Acc2003 database wont run on new XP PC

[dazadd99]

Hi Guys,

I have spent many nights and days on this forum, learning about Access.
With the community help, examples and problems solved, I finally managed to complete a Database that runs a charity stock control and sales function.

Currently it is used by 3 users over a network.
A central PC hosts it on a Fileshare (as an .mdb file) and the others connect to it via shortcuts to mapped a drive (W; is mapped to the host PC fileshare)

All worked well.

A new XP Pro PC was put in place as the Host PC. Setup was mirrored and worked fine for 2 days. On the 3rd Day the user put a password on the XP profile to secure the PC, and the database began to misbehave only on the New host PC. The other PC are still working fine.

I am unable to run any reports (some have VB in for .has no data).
I am unable to run one of the core scheduling forms which uses Allen Brownes excellent Calendar (the one with the highlighter).
But the strange thing is that I cannot even enter design mode on the form.
Just does nothing, no errors, no prompts.

Copied database to another PC and it all runs fine. Problem is isolated to this new PC. Checked VB references, ran Office updates to SP2, but still no difference.

Would anybody have any suggestions for a way forward??

PS, Thanks to all moderators and experts for excellent work on this forum.

Dazadd99

 

[ghudson]

Sounds like there are missing references and maybe the users do not have full file permissions to the directory where the db file is located on the new PC. Search around the forum for both of those topics have been discussed in numerous threads.

 

[dazadd99]

a bit more info

I had read a previous post about the references which recommended remove and reapplying them. So I removed all references on the host machine and then reapplied them to match the main development version on my PC.
This made no difference.

Also: The database is hosted on this new PC but doesn't work only on this new PC. I do not use the Access security & groups, but rather preferred the Login utility I came across on this forum. (I think it might have been posted by you actually ghudson)!.
The other users have full functionality.

As for the permissions idea - some forms will run. (All forms have vb code in them). So I had discounted that.
As the folder in which the mdb files resides is shared using windows sharing, I would have expected the permissions to be full for the PC that hosted it.

Any more ideas??

I was about to recommend a re-install of Windows and then Access to see if this made any difference......A bit extreme .....?

Many thanks

dazadd99

 

[The_Doc_Man]

Not FORMS permissions, which is an Access thing, but Windows permissions, which is a file-system thing, may be your problem.

When you changed out the server, you changed System IDs for the users hosted on the server. Not the last part of the SID, but the FIRST part, which is somehow part of your host system's Microsoft license number. Your access control lists are by SID, not by name, so recreating the name doesn't always reproduce the SID exactly.

Try getting into the properties of the folder where the MDB is kept. See if you have some "unknown" users. If so, these are the "leftover" users from the previous installation. You might have to remove and regenerate the ACL entries.

 

[dazadd99]

Thanks for your thoughts...

question:
When the new host PC was put in place and the database installed on to it the database worked perfectly for 2-3 days. Then after the profile password was created, the database became inoperable only on the HOST pc. the other networked pc continued and still are working fine.

Do you still think it could be a windows sharing problem??

In the meantime I will investigate the sharing permissions for these "leftover" SID's.

Many thanks again
Daz.

 

[The_Doc_Man]

Admittedly, if it worked for a while before failing, that makes it confusing. The question is, what happened just before it stopped working.

A reboot is a common event that "eats your socks" for you. Particularly if you have made changes to a system, some of them are not effective until the next login or next reboot, because they are related either to System Startup events or User Login events. The former events are part of the registry LOCAL_MACHINE hive, the latter are part of the CURRENT_USER hive. So if a login/logout or a system reboot occurred just before things went crazy, it was a registry change that caused it and a registry evaluation that actually triggered the effect you saw.

 

[dazadd99]

Thanks for the info....

Rather than trying to fix the registry entries, do you think it's now best to uninstall / reinstall Access to try to get the registry returned to its correct settings??

Thanks again

DAz.

 

[The_Doc_Man]

Might not be something that Access set. Don't have a clue as to how to answer you in this case. You need to find the event that preceded the first failure.

 

[dazadd99]

Problem resolved

Hi,

As the database was in use at a remote location, it made it difficult to solve the problem remotely.

As it happens their IT guy was appointed to do some maintenace work and the problem was mentioned to him. It turns out that he seems to know Access really well too.

The problem was down to the default printer being a wireless connected printer. He had seen this problem before and connected the printer directly to the problem PC and "voila" problem went away.
He stated that when Access opens a form the first thing it does is too check for the default connected printer - failure to connect results in the runtime error 2501 .

Fancy an attempt at elaborating on this or a way around it other than direct connect a printer.

Regards
daz.

 

[The_Doc_Man]

OK, at least I know WHY it worked as it did. In order to properly print a form or report, Access has to look up the printer in question to get the sizing right for how many pixels it has to muck about on the printed form/report. This is because it needs to compute the size of a TWIP. (You can look that up in the help files.) If you can't compute TWIP size, you are screwed.

I'd heard of that before, in fact ran into it once, but with radically different symptoms. Glad you have an answer that makes sense.