Jim Dettman
jimdettman at earthlink.net
Tue Jul 8 15:24:43 CDT 2003
Ron, I'd set the UseTransactions property on your action queries to no. This will allow JET to breakup the action queries into multiple transactions. Right now, it's having to create copies of everything and place locks on everything in case it needs to roll back. Just make sure you have a good backup. If the process stops in the middle, it will be a mess. Also, something has obviously changed as you said. Has the machine where the DB's reside had any work done on it? The machine where the job is executed? Remember, everything is processed locally even if the DB's reside on a different machine, except for locking, which is handled by the OS/NOS where the DB's reside. Jim Dettman President, Online Computer Services of WNY, Inc. (315) 699-3443 jimdettman at earthlink.net -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Ron Allen Sent: Tuesday, July 08, 2003 3:29 PM To: Access Developers discussion and problem solving Subject: [AccessD] Acc97: File Record Locking Count Exceeded error Hello folks, I have another odd problem I could use some suggestions on solving. I have an Access97 back end and .mde front end setup. The backend .mdb is approximately 180MB. The backend is on a mapped drive on the machine(s) where the front end is located. We have a Windows NT network. Each week, 8 files, about 200MB total, obtained from running various programs on our Unix system, then imported into the backend (via the frontend) using a process I programmed in several years ago. The data replaces the existing data. In addition, a good deal of processing is done, i.e. action queries to format data, calulate values, etc. during the import process. The import process takes several hours to complete, but this is acceptable because its once weekly and not time critical. The import process has operated fine for about three years. This week, the import has stopped twice with File Record Locking Count Exceeded. Also, the import process is incredibly slow, taking more than 8 hours to finally crash less than half-way through; the whole thing usually completes in about 3 to 4 hours. Before running the update each week, a simple filecopy backup is done, and then the backend is compacted using JetCompact. The data files being imported appear to be of the correct sizes and a brief look at them reveals no obvious formatting or other errors. In other words, something has changed, but I don't see what. The Microsoft site has two possibilities, one if on a Novell network and the other involving replication. Neither of those applies. Any suggestions or insights? Thanks, Ron _______________________________________________ AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com