[AccessD] ODBC

Jennifer Gross jengross at gte.net
Mon Oct 9 12:12:01 CDT 2006


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





More information about the AccessD mailing list