Opening a project in Access modifies all code modules

[daFreeMan]

Using RD 2.01b (2.0.0.38396)

When I open a project in Access 2010 then open the IDE, all forms are opened in design view, all code modules are brought to the foreground in the IDE, and when I try to close the project immediately after opening, I'm asked if I want to save every single module.

If I say No to all, the IDE and Access window disappear, but the process continues running using 0% CPU (according to Task Manager). Killing the process leaves the Access project unusuable - the forms exist, one code module is retained, but the remaining code modules have disappeared. rubberduck Access no save.log.txt

If I say Yes, I'm prompted with a Save As dialog and have to click OK to name each module. It will accept the existing module name without complaint. The IDE and Access window will close, but again, the process will remain running using 300+ MB of memory and 0% CPU. rubberduck.log.txt

If I open the project in Access again, RubberDuck is missing from the IDE menu and there is no attempt by RD to parse & resolve the project. If I go to Task Manager, kill the MSACCESS.EXE process, then open Access, RubberDuck is back on the tool bar, it is parsed & resolved, and the process starts over again.

This does not seem to be happening in Excel. I open an XLSM, open the IDE, RD parses and gets to a complete state. I then close Excel without doing anything else, and I do get prompted to save, but when I do so, all code modules remain. To be clear: RD is touching every code module and Excel marks the file Dirty (of course, moving the cursor to a new cell marks it Dirty, so that's not a major crisis), however, if I open the file, wait for RD to parse, then close it, I shouldn't get prompted to save. rubberduck Excel.log.txt

There is no data in my Access project, everything is linked files to a SQL Server back end, and there's nothing particularly proprietary about the code, so I could probably be talked into sending it in if needed.

[BobTB]

I have a similar experience with 2.01b, but did not know if I was to blame or RD is. It happens sporadically, some 6 times out of 10. Here I do not have the problem with IDE forms and stuff as above, but what happens to me is that msaccess.exe is kept running even after the application is closed. I have to kill it to be able to open the database, as otherwise it is still marked as in use inspite of IDE and Access windows disappearing.

[daFreeMan]

@BobTB - the "Access process doesn't terminate" issue is also referenced in #1843.

[retailcoder]

If I understand correctly, this issue is about RD marking the project as "dirty" even though nothing seemingly changed in any module?

But a parsed project will be "dirty", by design - RD is working around the ludacrisness of COM/interop references by assigning a ProjectId in the VBProject's HelpFile property (which nobody uses anyway) - this ID is then used in every declaration's hash code, which makes host project equality checks reliable.

If that's what this issue is about, then it's entirely by design, and unless anyone can come up with a reliable way of keeping COM references around and then later use them in reference equality checks, that's how it's going to have to be (unfortunately?).

[retailcoder]

That said, I find it awkward that Access would prompt to save individual modules, since I thought a vbproject was treated as a whole in the host app (which seems to be the case in Excel anyway). Individual modules are not modified upon being parsed; parsing is a read operation; not sure what's up with Access here.

[ThunderFrame]

Yes, Access prompts to save individual modules, as they're treated as first-class objects (just like Tables, Queries, Access Forms and Reports) in the Database Window. A VB Form does not appear in the Database Window, but it still needs to be saved individually.

[ThunderFrame]

And, FWIW, as per the spec, it's up to the host to determine how it actually stores the VBA streams and storages. In other MS applications, the streams are all stored in the VBA binary, in a fairly consistent manner. But in Access, the streams are stored in an Access table, and as such, each VB object has a unique Access object-specific Id in the MSysObjects table, and a VB-specific Id in the MSysAccessStorage table. It might be possible to execute some SQL to establish the uniqueid of a module, although I'm unsure if those id's will survive a Compact Database operation.

[daFreeMan]

This seems to have been fixed at some point along the way.

I just tested both Access & Excel in 2.0.11, opening a file, opening the IDE, parsing the project then closing the file. I received no prompt to save the file from either host.