Error 3531 (?) (1 Viewer)

GBalcom

Much to learn!
Local time
Today, 05:57
Joined
Jun 7, 2012
Messages
459
Just wrapped up a db for a client. Put the backend on their network (.accdb). Had the front ends put on the client work stations. (.accde). Deployed last night. Tested and worked fine. Today we're getting errors Saying the wait period for an event has timed out. Any ideas?
 

CJ_London

Super Moderator
Staff member
Local time
Today, 12:57
Joined
Feb 19, 2013
Messages
16,553
Implication is there is a problem with the network
using reserved words as field names can cause misleading errors

Otherwise not enough detail to be more specific.

do clients have full versions of access, or using runtime?
What did your test involve?
is everyone experiencing the same problem?
when does the error occur? On login? a specific form?
What line of code is causing the problem?
 

theDBguy

I’m here to help
Staff member
Local time
Today, 05:57
Joined
Oct 29, 2018
Messages
21,357
This question looks similar to this one at UA, are they related? Just curious...
 

GBalcom

Much to learn!
Local time
Today, 05:57
Joined
Jun 7, 2012
Messages
459
Hi CJ,
Thank you for the quick response. Clients have full version of Access 2016 (I believe, will confirm). I'm running Access 2013. I was able to get it to open fine on their machine last night. The only thing I didn't try was to have more than one FE looking into the BE at the same time.
 

GBalcom

Much to learn!
Local time
Today, 05:57
Joined
Jun 7, 2012
Messages
459
DB Guy,
That isn't my post, but I'm about to look at it. Thanks for bringing it up.
 

The_Doc_Man

Immoderate Moderator
Staff member
Local time
Today, 07:57
Joined
Feb 28, 2001
Messages
26,996
Error 3531 describes a "timeout" on an event. From your description, you have a native Access back-end file on a remote file server. (Correct me if I am wrong on that.) If my interpretation of your configuration is correct, there can be no asynch internal operations because native Access is inherently synchronous. Therefore, we have to look outside of Access itself.

The next question is, if you are getting timeouts, I would have to ask if you are seeing a large number of "Database in Inconsistent State" messages. Because the next place to look is the network connection between the FE and BE machines. If you are getting event timeouts, you should also be seeing other errors. I would be incredibly surprised if you weren't.

It might also be nice to know what they were doing at the time of the failure. Like, running an update query? Running an INSERT INTO query? What kind of operation was going on?
 

GBalcom

Much to learn!
Local time
Today, 05:57
Joined
Jun 7, 2012
Messages
459
Doc man,
The Back End resides on an in house server. close to the client computers.
 

GBalcom

Much to learn!
Local time
Today, 05:57
Joined
Jun 7, 2012
Messages
459
There isn't many records at all (<1,000). So, I'm not sure what they could have been doing. They have these apps on 4 computers. So, in theory I guess all of them could have been typing in new records? Still doesn't seem like a huge load.

I also just checked the trust settings and added the location that the BE is at. I'm really hoping that was it.
 

The_Doc_Man

Immoderate Moderator
Staff member
Local time
Today, 07:57
Joined
Feb 28, 2001
Messages
26,996
Actually, I inadvertently used the word "remote" unclearly. I really should have just said "separate" - which is what you described. My bad.

The only other thing I would look for is whether you have "Pessimistic Locking" in use. That is the only thing that would interfere with a simultaneous update and cause a timing issue. If you do, the fix is to choose either Optimistic Locks or No Locks. Either one should work OK for the small load you have described.
 

GBalcom

Much to learn!
Local time
Today, 05:57
Joined
Jun 7, 2012
Messages
459
Doc Man,
Thank you for your reply. It's time to fill in the rest of this story. I was hired to take a few small access apps and split them. They were created by a superuser, who is a database enthusiast. They did an OK job (it is working, for now), but after seeing them in use today, I see several things I wouldn't do, such as spaces in field names, users directly entering data into queries instead of forms, etc. The tables are in need of normalizing... They still want to retain the ability to go in and modify things as they require.

It turns out they were having that error before I split the DB, and I wasn't aware. I'm still trying to track that one down. We actually had the error today when opening one of the databases. I've checked the record locking, and it is set to no locks. However, I don't know what happens when they enter data directly into a query (their normal). I'm inclined to propose rewriting the application from scratch and porting the old data over. Is it possible any of these little issues could cause the Error 3531 mentioned above? The strange thing is it is they say it is happening to all of their mini-applications, not just one.
 

The_Doc_Man

Immoderate Moderator
Staff member
Local time
Today, 07:57
Joined
Feb 28, 2001
Messages
26,996
If you have an Access Front End and an Access Back End, you cannot be using a pass-thru query that would possibly lead to you waiting for the query to run in the active back end - because you don't have an active back end. And non-pass-thru queries that involve the back end are in an environment where your local machine's copy of MSACCESS.EXE (the Access executable image) is in control of everything. Everything in the FE is local so the only thing that CAN cause a delay is FE/BE communications.

The BE is on a passive file server so the only thing that would delay the operation is a delay to SMB (Server Message Block) protocol handshakes. Since SMB is also the protocol that implements file sharing through Windows Explorer, you should be able to use Explorer to look at those files directly and exercise the same protocol. If you can explore folders all over that file server and there are no delays in looking at files anywhere on that server (but particularly in that folder) then we don't yet know what is actually causing the delay.

If you don't see any delays in exploring the file server from some client of its service, then we need to dig deeper. The only way to be sure of what is happening is, in a form or report that exhibits this problem, implement logging to an event table. Make one if you don't have an event table already. You only need two fields - a SINGLE and a short text. At each event to be logged,

Code:
CurrentDB.Execute "INSERT INTO LogTable (MSMid, LogEvent) VALUES (Timer(), 'Form x event y') ;"

Timer() gives you milliseconds since midnight of today as a SINGLE. You put whatever message you want as the 2nd argument. Do this at each event entry point so you can see what event gets called and in what order. At some point, your error will trigger and you will know exactly which event was the last thing to fire. Whatever logically follows that event in sequence is where your error occurs.

It is possible to do this iteratively by identifying the failing operation and putting SEVERAL of the logging statement to identify phases of the specific operation. You want to narrow this down to where you have an event log that SHOULD be followed by another event log - but isn't followed by it. In essence, you are bracketing the failure with event logs. You can also have error handlers use this method. You can then sort by the MSMid field (or whatever you want to call it) to get an exact sequence of events. The problem with fixing this little pest is catching it.

Obviously, when you reach a solution, you can undo the special event logging and erase the table. In fact, you should manually erase the event log table before each run so that you won't get confused with yesterday's events.[/CODE]
 

Users who are viewing this thread

Top Bottom