Solved Odd error in my database

[Scott_Hall]

Howdy folks. I'm seeing an odd issue in a database I've had deployed for years and hope someone here might have a stroke of brilliance for me.

• The database is a few years old and has been running smoothly.
• It is an Access 2016 file, compiled to accde.
• All users have the same version of Office/Access
• It uses an Access back end.
• It is deployed with the standard batch file FE copy-to-local then launch
• There are 30ish users with 4-6 concurrent.
• All users connect over a remote desktop Citrix Receiver based platform.
• I have not made any changes (no patches to my dB) in months

So last Friday, three users received new Windows 10 laptops from IT. Despite the hardware, they still log into RD to use the database. Strangely, this Access database instantly closes on open for all three users. It closes so fast that it doesn't log any kind of error or log their entry into the system (which is the very first code executed). They can open other Access files, but this one just shuts down. They have full network permission to the data file drive.

I'm scratching my head on this one. Somehow it must involve these new laptops since that is the only thing that changed...but the users are all using a RD session, so the thick client shouldn't matter. All users are on Windows 10, though the thick clients could have different service patches.

Has anyone run into anything like this before/lately?

Thank you for any suggestions,
Scott

 

[arnelgp]

try if the solution here can solve your problem.
Solved - Access 2003 database under Windows Serwer 2019 - form open restarts application | Access World Forums (access-programmers.co.uk)

 

[Scott_Hall]

Unfortunately I can't even get into the DEP menu without IT support, so I'm waiting on them.

I did find something more though: the accdb runs fine...only the accde crashes. Code tracing found no errors, simply being compiled into accde kills it.

 

[bastanu]

Did you check the bitness of the Office installation on the new laptops, could it be 64 vs 32?

 

[Scott_Hall]

Did you check the bitness of the Office installation on the new laptops, could it be 64 vs 32?

Yup, identical systems. Build 5317 32 bit.

I also checked the file version...12 which is Access 2016, which is the current version everyone uses.

 

[bastanu]

I would also look at the Trust center and make sure you have the trusted locations set for the local folder where the front-end resides.

 

[Scott_Hall]

Thanks, yeah I've tried the file in several locations (all trusted).

It seems like this must have something to do with the recent bug introduced by Microsoft, and yet at the same time since it is a common remote desktop setting and only a few people are impacted, it seems like it can't be that.

Again, if the file is accdb it works flawlessly, but the second I save into an accde it fails. Same location, same user. No error messages, nothing logged, just instant shutdown of Access.

 

[Gasman]

Have you compared windows updates?

 

[jdraw]

I agree seems related to the recent bug and current work around is as per the link you referenced in #7.

 

[Scott_Hall]

Have you compared windows updates?

That's the fun part. All users are operating off of a single remote desktop system, so we all have exactly the same updates and software, environmental conditions, etc.

Now, people can log in from personal machines, work laptops, etc. The company doesn't care since they go into the encrypted remote environment. The only people who are impact are those three who use new work laptops they were issued last week. Shockingly, none of them own other computers so they have no ability to try logging in from another computer (without them making effort, which so far they have not).

My hope is that one of them will successfully launch the database using another computer, proving that the issue is locked to their thick clients. That doesn't make much sense to me either since it is the RD that should matter, but I've found no other commonality.

 

[Scott_Hall]

I agree seems related to the recent bug and current work around is as per the link you referenced in #7.

What throws me about this is that so far only this singular Access file is misbehaving, and if it was the accde update....why is it just three users instead of everyone?

 

[isladogs]

Yup, identical systems. Build 5317 32 bit.

I also checked the file version...12 which is Access 2016, which is the current version everyone uses.

Access v12.0 is actually Access 2007.

 

[Gasman]

My 2007 ?

 

[Scott_Hall]

Correct me if I'm wrong here. I am checking two values...the version of the dB file at creation and the current operating version of Access:

CurrentProject.FileFormat yields a result of 12, which is the Access 2007-2019 .accdb file format
Application.Version yields a result of 16.0, so Access 2016

When I create a brand new Access database right now using 2016 and check CurrentProject.FileFormat...I still get a result of 12. So I think that 12 is correct for accdb 2007-2019?

 

