Jim Dettman
jimdettman at verizon.net
Tue Oct 10 13:27:30 CDT 2006
Jennifer, Sorry for the delay in getting back to you. You'll need to use the ADO to get the current roster. The code is here: http://support.microsoft.com/kb/198755/EN-US Only draw back is that you'll need to leave this up and running somewhere. When you find a user can't get into the database because it's corrupt, go to this instance and run the routine. The 4th column should show who left it corrupted. Jim. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jennifer Gross Sent: Monday, October 09, 2006 1:12 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] ODBC 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. -- Stuart -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com