Access shuts down on preview of report (1 Viewer)

ellenr

Registered User.
Local time
Today, 03:55
Joined
Apr 15, 2011
Messages
356
I'm not sure if this is the correct forum, but thought to start here with my bizarre problem. Access program for small manufacturer written by me 2000 or earlier. I finally talked them into upgrading to modern version. I converted to .accdb files for FE and BE and got through a few little bumps. The two office people run using shortcuts to the program FE that resides on the server in the same folder as the BE. They both have Win10 pro on new computers and both have Access 2019 so all should be identical. When they get an order there are six work order documents that go to the plant. For any given order, several of these reports may have no data. Only one of these office computers shuts down Access, makes a backup copy and restarts when trying to preview the "FSC" report (no idea what that stands for) if no data, and the other computer gives the no data message properly. I cannot make it fail on my development computer. Any ideas where and how to start troubleshooting? They never had any problem back in the .mdb days and the queries haven't changed.
 

bastanu

AWF VIP
Local time
Today, 00:55
Joined
Apr 13, 2010
Messages
864
FIrst of all make sure each user has their own LOCAL front-end, not much point in splitting if they share the same network front-end. Then check the VBA references on both machines.

Cheers,
 

ellenr

Registered User.
Local time
Today, 03:55
Joined
Apr 15, 2011
Messages
356
After the bugs are worked out, I will give them local FEs. Since they are both using the same copy on the server, can the references differ?
 

bastanu

AWF VIP
Local time
Today, 00:55
Joined
Apr 13, 2010
Messages
864
You cannot properly test with a shared file as sometimes server locking settings would interfere with multiuser usage. The references are to code libraries installed on each computer, not on the server. The fact that the file has a set of references doesn't mean they are available on each machine.
Cheers,
 

gemma-the-husky

Super Moderator
Staff member
Local time
Today, 08:55
Joined
Sep 12, 2006
Messages
14,531
It might be a bit late now, but you could have probably converted it to a compatible mdb, and if it ran fine in that, then looked to convert it to an accdb.

You are on the correct bitness aren't you. I assume it's 32bit access
 

ellenr

Registered User.
Local time
Today, 03:55
Joined
Apr 15, 2011
Messages
356
I am getting closer I think! The snips attached below show code that isn't working occasionally on customer computer. Why?
 

Attachments

  • Capture.PNG
    Capture.PNG
    33.3 KB · Views: 48
  • Capture2.PNG
    Capture2.PNG
    9.5 KB · Views: 132

bastanu

AWF VIP
Local time
Today, 00:55
Joined
Apr 13, 2010
Messages
864
Can you try to include the Start argument?
e1:InStr(1,[Details],"[")

Cheers,
 

ellenr

Registered User.
Local time
Today, 03:55
Joined
Apr 15, 2011
Messages
356
Thank you!!! That seems to have fixed it. I've been writing Basic code since the 80's and haven't done it this way. This is the first time I have run into a problem.
 

bastanu

AWF VIP
Local time
Today, 00:55
Joined
Apr 13, 2010
Messages
864
You're welcome, hopefully it will stay fixed. The start argument is optional, but required if you use the fourth "compare" argument (which you don't). When built in functions like this start to misbehave usually there is some sort of Office installation isssue\Windows or Office updates, very hard to track.

Cheers,
 

Isaac

Lifelong Learner
Local time
Today, 00:55
Joined
Mar 14, 2017
Messages
5,578
All else being equal and nothing else having changed, this all seems a bit odd to me. That that would fix it.
When built in functions like this start to misbehave usually there is some sort of Office installation isssue\Windows or Office updates, very hard to track
agreed
 

The_Doc_Man

Immoderate Moderator
Staff member
Local time
Today, 02:55
Joined
Feb 28, 2001
Messages
20,690
@ellenr - just as an explanation...

The main reason you split databases and make COPIES of the FE for each user is to avoid tripping over the inevitable file locks that you take out when sharing files. Saying you will distribute separate copies later means you will keep open a huge window of opportunity to corrupt your DB because of file locking conflicts. The moment that Access takes a fatal lock conflict, it will potentially leave a DB file in an incompletely updated (and therefore self-inconsistent) state. Leaving you with problematic data recovery.

The reason you must visit or take other steps for your users is that giving them their own copy of the FE isn't enough. Whether they use the same FE or different FE files, they are on different machines. The references are indicated in the .accdb or .mdb file but they are effective only if they have been updated in the registry (HKCU segment, probably). So it is EASILY possible for two users sharing FE and BE files on the server to nonetheless have different experiences based on their references and registry settings. And you must remember, the registry is not only per-machine, it can even be per-user on a shared machine with two different logins.
 

ellenr

Registered User.
Local time
Today, 03:55
Joined
Apr 15, 2011
Messages
356
Thank you, Doc Man. That all makes sense. What is the best way to handle program updates?
 

The_Doc_Man

Immoderate Moderator
Staff member
Local time
Today, 02:55
Joined
Feb 28, 2001
Messages
20,690
We have several threads here on the topic of automatic updaters. Basically, you don't launch the front end. You launch a batch job or VBScript item that looks at the creation dates on the master FE vs. the end-user's copy of the FE - or there are other methods as well. Then if the end-user has the latest copy, launch it from the batch job. Otherwise, delete the local FE and download / copy the newer version, then launch that.

Here is a post where several of our members show you what they do for this problem.
 

Users who are viewing this thread

Top Bottom