MartyConnelly
martyconnelly at shaw.ca
Mon Oct 9 14:27:43 CDT 2006
You could try opening the corrupt ldb file and read it with notepad or with a hexeditor, you shoud be able to read the machine name and userid of the clients extant in mdb at corruption However the machine name may be just the server something like CITRIX01 One of the checks that MS applies to determine a corrupt mdb is on opening the mdb if the .ldb file is there but has no file locks on it, then the database is considered corrupt and needs to be "repaired". Normally the last Access process to have the .mdb open will delete the .ldb file when the .mdb file gets closed, or at least remove the last lock on the file Now this is just a wild idea but with a copy of the corrupt backend mdb and ldb Open up the .ldb file in notepad, this will establish at least one system file lock and you might then be able to look at both through the LDB viewer with or without using the schema roster. Another way without opening a program to establish a lock is maybe to do a Dir( "c:\filepathname to ldb") then run the userroster method Jennifer Gross wrote: >Hi Jim, > >I am using A2K and I would love to know how to find out who is >corrupting the database. I cannot use Dev Ashish's LDB Viewer because >it does not recognize the BE as a valid database when it is in a >"corrupt" state. > >Thank you, > >Jennifer > >-----Original Message----- >From: accessd-bounces at databaseadvisors.com >[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Dettman >Sent: Monday, October 09, 2006 5:25 AM >To: 'Access Developers discussion and problem solving' >Subject: Re: [AccessD] ODBC > > >Jennifer, > ><<Recently a WAMP Server (Apache) was installed on the TS box. Although >it is inactive I have concerns that it has changed some setting that are >contributing to the problems we are having. >> > > Maybe not a setting that was changed, but certainly it is consuming >more resources on the server. My first stop would be the system event >logs checking for any errors or warnings. I would also go back and >check all TS settings in general and for each user. A disconnect should >not logout the session. > ><<Since then the database has been "corrupting" at least once a day - >typically around lunch time when all users are getting in to clock out - >their time clock is part of the database. No data is lost, but the >repair utility has to be run.>> > > Someone is getting terminated abnormally. Have the users reported any >strange behavior or problems? I didn't see in the prior messages what >version of Access you are using, but what you need to do is find out >what >user(s) are leaving the database in a corrupt state. The method you use >depends on the version (either using LDBVIEW or the JET roster). Once >you have that, you can build up a pattern (same user all the time or >different users each time). That generally gives you a clue where the >problem lies. > ><<in the past when I was posting a FE >update, if someone was using the database the linking to the BE would >take 20+ minutes, I assume because of the record locking checks. >> > > I would say 20+ minutes was abnormal, but without knowing what you >mean by doing a "FE update", I can't say for sure. > ><< Now, >it takes less than a minute, as though no one is working in the database >and everyone who is working in the database gets kicked out. >> > > How do they get 'Kicked out'. A message? Window simply closes? > > There is nothing in Access that does this on it's own. It's either >something built into your app or something abnormal that is occurring. > >Jim. > >-----Original Message----- >From: accessd-bounces at databaseadvisors.com >[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jennifer >Gross >Sent: Sunday, October 08, 2006 4:18 PM >To: 'Access Developers discussion and problem solving' >Subject: Re: [AccessD] ODBC > >Hi Jim, > >We have <25 users. > >The FE is only referencing DLLs and type libraries so hopefully that >should not be a problem. > >Recently a WAMP Server (Apache) was installed on the TS box. Although >it is inactive I have concerns that it has changed some setting that are >contributing to the problems we are having. New IT guy says it was >installed subsequent to the first corruption, but it was the same day. >Since then the database has been "corrupting" at least once a day - >typically around lunch time when all users are getting in to clock out - >their time clock is part of the database. No data is lost, but the >repair utility has to be run. > >In addition to the "corruptions" another strange thing has been >happening during this time period - in the past when I was posting a FE >update, if someone was using the database the linking to the BE would >take 20+ minutes, I assume because of the record locking checks. Now, >it takes less than a minute, as though no one is working in the database >and everyone who is working in the database gets kicked out. We have >one guy who works late nights, and that is when I post FE updates. > >Any thoughts? > >Jennifer > >-----Original Message----- >From: accessd-bounces at databaseadvisors.com >[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Dettman >Sent: Sunday, October 08, 2006 4:39 AM >To: 'Access Developers discussion and problem solving' >Subject: Re: [AccessD] ODBC > > >Jennifer, > ><< We are having data corruption and the new guy says it >is because of Terminal Server - too many connections to the back end >from the same box. I know very little about the >network/hardware/software aspects and am at a loss. >> > > The TS connection settings should be checked. When a connection is >dropped, there are various things TS can do; retain the session so you >can reconnect, log it out, etc. > > What you don't want is for it to be logged out. That means Access >(and any other running apps) will get terminated whether they want to or >not. > > The other place where TS bites you is references. Unless you change >references on the fly or distribute a special TS version of your FE, all >users will have references (usually to the local C drive in most cases). >This means they are all sharing those references even if you've given >them all a separate copy of the FE. With Dll's and type libs, that's >not a problem, but if it's a .MDA add-in, you might have some issues >with that. Using some of the Access Wizards under TS requires >workarounds because of this. > > Beyond that, running TS is no different then a bunch of client PCs all >connecting to the BE in terms of connections. In fact, it's a lot more >stable. If I could run Access under TS vs the "normal" way, I'd choose >TS hands down every time. > >Jim. > > BTW, how many users are we talking about? > > > > > >-----Original Message----- >From: accessd-bounces at databaseadvisors.com >[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jennifer >Gross >Sent: Friday, October 06, 2006 11:16 PM >To: 'Access Developers discussion and problem solving' >Subject: Re: [AccessD] ODBC > >Hi Stuart, > >Do you have experience with Terminal Server with multiple users running >separate front ends to a common Access data file? I would love to pick >your brain if you do - or anyone else for that matter. I currently have >a new IT guy who is in conflict with the old IT guy about our use of >Terminal Server. We are having data corruption and the new guy says it >is because of Terminal Server - too many connections to the back end >from the same box. I know very little about the >network/hardware/software aspects and am at a loss. I have made no >changes to the database, yet in the past two weeks we have experienced >several "corruptions", when the database had been stable for nearly a >year without a corruption. > >Any help would be appreciated. > >Jennifer > >-----Original Message----- >From: accessd-bounces at databaseadvisors.com >[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Stuart >McLachlan >Sent: Friday, October 06, 2006 8:05 PM >To: Access Developers discussion and problem solving >Subject: Re: [AccessD] ODBC > > >On 6 Oct 2006 at 19:09, Jennifer Gross wrote: > > > >>Question 1: When an Access front end connects to an Access backend is >> >> > > > >>it an ODBC connection? >> >> > >No, it's a JET connection, which is more efficient than ODBC > > > >>Question 2: If multiple users have separate front ends on the same >>Terminal Server box linking to a back end on a different box, are they >> >> > > > >>opening separate connections to the back end (ODBC or otherwise), or >>are they sharing the same connection? >> >> > >They are separate connections. > > > -- Marty Connelly Victoria, B.C. Canada