Changes to multi-user app after splitting?

[CW]

I have built a database that is going to be used by 6 persons, running the
back end on a SBS 2000 server.
I have read a fair amount about splitting, which everybody seems to say is A
GOOD THING to do.
Question: once I have done the installations and the splitting, and
everything is installed and running, if (no, when) I make changes to anything
(for example the layout of a form, or if I add another field to a table) do
I just do the update once and it will be seen by everyone?
What are the types of change that DO have to be done individually, locally
at each PC?
Many thanks
CW

 

[Douglas J. Steele]

Nothing should have to be done locally at each PC. All you do is replace the
current front-end MDB file with the new one.

To automate the process somewhat, take a look at the free AutoFE Update Tony
Toews has at http://www.granite.ab.ca/access/autofe.htm

 

[CW]

That's good news! Many thanks, Doug.
CW

Nothing should have to be done locally at each PC. All you do is replace the
current front-end MDB file with the new one.

To automate the process somewhat, take a look at the free AutoFE Update Tony
Toews has at http://www.granite.ab.ca/access/autofe.htm

 

[Tom Wickerath]

Hi CW,

...or if I add another field to a table...

To add just a bit to Doug's answer, if you make any design changes to the BE
database (add or remove fields, indexes, etc.), I recommend that you delete
the table link in the FE database, compact the DB, and then re-create the
link from scratch using File > Get External Data > Linked Tables.


Tom Wickerath
Microsoft Access MVP

http://www.access.qbuilt.com/html/expert_contributors.html
http://www.access.qbuilt.com/html/search.html
__________________________________________

 

[Chris Mills]

Hi Tom,

Not to be controversial at all (and I don't know), but I'm interested in this
because obviously it affects most all linked databases.

Where "in hell" is such information held in the link (the data contained in
the link)?

Regards
(also, I've never had an opportunity to congratulate you on becoming MVP. Be
assured, I ask because I often don't understand sufficiently)
Chris

 

[Tom Wickerath]

Hi Chris,

Here are two references that I've found in the past:

Michael Kaplan has posted the following:
"One thing you can look at is the deletion/recreation of links. I have been
amazed at how much stuff gets cached in the links for tables, and also how
much of what is cached is based on usage patterns (so that if the two users
make use of a link two different ways, the info might be different). Deleting
and recreating the link can often resolve these weird cases.

http://www.granite.ab.ca/access/splitapp/details.htm

and
(ACC2000 Optimizing for Client/Server Performance
http://support.microsoft.com/?id=208858

includes the following quote, under the topic heading "Linked Tables and
Views":
"NOTE: If you make changes to fields or indexes on the server, you must
relink the remote tables in Access."

Given that Access 2000, 2002, 2003 and even 2007 for .mdb format are all
based on the JET 4 database engine, I think it is a pretty safe bet that this
article applies to these versions as well, and is not simply limited to
Access 2000, as the title indicates. That's why I added the parentheses
around the Access 2000 part in the title. If I had to place bets, my guess is
that Access 97, based on JET 3.5x, is also affected in a similar manner.

I have seen the importance of this first-hand. I once helped a co-worker at
my place of work fix a query that was obviously returning the wrong results
when one compared the SQL statement to the data in the table. The *only*
thing that I ended up needing to do to get the query to start returning the
correct results was to delete a linked table and re-create it from scratch.
I'm just assuming that the compact step should be carried out after deleting,
but before re-creating the link. I don't know for a fact that it is required,
but it's not a bad idea to do this in any case. As they say, YMMV.

(also, I've never had an opportunity to congratulate you on becoming MVP.

Thank You.


Tom Wickerath
Microsoft Access MVP

http://www.access.qbuilt.com/html/expert_contributors.html
http://www.access.qbuilt.com/html/search.html
__________________________________________