I had so many problem with this one, I worked on this problem for hours, called QB tech support but no answer, just the regular spin on do this and that until I found this.
Server-hosted install: Windows Server 2012 R2
Share: \\ServerName\QuickBooks mapped to P:\
Note: The server had TWO functioning Ethernet adapters (192.168.0.7 & .8 in IPv4 and two other addresses in IPv6 space)
Workstations: All Windows 7
Lots of problems with multi-user. The server’s DB manager would lose its state management of the company file. Workstations couldn’t find the server and would attempt to re-config the .ND/.DSN files in place on the server share. Some users couldn’t connect to server using P: drive–decorated mappings but could with \\ServerName\Quickbooks–related paths.
Observed that if I delete the .ND file then QuickBooks will use IPv6-related addresses for the server and mark this in the new file. It then would fail connectivity to the server. I’d call this a bug.
Observed that there appears to be code within QB that sometimes uses NetBIOS-based name resolution and sometimes uses DNS.
Observed that the workstation would get a connection to the server, I’d press F2 and see that it’s finding the server on the first Ethernet adapter. I’d then switch to single-user mode and now the workstation was attached to the second Ethernet adapter. This could be causing the QuickBooks DB manager a problem in tracking state. Each time, it would update the .ND/.DSN files with the newly-found IP address.
- Created desktop items for all users straight to the QBW company file. Used double quotes to surround paths (given the space character in “Company Files”). Used UNC-style paths rather than drive letter–style.
- Disabled the second Ethernet adapter on the server, reconfigured DNS to only use this one adapter to resolve the server name.
- Marked both QB-related services on the server to automatically start.
- Manually edited the .ND and .DSN files with the correct IPv4-based IP address, replacing the IPv6-based address or the one associated with the secondary Ethernet adapter. Did this for both the “Company Files.ND” & .DSN in the parent folder as well as the company file–named versions in the Company Files folder itself. Important: Also, I verified that paths were drive letter–based and LOCAL to the server rather than to the workstations.
- Rebooted the server.
- Ran the Quickbooks DB manager again on the server and scanned the folder.
- Ran QuickBooks from the first workstation as Admin, verifying that the “run in multi-user mode” option is checkmarked from the Open Database button.
- Pressed F2 to verify that the server’s IP address is 192.168.0.7.
If someone gets an H202 error and then begins to “fix” the problem under Quickbooks’ guidance… it will corrupt the .ND/.DSN files with file paths which are workstation-centric rather than server-centric. This then seems to confuse the QB DB manager which then screws up state management for single- versus multi-user. One should only run the repair tool from the server so that file paths then are server-centric.
Also, when running the repair tool I was notified on two attempts that the file was hopeless and that I ought to restore from backup. I chose not to do this and was able to fix it as stated above. So I could have lost hours’ or days’ worth of work by trusting the repair tool.
Keywords: H101, H202, single-user, multi-user, server, Enterprise Solutions 2015, unrecoverable error, Company Files.DSN, Company Files.ND, UNC, drive mapping”