search

joyfullservice / msaccess-vcs-addin

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

VCS 3.4.22: ERROR: Unhandled error found before `On Error` directive #341

Closed alanv73 closed 2 years ago

alanv73 commented 2 years ago

vcs_error

Export.log

joyfullservice commented 2 years ago

If you turn on the option to debug VBA errors, are you able to see the line of code where the error is being triggered?

image

Looking at the log file, it would appear that it is happening in the themes and/or imex specs scan/export process. Let me know if you are able to pinpoint this further, or if you can provide a small sample database reproducing the issue.

alanv73 commented 2 years ago

Here goes... The error: vcs_error1

The debug point: vcs_error2

If I step through the code I get to here: vcs_error3

BTW, I just exported 8 different databases and this error occurred on every one of them so I don't think it's database related.

joyfullservice commented 2 years ago

Thanks for the additional information! I did some testing with the same version of the add-in and I am not seeing this behavior on my system... Which version and build of Access are you currently running?

Also, you might try renaming the source folder to see if the export runs correctly on a fresh export with no existing files. (Noting that the call stack in your screenshot points to something connected with clearing orphaned source folders.)

Have you been running version 3.4.22 for a while, and this suddenly started happening, or did you recently upgrade from an older version of the add-in?

alanv73 commented 2 years ago

Previously using 3.4.17, I downloaded 3.4.22 at the beginning of May (5/2 maybe) and used it a few times in May (5/17 is the last) but not since then. (Wasn't there an Office update released since then?)

I have tried exporting to an empty local folder, nothing changed.

Access Version: Microsoft® Access® for Microsoft 365 MSO (Version 2206 Build 16.0.15330.20144) 32-bit RubberDuck: Version 2.5.2.5906 OS: Microsoft Windows NT 10.0.19044.0, x64 Host Product: Microsoft Office x86 Host Version: 16.0.15330.20230 Host Executable: MSACCESS.EXE

Edit: When I exported to a clean local folder, I noticed that the log says it processed 51 themes, yet there is no themes folder present in the repo. Previously, all of my repos have a single theme file in the themes folder named Ofice Theme.thmx.

Detailed Output Export.log

Update: The images folder is also missing from the new repo. The log says that 51 images were exported but there should be more like 84 images. Coincidentally, there were 51 properties exported?

The errors appear in the log in all cases (all 8 of my front end databases) after exporting images (which I don't think actually happened) and after exporting themes (also don't think it actually happened).

I checked my backend databases and the error only occurs after theme export, but those databases have no images.

I rolled back to 3.4.17 and the error is still present.

alanv73 commented 2 years ago

In a troubleshooting attempt I rebuilt one of my databases from source. It's choking on the theme file.

image

Build.log

joyfullservice commented 2 years ago

It sounds like you are the right track there... It is a little challenging to troubleshoot without being able to reproduce the problem on my end, but that is what I love about having this add-in running as an unlocked Microsoft Access VBA project. You can literally debug the add-in itself, just as you would your own project.

After opening the add-in the first time in the current instance of Microsoft Access, it will be loaded as a VBA project. You can then add break points to the code, view locals and the call stack, and even edit and continue just like you would in your own database. The key difference is that none of your changes to the add-in will be saved, since it is loaded as a library, not as the current database. (To reset the add-in to its original condition, simply close the Access instance and open it back up.)

I would suggest adding some break points in relevant places, such as where the add-in begins the export of the theme and shared images. F8 and Shift+F8 are helpful keyboard shortcuts to step through the relevant code. While the code is paused, you can hover over variables or print to the immediate window to get a better understanding of what is happening.

As you do this, hopefully it will be pretty efficient to pinpoint exactly what is causing the problem. Like you mentioned, it could be a bug in a recent update of Access, or it might be something we could tweak in the code to resolve the issue.

Keep me posted! 😄

Dlothcab commented 2 years ago

Access Version: Microsoft® Access® 2016 MSO (Version 2206 Build 16.0.15330.20144) 32-bit Version Control System: 3.4.22

I've been running into the same problem, but it stops at this line instead (with error 13/Type mismatch):

image

This is the recordset that I get by running the sql statement image

When I check to type of m_Rst!Data in the immediate window it says 101. image

joyfullservice commented 2 years ago

@Dlothcab - What do you get if you run this: ?TypeName(m_Rst!Data)

Dlothcab commented 2 years ago

image

Dlothcab commented 2 years ago

Changed the type of fld2 to DAO.Field3. Export works with no errors.

image

joyfullservice commented 2 years ago

Wow. Sounds like a new class type... I assume this must have been introduced in a recent release. 🤔

mwolfe02 commented 2 years ago

Yep. See this StackOverflow answer from Access MVP Gustav Brock for details.

alanv73 commented 2 years ago

I just changed all of the variable declarations of DAO.Field2 to DAO.Field3 and the errors are gone.

image

image

mwolfe02 commented 2 years ago

@alanv73 What if you change the declarations to DAO.Field instead of DAO.Field3 (or DAO.Field2)?

Reading between the lines of Gustav's answer on SO, it looks like that is the approved way to avoid future breaking changes when Microsoft inevitably introduces DAO.Field4, DAO.Field5, etc.

When we make an update to an interface, we can’t update the existing interface, but must extend the existing interface. We are looking into whether we can improve the backward compatibility issue for cases where people explicitly declared variables to be of type Field2, rather than just Field.

joyfullservice commented 2 years ago

@alanv73 What if you change the declarations to DAO.Field instead of DAO.Field3 (or DAO.Field2)?

My thought exactly! This would be helpful for backwards compatibility because DAO.Field3 won't compile on Access 2010.

alanv73 commented 2 years ago

That works as well.

Export.log

mwolfe02 commented 2 years ago

If switching to DAO.Field works, I would also try switching from DAO.Recordset2 to DAO.Recordset.

I have a feeling the same theory will apply there, too. Switching to DAO.Recordset now might save some future grief (assuming it works).

joyfullservice commented 2 years ago

Thank you all for your help testing that in the newer versions of Access! I will plan to roll out an updated release this afternoon to address the issue.

alanv73 commented 2 years ago

If switching to DAO.Field works, I would also try switching from DAO.Recordset2 to DAO.Recordset.

Also no errors in this test case.

Export.log

mwolfe02 commented 2 years ago

Awesome! Thanks for testing that @alanv73! I'm writing an article about this on https://nolongerset.com. Check back later today to see it.

mwolfe02 commented 2 years ago

Article is live: WARNING: Do NOT Declare DAO Fields As Field2, Field3, etc.. Thanks again, @alanv73, for your work in confirming the recommendations from Microsoft.

joyfullservice commented 2 years ago

Version 3.4.23 is now ready for download. Thanks again to everyone for the help in getting this resolved! 😄

alanv73 commented 2 years ago

Thanks, I got it installed. Tomorrow morning I'll set to refreshing all of my repos that were affected by the bug. I'll let you know if I have any trouble.

[wrong account used before]