1

Re: Problems with SQLServer arising from changing computer name

This is a very strange one. A long story I'm afraid.

I installed Recorder 6 on my work laptop a couple of months ago and imported data from Rec2K2, and had no real problems. UNTIL the IT support person who had set up the laptop realised it had been given the wrong name. What happens is that the machines are set up from an image disk, and initially they are given the computer name of the machine the disk image was made on (DLT238). This is supposed to be changed manually but the IT person had forgotten to do so. So, he changed it to what it should have been (DLT218). This immediately caused problems for me accessing Recorder 6 - basically I couldn't open it. This issue for SQLServer is documented: see http://www.cisco.com/warp/public/78/SQLServ_Name.html "The SQL Server name Does Not Match The Computer Name". Now, I assume (can't remember I'm afraid) that I had, during the Recorder 6 installation, left the SQLServer name as default, which was probaly then based on the computer name. Changing the computer name BACK to DLT238 generated a different error.

Anyway, at this point IT suggested I cut my losses and have the computer wiped and re-built from the image, and re-install everything. So this is what happened, with the computer being assigned its "proper" name of DLT218. I re-installed Recorder 2K2, with upgrades, copied my Nbndata.mdb back in, installed Recorder 6, selecting a name for the MSDE instance of RECORDER6ADH. I applied the 6.7.2 upgrade. All looked good at this point.

Then I tried to import the R2K2 data. This seemed to run OK, but eventually an error dialog came up with "ODBC-connection to SQLServer DLT238 failed" - Note the SQL Server name!  I closed this dialog and was presented with a login dialog for the server. I logged back in (sa) and the import process started over again, ending with the same error. I cancelled out and opened Recorder 6, and it looked like most of the data had come over and things seemed to work OK. On closer inspection however it was clear some Taxon occurrences were missing.

I've uninstalled Recorder 6 and MSDE, re-installed just to version 6.6.8.59 , and tried the import again. Same problem. Under services only RECORDER6ADH is running, the appropriate Registry entry under Recorder 6 gives the SQL Server name as RECORDER6ADH, and the system tray is reporting DLT218\RECORDER6ADH running. Why is Recorder looking for SQL Server DLT238? I'm truly baffled.

Alan

2

Re: Problems with SQLServer arising from changing computer name

That is baffling. Where's it getting the old incorrect "DLT238" from? If the computer has been wiped, then there can be no reference to that name anywhere. But, for this error to be generated, there must be something somewhere that's providing Recorder with the incorrect information. Could there be something stored in in the nbndata.mdb? Have you checked the ODBC data sources in the control panel? Have you searched the registry or the rest of the computer for anything mentioning DLT238?

Charles

Charles Roper
Digital Development Manager | Field Studies Council
http://www.field-studies-council.org | https://twitter.com/charlesroper | https://twitter.com/fsc_digital

3

Re: Problems with SQLServer arising from changing computer name

A possibility is that the previous attempt to migrate the data left a linked table in the Access mdb file which was pointing to the old machine name.

John van Breda
Biodiverse IT

4

Re: Problems with SQLServer arising from changing computer name

Sounds very plausible to me. If this is indeed the case, then simply deleting the dodgy ODBC linked table(s) should solve the problem (they're the ones with the world icons next to them). Now that you come to mention it, I think I may have had similar experiences. I seem to remember having to go into our NBNData.mdb to delete (one by one!) all of the ODBC linked tables that get left in there after a transfer.

Charles

Charles Roper
Digital Development Manager | Field Studies Council
http://www.field-studies-council.org | https://twitter.com/charlesroper | https://twitter.com/fsc_digital

5

Re: Problems with SQLServer arising from changing computer name

Just picked this up again after being on leave for a couple of weeks. Deleting the ODBC tables does indeed do the trick (much to my relief - I haven't got too much hair left to pull out!). Thanks very much Charles and John.

Alan

Alan Hale
Aberystwyth

6

Re: Problems with SQLServer arising from changing computer name

Glad we could help!

John van Breda
Biodiverse IT