Moving database from Windows 98 to Win2K Server

[alanknipmeyer]

Hi,

I`m in the process of migrating a Access 2002 (Run in 2000 mode) from
Windows 98 to Win2K Server. It is a shared resource via a file share on
the 98 Server. Client systems are Win98 with the shared drive mounted
and the application run via the shared drive.

I have tried once before, but came across some file locking issues. I
thought i had addressed these file locking issues, but it came apparent
I hadn't when data started to get lost, quick roll back and much red
faces !

I`m sure there must be a way to run Access 2000 database from Win2K
Server as a share whilst allowing many users to access it at the same
time and update the data.

In the Advanced section I can see various features, i.e. Default mode
'Shared' or 'Exclusive', I would think this would need to be shared.
In Default record locking i have 'no locks' enabled, edited record
would make sense to me, to stop two users over writing the edited
record.

My problem seems to be more Win2K Server based, as I`m migrating the
mdb as it was from Win98, or am I over simplyfing the problem.
Many thanks in advanced,

Alan K.

[Allen Browne]

Make sure you have at least SP3 for Win2k. There was an issue with
opportunistic locking in Win2k.

Just as importantly, split the database so that each user has their own copy
of the front end, the the attached tables in a shared mdb on the server.
Details:
http://members.iinet.net.au/~allenbrowne/ser-01.html

--
Allen Browne - Microsoft MVP. Perth, Western Australia.
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.

<al***********@ yahoo.com> wrote in message
news:10******** **************@ c13g2000cwb.goo glegroups.com.. .

I`m in the process of migrating a Access 2002 (Run in 2000 mode) from
Windows 98 to Win2K Server. It is a shared resource via a file share on
the 98 Server. Client systems are Win98 with the shared drive mounted
and the application run via the shared drive.

I have tried once before, but came across some file locking issues. I
thought i had addressed these file locking issues, but it came apparent
I hadn't when data started to get lost, quick roll back and much red
faces !

I`m sure there must be a way to run Access 2000 database from Win2K
Server as a share whilst allowing many users to access it at the same
time and update the data.

In the Advanced section I can see various features, i.e. Default mode
'Shared' or 'Exclusive', I would think this would need to be shared.
In Default record locking i have 'no locks' enabled, edited record
would make sense to me, to stop two users over writing the edited
record.

My problem seems to be more Win2K Server based, as I`m migrating the
mdb as it was from Win98, or am I over simplyfing the problem.
Many thanks in advanced,

Alan K.

[Brian]

"Allen Browne" <Al*********@Se eSig.Invalid> wrote in message
news:41******** *************** @per-qv1-newsreader-01.iinet.net.au ...

Make sure you have at least SP3 for Win2k. There was an issue with
opportunistic locking in Win2k.

But beware SP4 if it isn't already installed. I know from personal
experience that the issue described here:

http://support.microsoft.com/default...b;en-us;839517

is a severe PITA if you encounter it, especially if no-one knows the
Administrator password (the recovery console requires THE Administrator
password, not AN Administrator password)! Once you are in that hole, the
only way out is a complete parallel installation of Windows.

[alanknipmeyer]

I am very grateful for your responses ! I shall setup a 'sandpit'
server to start with with the split as detailed in Allens excellent
reference document, and ensure that windows update is complete upto the
latest release as recommend by Brian.

If I experience any problems or it all goes amazingly well, i`ll
respond to my thread to let people know that they can use this as a
reference.

Many thanks guys !

Al.

[alanknipmeyer]

Well I havnt put together a test plan yet, but its looking good. The
database/split procedure seemed to do its buisness and i now have
linked tables within Access.

Can I please clarify one point tho ? When I split the database, I`m
left with the .mbd file which is still the same size and the back end
tables. When it comes to distributing the .mdb can I put the newly
split database .mbd file onto a file share, copy it to each desktop
from which it will find the network path to the back end tables (all
the drives are mounted as the same system/partiton to the back end
tables) ?

I am going to test this out tommorow, but it would be good to have the
advice of an 'expert'.