[Gasman]

No, I believe just the version of access.
I just used your CurrentProject.FileFormat and get 12 for accdb and 10 for my mdb which was from 2003.

So just your version which is 16 as you say, but this says differently. Confusing as hell

Microsoft Access Version Releases, Service Packs, Hotfixes and Updates History

Microsoft Access has many versions, Service Packs, Hotfixes and other Updates with Office

www.fmsinc.com

 

[isladogs]

Ah yes... the ACCDB file format was introduced with Access 2007 (v12.0) so the CurrentProject.FileFormat is indeed 12
The format hasn't been significantly changed since then
Similarly Excel .xlsx file format is 12 etc ....

 

[The_Doc_Man]

Reading through this, I noticed something that probably has nothing to do with anything. But hey, nothing else has shown up very much, so ...

Your opening description makes it clear that the users with the new workstations - 3 new laptops - have the problem. But just to nail down this environment, what were the other users using? I looked and didn't see that. I DID see that they are all using RD sessions under Win10. OK, no biggie there. But since they are all on RD sessions, are they correctly set up to have private RD environments? I ask that because some RD admins drop everyone into a common folder for their file-locking free-for-all. And that, of course, kills the world the moment you have two users.

Another thing bothers me. You saw no error messages, but have no apparent compilation errors. (Since you are building .ACCDE files, you CAN'T have compilation errors.) But that 'no errors' bothers me. Since that is occurring on an RD system there will be a central event log. Can your IT folks help you look at the event viewer logs for a time when someone tries to run that app and it terminates? The thing that bothers me is that Windows is just not normally silent. It leaves a big, ugly event trail when it messes itself. If you have a date and time corresponding to when one of these attempts fails (and a username so you can confirm it is the right entry), you should check the Windows Event Viewer for that date/time. There might be a couple of entries in quick succession, the first being the failing app - unless there is a common triggering event that is almost in the same second. Particularly on a server, there should be either a SYSTEM error event or there might be an app-specific error event depending on WHICH of the several possible RD tools you are using.

 

[Scott_Hall]

Reading through this, I noticed something that probably has nothing to do with anything. But hey, nothing else has shown up very much, so ...

Your opening description makes it clear that the users with the new workstations - 3 new laptops - have the problem. But just to nail down this environment, what were the other users using? I looked and didn't see that. I DID see that they are all using RD sessions under Win10. OK, no biggie there. But since they are all on RD sessions, are they correctly set up to have private RD environments? I ask that because some RD admins drop everyone into a common folder for their file-locking free-for-all. And that, of course, kills the world the moment you have two users.

Another thing bothers me. You saw no error messages, but have no apparent compilation errors. (Since you are building .ACCDE files, you CAN'T have compilation errors.) But that 'no errors' bothers me. Since that is occurring on an RD system there will be a central event log. Can your IT folks help you look at the event viewer logs for a time when someone tries to run that app and it terminates? The thing that bothers me is that Windows is just not normally silent. It leaves a big, ugly event trail when it messes itself. If you have a date and time corresponding to when one of these attempts fails (and a username so you can confirm it is the right entry), you should check the Windows Event Viewer for that date/time. There might be a couple of entries in quick succession, the first being the failing app - unless there is a common triggering event that is almost in the same second. Particularly on a server, there should be either a SYSTEM error event or there might be an app-specific error event depending on WHICH of the several possible RD tools you are using.

All users are logging into the MyPC/Citrix environment supposedly under the same conditions. There are zero errors identified at login.

There are zero compile/debug errors found.

Once they are logged in and try to start the database, they see a flickering then a crash/shutdown. Nothing is recorded as an error that myself or IT can see. Access simply closes almost instantly.

 

[The_Doc_Man]

I was referring to the hardware used by the users who DON'T have the problem. Laptops? Desktops? Since you were building a DE file, I didn't think you would have errors.

I still come to the question of which version of the RD client is used by the new laptops and which version is used by the older stations.

 

[Scott_Hall]

Hardware is a mix across the user base. Mostly Dell laptops, but a few others and even a couple of Macs. The RD software is Citrix Workspace, and I've verified that we have functional and non-functional people using the same versions.