Split Database Problems

[Guest]

I have an existing database that I tried to split into a FE and BE. I took
the existing DB and copied it, deleted the tables from what would become the
client and linked this new client back to what I termed the AuditMain. I
also took all but the tables out of the main database (Main lives on server,
FE on workstations--not shortcuts I checked that). I have no problems with
the auto-update of the client to the desktop. My problem is very basic, but
I can't seem to find where I possibly went wrong.

It worked fine for me as I tested the process. The problem is no other user
can connect with their client. Access just kicks into "not responding".
Have I missed a setting somewhere? My structure is: AuditMain(tables only,
on server), AuditClient(on workstation in c:\documents and settings\all
users\desktop). I also have a AuditClient master copy on the server which,
after changes are made, copies to workstation if version numbers are
different via an updating database.

 

[Joan Wild]

I have an existing database that I tried to split into a FE and BE.

It worked fine for me as I tested the process. The problem is no
other user can connect with their client. Access just kicks into
"not responding". Have I missed a setting somewhere? My structure
is: AuditMain(tables only, on server), AuditClient(on workstation
in c:\documents and settings\all users\desktop).

This all sounds fine to me. Are the frontends linked to the backend via UNC
or a mapped drive (Go into the Linked Table Manager, select all the tables,
put a check to specify a different location - Use Network Neighbourhood to
browse to the backend). That will use UNC mapping, and you don't have to
rely on users having a correctly mapped drive.

Ensure all users have create/delete permissions on the folder where the
backend is located. Also there have been reports of problems if the backend
is put too deep in some folder tree - try moving it closer to the root.

 

[Guest]

A curious thing happened. I opened the client database and then tried the
link manager and the window is blank. All tables in the database window show
as linked with the little arrow next to them but none show up in the link
manager window.

As for UNC, I was not sure when I started this how to make the coding accept
it, although it does take the drive mapping. The server it is on is the main
one for the company and is "force mapped" as letter G so I am "safe" that
way. I have tried this on multiple machines and verified the mapping. I
have also verified access to the folder/file and that is clear.

As for the location in relation to the root: the unc would be
\\server\DATA$\AuditDB\the mdb files. The users when the browse the G (this
server) drive see the folder AuditDB...as I see it, it is two from the root
at the most. I was concerned to place it "folderless"--I just did not want
it in the open.

I forgot to add this database does have a sign on routine. The sign-on is
picking a user name and entering a password. The OK button runs code that
matches the user and password to data in a table. This table is also linked
back to the main from the FE. The FE is set to open with this form

I have discovered it does open...but it takes quite a while as in 5 minutes
wait. Any ideas on what could cause such a delay?

 

[Guest]

UPDATE: It will not open on multiple machines. I botched my test and
reported incorrectly in my previous post. (My machine and my test are in
different rooms and I had inadvertently closed mine and when I did the other
one popped right open.)

I also noticed that the FE will create an .ldb on the workstation. I
assumed this to be a correct occurrence, yes? And, the BE will show and .ldb
in its folder once the client connects. I assumed this was logical also.

And I thought everything was going just ducky--was with my testing--until I
moved to testing with multiple users. So much for fielding this by Monday...


What prompetd all this, BTW, was the fact that this was a database accessed
by 40+ folks on a regular basis and was slow and locking often. We want to
move to SQLServer (my recommendation but not purchased yet and not in near
future). Original DB was locked or slowed so productivity was suffering so I
tried to split it (a copy of course).

 

[Joan Wild]

I also noticed that the FE will create an .ldb on the workstation. I
assumed this to be a correct occurrence, yes? And, the BE will show
and .ldb in its folder once the client connects. I assumed this was
logical also.
Yes.


What prompetd all this, BTW, was the fact that this was a database
accessed by 40+ folks on a regular basis and was slow and locking
often.

You should have a look at
http://www.granite.ab.ca/access/performancefaq.htm
for some possible remedies.

Are you using Access 2003? Re-register accwiz.dll (the one located in the
same folder where Access 2003
is installed)

Regsvr32 "path\ACCWIZ.DLL"
See
http://support.microsoft.com/?id=835519
If that doesn't work, then change the following registry key
HKey_Classes_Root\TypeLib\{5B87B6F0-17C8-11D0-AD41-00A0C90DC8D9}\8.0\0\win32
\(Default)

It needs to have the correct path to
C:\Program Files\Microsoft Office\OFFICE11\ACCWIZ.DLL

 

[Guest]

Tony's site had the answer! All it took was a dummy table, a dummy form that
links to dummy table that opens and hides itself. Thanks for the link! It
was taking up to 5 minutes or more to load and now it is down to seconds...