search

joyfullservice / msaccess-vcs-addin

Synchronize your Access Forms, Macros, Modules, Queries, Reports, and more with a version control system.
Other
211 stars 41 forks source link

Error on Build from Source; automation error #197

Closed hecon5 closed 3 years ago

hecon5 commented 3 years ago

I've been getting the following error lately; any ideas?

ERROR: Importing VBE Project Source: clsDbVbeProject.Import Error -1027541024: Automation error [1]

hecon5 commented 3 years ago

Thanks @retailcoder! I appreciate your input and the back story; VBA is like that; wonderful to use for so many applications, but constraining in others, so bound to have 'features' like this one. Thank you again.

hecon5 commented 3 years ago

For tracking purposes: https://github.com/rubberduck-vba/Rubberduck/issues/5741 is the Rubber Duck Issue. When it's closed, perhaps we should retire the option all together...again...

joyfullservice commented 3 years ago

For tracking purposes: rubberduck-vba/Rubberduck#5741 is the Rubber Duck Issue. When it's closed, perhaps we should retire the option all together...again...

Yes, I think that sounds like probably the best approach. We don't need to carry forward workarounds that are no longer relevant. But we may want to give it a little time for users to adopt the updated RD version before entirely removing the workaround.

joyfullservice commented 3 years ago

... In Access however, unless I'm mistaken there's only ever a single VBA project opened per instance, so the risk of collision is non-existent: any non-empty value in that field would stop Rubberduck from re-generating it everytime: even just 0 should work.

@retailcoder - Thanks for taking time to chime in on this thread! It is helpful to get your perspective and some of the history behind the usage of the HelpFile property.

I wanted to mention a couple scenarios in Microsoft Access where you can have multiple VBE Projects open in the same application instance.

  1. Microsoft Access Add-in projects (such as this project, and some of the internal wizards and utilities) are loaded on demand at the application level. (This reference is persistent even when the current database is closed.)
  2. Access also supports Library Databases, where you can add a reference to another Access database and interact with the exposed objects and classes. This probably isn't widely used, but in my corporate environment I use this pretty extensively to share code libraries between projects. These can even have nested dependencies upon each other, which can create additional situations where you might have multiple copies of the same library opened from different locations. In Access you can change properties and even code in these nested libraries, but the changes are not saved to the file, and are lost when the parent database is closed.

Here is a screen shot illustrating multiple VBE Projects referenced in a single database:

image

In my environment, I have all the library databases in the same folder as the parent database, and ensure that they are all recursively linked to the same set of libraries so it works pretty well for us.

image

All that to say, there are definitely times when you will have multiple VBE Projects in the same application instance in Microsoft Access. I hope that helps!!