Still not getting much feedback on this one, but I am going to keep posting, partly in the hope that it will one day be of use to someone else, but I also have a specific question for Mike, John and Sally (of which more later).
So at present we still have two installations of R6, both on the latest version, running on separate fileservers, but which are becoming increasingly out of step as we are still entering data into the old one (I will backup and restore to the new one once we have got the new installation running as it should.
The old installation uses the older copy of the database under SQL Server 2000, this now works on only three of our workstations, two running Windows 7 and one XP. These are the machines I haven't touched yet and our "live" database.
The new installation has a copy of the same database under SQL Server 2012. On two XP workstations we have remapped the drive assignments so the Z: drive points to the new fileserver and uninstalled and reinstalled workstation software, using the copy of WorkstationSetup.exe also on the new fileserver. These did both function correctly for a while with the new db, but now neither work ('Error accessing the OLE registry').
Two further workstations running Windows 7 have been treated in exactly the same way. One will not run R6, crashing on start-up with the '%1 can't be found' error described above. If we turn off Kaspersky entirely it functions normally, but disabling all the individual components of Kaspersky, including the firewall does not work. The second used to behave the same way, but now has a different error instead (not being able to access the OLE Registry).
We also have R6 workstation installed on a remote access terminal running Windows Server 2008 R2. This was the first one we tried to fix and it worked almost straight away (or at least appeared to) without errors. However it transpires that it sees only the old copy of the database, despite being installed using the WorkstationSetup.exe on the new fileserver.
If this was not confusing enough, I have now found that on the first Windows 7 machine described above, if I navigate to the new fileserver and double-click either Recorder.exe, or RecorderApp.exe (rather than using the desktop icon created on install), I get the %1 error, but if I navigate to the OLD fileserver and do the same R6 opens normally, but sees the NEW copy of the database.
Clearly we have a problem with something to do with the drive mapping, or the local registry entries. Whatever the problem is, it manifests in a way which is dependent on some basic part of the Kaspersky software, but Kaspersky are unable to find anything untoward on our system.
So my question to Mike, John and Sally is as follows: Can any of you explain to me what actually happens when we run WorkstationSetup.exe? How does the installer decide which SQLServer instance to use and where does it get the various path settings for the registry? Also how good is the uninstaller at removing old registry settings and how does it recreate the HKEY_LOCAL_USERS keys for each new user.
As an illustration of the problem, our ITC just uninstalled the workstation from the remote access terminal (Windows Server 2008 R2), then reinstalled it (as administrator), it performed exactly as you would wish and opened correctly with the new db. But when I try to open recorder on the same machine (not as admin) I get an error (Map Files Path setting incorrect or missing, we get this often with new installs). On checking the settings keys in HKEY_LOCAL_USERS (I am now the user), most of the path settings (which should begin Z:/, the path to the new fileserver R6 folder), actually begin with \\wwt-sql01\, which is the path to the OLD fileserver and clearly date from a previous install. So it seems to work for the person who installed it, but not for anyone else.
Still on the remote access machine we have now uninstalled the workstation software again and are attempting to run a registry cleaner to remove references to earlier installs. Next we will try to reinstall again. Will it work? I am not all that hopeful.
Rob Large
Wildlife Sites Officer
Wiltshire & Swindon Biological Records Centre