Also as an aside, is there a good reference for 'testing' access
databases, i.e. stress testing (like the way I would a webserver, i.e.
can take 10^n hits==10^n querys per <time>, this query takes this nn
llong,etc)
Many thanks in advance for your kind assistance.

Regards,

Alan K.

[Tony Toews]

al***********@y ahoo.com wrote:

Can I please clarify one point tho ? When I split the database, I`m
left with the .mbd file which is still the same size and the back end
tables. When it comes to distributing the .mdb can I put the newly
split database .mbd file onto a file share, copy it to each desktop
from which it will find the network path to the back end tables (all
the drives are mounted as the same system/partiton to the back end
tables) ?
Yes, assuming the FE MDB uses a network share or share drive letter to link to the
backend MDB. If, OTOH, you are running the FE on the server and you are linking via
C:\etc then the FE MDB will not be able to find the BE MDB on the server.

I specifically created the Auto FE Updater utility so that I could make changes to
the FE MDE as often as I wanted and be quite confident that the next time someone
went to run the app that it would pull in the latest version. For more info on the
errors or the Auto FE Updater utility see the free Auto FE Updater utility at
http://www.granite.ab.ca/access/autofe.htm at my website to keep the FE on each PC up
to date.
Also as an aside, is there a good reference for 'testing' access
databases, i.e. stress testing (like the way I would a webserver, i.e.
can take 10^n hits==10^n querys per <time>, this query takes this nn
llong,etc)

Not that I can recall. I do have a similar utility for stress testing a server to
see if Access can corrupt an MDB but that's not the same thing.

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

[alanknipmeyer]

Dear fellow access users,

Many thanks for all the assistance in the above threads. I can report a
very pleasing 'ok' on using the split procedure tool from within
access. I will be using the AutoFE tool, which looks brilliant to
update the FE clients.

To reitirate here was my goal and the procedure used to get there :-

Goal :- To split access from one single system which loaded via a
public share. The requirment came apparent as this was a 'desktop'
system which had a very important access repository on it. If any
hard-disk or part of the system was to fail, only recovery from backup
was possible and then onto a machine which would have to be made
available. Alot of network traffic was also used in each desktop system
loading the entire application across the network.

This led to thought I should split the database onto our well specified
back end server (Dell PE2450 DualPIII900, mirrored C:\, RAID5+1 all
other data, automated backups onto dds3) and have the front end on each
client. This would also enable me to update the FE client without
having exclusive access to the database.

How accomplised :-

1) I first backed up the database from the system it was ! This was
multiplebackups , one tape, 3rd system hard-disk and remote system
backup. I knew then if it all went wrong I had a backup to recover to.

2) I created a new directory called 'Database' on the Raid5+1
filesystem, i named the share. 'Database'. I copied the current
database onto the new fileshare.

3) I unmounted the old fileshare from each CLIENT system and remounted
the new Database share in the same place.

4) I ran the database from the new share. I than the run the split
wizard, putting the back-end tables onto the share i.e.
mydatabase_be.m db.

5) On the client system i created c:\DATABASE. I copied the front end
into this directory.

6) I created a directory on the backed system called 'DISTRIBUTE' this
contains the database to install on other machines, and will no doubt
come in use when running the auto-fe tool.

7) I went to each other front end system and created a C:\DATABASE
directory and copied the my_database front end from DISTRIBUTE. I
opened up each database in tern leaving it open and seeing that the
tables where linked.

8) (not essential step, but useful) I am lucky enough to be using a
Cisco switch with a Netra T1. I setup SPAN (Switch Port Analysis) and
monitored the traffic going through the switch on the backend. I could
measure the amount of traffic used and the 100MbFDX we are using is
more than adequate for the clients we have, this will help ensure there
is no dataloss or corruption from the internal network.

9) I ran thru the database test procedure, i.e. testing the database
done what it was supposed and as it was before prior to the split.

10) I wrote this and had a beer :)

again many thanks for everyones help. I really like the newsnet
community and I hope that my work goes towards furthering the
generosity and application of those people who geninually wish to help
each other.

Regards,

Alan Knipmeyer