One table link breaks every time

[EJO]

Using an MS A2K front end running on WinXP and ODBC connections to SQL
Server 7 on Win 2K server; there are about 10 users who access the
front end via Terminal Server and use the same front end; there are
about another 10 users who run a copy of the db on their local machine.
SQL server has 2 databases, with approx. 20 tables between them (one
is for processing ckts from a remote sql server for local use, the
other is a site database).

There is one user that always has to refresh the same single table each
time a release of the db is copied to his local machine. Once the
table is refreshed in link manager, the front end is good to go...until
the the next release is made (about every 2 months--for changes in
business rules). We have gone and checked his WINS and DNS settings
and at this point, the only difference between other users and this one
who can't get the table normally, is that he is using a different brand
machine (he uses a toshiba satellite, all others use a ibm thinkpad).
Since purchasing a new laptop for him is out of the question, does
anyone have a suggestion for correcting this problem?

TIA for the help,

EricO.

[MGFoster]

EJO wrote:

Using an MS A2K front end running on WinXP and ODBC connections to SQL
Server 7 on Win 2K server; there are about 10 users who access the
front end via Terminal Server and use the same front end; there are
about another 10 users who run a copy of the db on their local machine.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

The 10 users who "access the front end via Terminal Server and use the
same front end" should NOT use the same front-end. Each user should
have a separate work folder with a COPY of the front-end in that folder.
When they log into the TS they should be automatically starting in
their work folder. More than one user opening the same front-end is
inviting corruption.

For the non-linking table. You can use a DNS-less connection string.
Go to this site for examples of DNS-less connections:
http://www.connectionstrings.com/

The advantage of a DNS-less connection is that it "points" directly to
the data location w/o having to rely on the "correctness" of the DNS
file on the local computer.
--
MGFoster:::mgf00 <at> earthlink <decimal-point> net
Oakland, CA (USA)

-----BEGIN PGP SIGNATURE-----
Version: PGP for Personal Privacy 5.0
Charset: noconv

iQA/AwUBQwJPi4echKqOuFEgEQJgowCfbvqvlVsYZ1dpY9LJDAF3q7 dcm9IAniWa
Li8nJehLxmbU5WsrePvFx42x
=IkhD
-----END PGP SIGNATURE-----

[EJO]

Thanks for the connection string info, i'll give it a try.

But if you don't mind i'd like to hear more about ts running access. I
went to MS kb and didn't see any articles even generally hinting to a
problem doing so, with the exception of an unattended system account
running the db. I also didn't see many ts questions in the ng with the
exception of connecting accross a wan and similiar. This is the first
time I've looked for ts with regard to access...

When the ts users run the db, a copy of the mde is made in the same
directory as db1.mdb, db2.mdb, db3.mdb, etc. The only problem I have
had with this is that the copies are not removed when the users close
or logoff. In the 4 years my workgroup has worked like this, noone has
reported data loss that a source/cause was not identified.

Under what circumstances is data loss likely to occur? Though the
chances of users being in the same record is fair, the back end server
side locks at the column level seem to work well. Are there other
issues? Perhaps with code in the database? (I don't have any modules
other than what is behind the forms themselves.)

Win 200 Server (running TS), all updates
Access 2000 from Office SR1, don't remember which updates
no known jet service pack

[MGFoster]

EJO wrote:

Thanks for the connection string info, i'll give it a try.

But if you don't mind i'd like to hear more about ts running access. I
went to MS kb and didn't see any articles even generally hinting to a
problem doing so, with the exception of an unattended system account
running the db. I also didn't see many ts questions in the ng with the
exception of connecting accross a wan and similiar. This is the first
time I've looked for ts with regard to access...

When the ts users run the db, a copy of the mde is made in the same
directory as db1.mdb, db2.mdb, db3.mdb, etc. The only problem I have
had with this is that the copies are not removed when the users close
or logoff. In the 4 years my workgroup has worked like this, noone has
reported data loss that a source/cause was not identified.

Under what circumstances is data loss likely to occur? Though the
chances of users being in the same record is fair, the back end server
side locks at the column level seem to work well. Are there other
issues? Perhaps with code in the database? (I don't have any modules
other than what is behind the forms themselves.)

Win 200 Server (running TS), all updates
Access 2000 from Office SR1, don't remember which updates
no known jet service pack

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

It's common knowledge amongst experienced Access developers that the
same front-end should not be used by many users at one time. If TS is
making a copy of the front-end per user then there shouldn't be a
problem. My suggestion of making a work folder & placing a copy of the
front-end in that folder, essentially, does the same thing as TS is
doing automatically; it just makes a permanent copy that the users
preferences, if any, can be saved in.

BTW, Access can only lock at the row (record) level not the column
level.
--
MGFoster:::mgf00 <at> earthlink <decimal-point> net
Oakland, CA (USA)

-----BEGIN PGP SIGNATURE-----
Version: PGP for Personal Privacy 5.0
Charset: noconv

iQA/AwUBQwOFuoechKqOuFEgEQL/dQCg4Ao1F1VLU07vYH46TGJNlW24NNUAn3YF
V8Tq3ucTdogf35Hi/MniblMp
=OPni
-----END PGP SIGNATURE-----

[EJO]

Thanks, MGFoster...

I made a seperate post of this hoping to get some input from several
people, please don't be offended--i have gotten far too much assistance
in this group to intentionally offend someone.

For user preferences, I haven't gotten that far yet, and noone has
asked for anything that would necessitate doing so. But, that could
change...

Thanks, again!