ODBC - Failure, Is there a better way?

S

Sean

I have an Access 2003 database that runs on my company server and it is used
by multiple users at the same time (about 5 or so). Every so often if I make
a change to it, I have to go around to each users workstation and refresh the
table links because they get ODBC call failures. Is there a better way of
managing this database so I do not always get these failures?
 
P

Paul Shapiro

Does each user have their own local copy of the front-end db? I usually
setup client workstations to run an application by executing a batch file
which copies the current front end from the server to a local folder, and
then executes that local copy.

If users are already running local copies, network problems seem the most
likely issue to pursue.

If the problem occurs when you change data structure in the backend db, I
would expect this behavior. I only make structural changes with exclusive
access to the backend db file.
 
S

Sean

The database sits on the server and everyone has a shortcut to the database.
It does not have a front end and a back end.
 
D

Douglas J. Steele

You should split it. You should never have multiple users opening the same
application file.
 
C

Clif McIrvin

I think I'm missing something here --- if there is no FE, why do you
need to refresh table links on each user's workstation?
 
T

Tony Toews [MVP]

Sean said:
I have an Access 2003 database that runs on my company server and it is used
by multiple users at the same time (about 5 or so). Every so often if I make
a change to it, I have to go around to each users workstation and refresh the
table links because they get ODBC call failures. Is there a better way of
managing this database so I do not always get these failures?

Are you using SQL Server to store the data? Does each user have their
own copy of the FE on thier system or on the file server? What kind
of changes cause the ODBC call failure?

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
 
D

David W. Fenton

You should split it. You should never have multiple users opening
the same application file.

My advice on splitting:

Every Access application with more than one user should be split. NO
EXCEPTIONS.

Every Access application where the user needs to get updates to the
forms/reports from someone else should be split, even if it has only
one user. NO EXCEPTIONS.

Every replicated Access app should be split. NO EXCEPTIONS.

And every user should have an individual copy of the front end, no
matter whether the app is running on a workstation or in a Terminal
Server/Citrix session. NO EXCEPTIONS.
 
C

Clif McIrvin

Dave:

I've seen your (canned, I presume) splitting mantra several times, and
I've been lurking in these NGs long enough now that I understand some of
the reasons for your advice.

I would, however, offer one suggestion: include some links to several of
the good foundational background resources available on the various MVP
sites. Remembering my early days getting acquainted with Access and
these NGs, I'd venture a guess that a large percentage of newcomers
aren't even aware of - or how to look for - those resources.
 
D

David W. Fenton

I've seen your (canned, I presume) splitting mantra several times,
and I've been lurking in these NGs long enough now that I
understand some of the reasons for your advice.

I would, however, offer one suggestion: include some links to
several of the good foundational background resources available on
the various MVP sites. Remembering my early days getting
acquainted with Access and these NGs, I'd venture a guess that a
large percentage of newcomers aren't even aware of - or how to
look for - those resources.

If you're too dumb to take the good advice from the obviously
qualified participants in this newsgroup (who almost always
explicitly explain why splitting is needed when the topic comes up),
then some friggin' links are not going to make a difference.

If you want to supply the links, I'll include them in my canned
response, but I just don't think they are necessary.
 
T

Tony Toews [MVP]

David

I've delayed responding to this post because I wanted to think about
this.
If you're too dumb to

I have to disagree with the tone of the above words.
take the good advice from the obviously
qualified participants in this newsgroup (who almost always
explicitly explain why splitting is needed when the topic comes up),
then some friggin' links are not going to make a difference.

If you want to supply the links, I'll include them in my canned
response, but I just don't think they are necessary.

Actually Cilf has a good suggestion. I always try to post links as
well because folks, especially newbies to the forums and software,
don't know how to do a good search. You, regulars and myself do know
how to do the search.

And now with Google fouling up the frigging newsgroups search as they
have it's pretty useless doing a search on Google Groups.

So it's going to become even more important for us to include links.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
 
D

David W. Fenton

So it's going to become even more important for us to include
links.

If someone supplies them I'll include them in my canned response.

If nobody does, it doesn't seem to me like anybody really cares that
much about improving my canned response, and is really more
interested in just bitching for no reason other than to just bitch.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top