Accounting application struggles in Windows 10 (Mapped Network Drive)

Hello,

we are an accounting company using one program for almost 15 years and we are very satisfied.

Network work is a bit specific, but it works (worked?!) fine until recently. Program is installed on the "server" (just another computer in the office) and it is run on the clients just by mapping a server's disk drive and creating a program shortcut on the client.

This program uses Access database! I think this is important part of the problem.

Network is gigabit, all PC's are almost new. Network works perfectly! All computers until couple of days ago were Windows 7/8 and accounting program also worked perfectly... IP's are static, drivers are mapped via IP address.

Couple of days ago we bought 2 new computers and obviously Windows 10 Pro x64, and now we have a problem with this software that is seriously affecting our work. The problem is simple: when creating a document (invoice or similar) and saving it - saving takes 2-3-4 minuts.

During this 2-3-4 minutes:
- network is operating normally
- ping from client to server is 1ms
- file transfer from client to server is 100 MB/s
- all permissions are OK
- mapped drive is visible and accessible

The problem is present only on the clients. On the host all works perfectly. Windows 7/8 clients also work perfectly. Only problem are Windows 10 clients. I see that many users of this program has the same problem on Windows 10, but the producer/programer has very bad support.

I have tried almost all solutions from the Internet (enabling/disabling SMB1/2, registry tricks, windows 7/8 compatbility mode on the client, etc.).

Any ideas? Please do your best :)

p.s.
Thanks on your patience

Also, what is the program, Peachtree [now SAGE], QuickBooks Pro or another?

Keano,

I have experience of helping people with Access-based databases such as yours.
- This kind of accounting package was always claimed to be superior because it was tailored to the needs of the particular customer. Such claims were always false. Sage & the other mainstream accounting packages have always been easy to tailor to an individual organisation's needs.
- This database was designed a long time ago & has not been maintained by its author.
- Your database might or might not confirm to modern data protection regulations. Access database privacy & security have always been regarded as inadequate.

One of the other posters might have sufficient networking skills to help you with the current problem but, in the long term, you will change over to Sage or one of the other well-established accounting packages because you will end up having to.

So expend all the effort you want on the current issue but, given the inevitability of an eventual transfer to Sage etc, why not devote your energies to that permanent solution now instead?

I wish you well & I hope you do not mind me being so blunt,
Denis

Keano,

The .mdb extension is what told me it had never been maintained by its author. If it had been maintained beyond 2006 it would have been .accdb.

Is it really a networking issue?
- All you know for sure is that there is a networking symptom.
- Nobody knows what old WinXP references are buried inside that database.
- It could be using a particular dll or some other reference file.
- It would be referring to it as it existed in WinXP.
- Win7 might have had an updated dll that could cope with being quizzed as if it were the WinXP version.
- Win10 might now have dropped all attempts to maintain compatibility with WinXP versions.
- Your older computers might have earlier versions of the dll that get left in as newer versions are introduced by Windows updates. [The OS is not defined solely by its Version.Build but also by its update history]
- Your new computers might have only the very newest version of the dll. And it might not know what your database is talking about.

If you downgrade to Win8 you will also need to get hold of and test Win8-compatible drivers for the hardware.
- You'll only find out if the downgraded computers work well with the database afterwards.
- You'll do a lot of work and only know if it is successful at the very end.
- Even if it is successful it might take more effort than it deserves.

Do consider altering your working practices instead.
- Perhaps only those with older computers should do the printing.
- Such a workaround might cost you less than reverting the new ones to Win8.
- And you can invest the difference in Sage training.

Denis

Keano,

I also have one very stupid idea.

You'll need to make a system image before you start and to check activation of your OS is with a digital licence [else check you have written the activation code down safely].

Identify the latest OS that your database has worked correctly with over your network.
Downgrade to that OS.
Install & test the database.
If necessary to get the database working over the network, get the bare minimum of older drivers.
Upgrade to WIn10 again.
Test the database.

The remnants left over within the re-upgraded OS might be enough to let the database work.
- And you might not have to mess about getting hold of any old Win8 drivers at all.

Denis