Trouble updating SQL driver and Named Pipes file

[NNIsarahd]

On a few machines here, we're having a hard time updating the SQL driver and Named Pipes libraries. We upgraded our server from SQL 7 to SQL 2000, and we've run MDAC 2.8 to try to upgrade the SQL drivers on the client machines. Most of the machines, the drivers upgrade fine. But a few - mostly Windows XP SP1, with the exception of a Windows 2000 machine - don't update fully. I've used to Component Checker and the same files on all of the machines aren't upgrading:

sqlsrv32.dll
dbnmpntw.dll

Has anyone else run into this problem where not all DLLs update? Any suggestions on how to get these files to update properly?

 

[ArtieChoke]

Are any apps running on those machines that have loaded those drivers into memory, like query analyzer, crystal reports, etc.?

"I think we're all Bozos on this bus!

 

[NNIsarahd]

Vista or the Crystal Reports client (for compiled reports) would be the only things locking it on the clients, and I tend to reboot to free up the memory and then do the MDAC install right after that.

 

[ArtieChoke]

Try booting up in safe mode, so nothing else is running and see if that works.

"I think we're all Bozos on this bus!

 

[NNIsarahd]

I tried this in safe mode this afternoon and the SQL driver and the Named Pipes file both weren't up to MDAC 2.8

I am able to copy a working SQL 2000 DLL to C:\Winnt\System32 and then it shows the driver as SQL 2000. But as soon as I open Vista, it reverts.

I have to wonder if part of my problem is because I cannot get the SQL 2000 DLL to register. When I do a regsrv32 on the DLL, it tells me something about how it cannot find an entry point. Could this be contributing to my problem?

Any other suggestions?

Thanks again.

 

[ArtieChoke]

You don't need to register the dll file - it's not an ActiveX (COM) object.

Just an FYI - dll files come in two flavors - COM, which needs to be registered or as just a collection of shared routines that multiple programs can use - they cannot be registered - that's why you get that message.

Do the machines that don't update all have Vista - or do other machines that work have it as well? When you say it reverts, does that mean the old version of the file is put back into the system directory, overwriting the new version? If so, sounds like you might have found the culprit...

"I think we're all Bozos on this bus!" - Firesign Theatre

 

[NNIsarahd]

Ah - I hadn't realized that about DLLs. I had thought all had to be registered. Thanks for clarifying that.

All of our machines in the shop have Vista installed. Most of our machines are Windows 2000. Only a handful of these machines have this problem - and there really isn't much in common except they run Windows 2000 or Windows XP and Vista reverts the driver. Do you think Windows File Protection might make a difference?

Yeah, when I say revert, the old version of the DLL is copied back into the system directory. I'm not sure where it's copied from, especially if that file isn't in the dllcache.

 

[ArtieChoke]

I've never seen a software package that updated an ODBC driver when it runs - but it could happen. Are all copies of Vista at the same version level?

The only other thing I can think of is somehow a system restore is taking place and rolling back to the previous version. Do you have any automatic processes to do that?

"I think we're all Bozos on this bus!" - Firesign Theatre

 

[NNIsarahd]

They're all the same version of Vista - 4.41.038.

I don't know of any automatic processes that would roll back to the previous version. I'll look to see if maybe Windows File Protection deals with the ODBC drivers.

Thanks so far for helping me find other possibilities!