0

Some background:

I'm a programmer, not a network administrator, who has been asked to migrate some accounting software (Integrated Office Accounting version 3.2) from an existing domain (OLD_NETWORK) to a new domain (NEW_NETWORK). No-body at the office knows how it works under the hood. It is a split Access 2000 database with the back-end shared and on a file server (which is also the DC) using mapped drives. The DC is NT Server 4 SP 6. The new server is server 2003. The two networks are running independently (ie: two computers on each desk).

I have been able to get new computers set up on NEW_NETWORK and working with the IOA software just perfectly but for one problem: The company here uses other entirely separate databases which access the tables IOA maintains (specifically the 'customers' table) via links. To switch between these systems, you press F11 then File->Open the appropriate database and away you go (this is necessary to maintain the permissions that the IOA system uses to protect the customers table).

The entire database is Access 2000, the links go to other Access databases, SQL-Server is not involved in any way, nor is a migration to SQL server likely. If I can't migrate anything over, everything will stay as it is, and the NEW_NETWORK computers will not be used.

The problem:

When I try and update these seperate databases (I shall call one "BANK_ACCOUNT", but the name does not matter), it says "this recordset cannot be updated". It also will sometimes not pull information out of the 'customers' table (ie: date_entered) when looking at a report of everyone who opened a bank account on a certain day (ie: today).

I have tried:

•Giving 'everyone' full control via. shared directory permissions
•Giving 'everyone' full control on a file system level
•Checking the permissions within Access (everyone has full read/write on all tables)
•Copying the entire server contents from one file server to another (ie: xcopy everything)
•Copying the entire local client files from one computer to another, putting them in the exact same position in the file system, with the same permissons (or full control to 'everyone').
•Running as an Administrator
•Taking one of the NEW_NETWORK computers, having it join OLD_NETWORK and run the software (direct copy from a working system with identical drive mappings), this did not work
•Weeping openly
My Question:

Is there anything else I can try?

(sorry for this being so long)

3
Contributors
2
Replies
3
Views
7 Years
Discussion Span
Last Post by dmarino1
0

I have dealt with these kinds of issues often in the past.

Please contact me at [removed] to discuss this in more depth.

Thank you,

Neal Miller
President
Miller Systems, Inc.
[email removed] (the underscore character is to foil spammers, please omit)


Some background:

I'm a programmer, not a network administrator, who has been asked to migrate some accounting software (Integrated Office Accounting version 3.2) from an existing domain (OLD_NETWORK) to a new domain (NEW_NETWORK). No-body at the office knows how it works under the hood. It is a split Access 2000 database with the back-end shared and on a file server (which is also the DC) using mapped drives. The DC is NT Server 4 SP 6. The new server is server 2003. The two networks are running independently (ie: two computers on each desk).

I have been able to get new computers set up on NEW_NETWORK and working with the IOA software just perfectly but for one problem: The company here uses other entirely separate databases which access the tables IOA maintains (specifically the 'customers' table) via links. To switch between these systems, you press F11 then File->Open the appropriate database and away you go (this is necessary to maintain the permissions that the IOA system uses to protect the customers table).

The entire database is Access 2000, the links go to other Access databases, SQL-Server is not involved in any way, nor is a migration to SQL server likely. If I can't migrate anything over, everything will stay as it is, and the NEW_NETWORK computers will not be used.

The problem:

When I try and update these seperate databases (I shall call one "BANK_ACCOUNT", but the name does not matter), it says "this recordset cannot be updated". It also will sometimes not pull information out of the 'customers' table (ie: date_entered) when looking at a report of everyone who opened a bank account on a certain day (ie: today).

I have tried:

•Giving 'everyone' full control via. shared directory permissions
•Giving 'everyone' full control on a file system level
•Checking the permissions within Access (everyone has full read/write on all tables)
•Copying the entire server contents from one file server to another (ie: xcopy everything)
•Copying the entire local client files from one computer to another, putting them in the exact same position in the file system, with the same permissons (or full control to 'everyone').
•Running as an Administrator
•Taking one of the NEW_NETWORK computers, having it join OLD_NETWORK and run the software (direct copy from a working system with identical drive mappings), this did not work
•Weeping openly
My Question:

Is there anything else I can try?

(sorry for this being so long)

Edited by Ezzaral: Removed contact info. Please keep discussion on site.

0

couple things may need to be done. make sure your two domains TRUST each other correctly. Your IT group should know about this. If the trust is not set correctly, your databases will not talk. Also, did you go back and re-link the tables to the front end of the database? If I read your message, you stated it was split. Moving from one domain to another will cause the links to break. Re-do the links by running the link table option in Access under Database Tools. Once your TRUST and Links are reset, you should be ok, providing the permisisons are set correctly as well. You also need to make sure the location of the backend is set to change for the users who have access, otherwise they will not be able to update the tables. Good luck.

This topic has been dead for over six months. Start a new discussion instead.
Have something to contribute to this discussion? Please be thoughtful, detailed and courteous, and be sure to adhere to our posting rules.