November 3, 2006 at 1:56 pm
During a Wise Installation upgrade of our software, we are renaming a
directory that contains our ExtendedSP DLL. We issue a
DBCC TSWSQLXP(Free) call before doing the rename, yet SQL Server,
still "holds on" to that DLL. We install a new version, and the ListDLLs
utility (from sysinternals) lists the new DLL in the correct directory.
However, when trying to remove the renamed directory, it won't let us
remove the old DLL because it says it is in use. We can delete the NEW
DLL in the NEW directory with no problem.
I have run the DBCC call numerous times and SQL Server STILL won't
release the DLL for deletion. The only way to delete the OLD DLL is to
stop the SQL Server, delete the DLL, and then restart SQL Server. We
do NOT want to do this because there may be other processes running in
SQL Server.
Here's the process inside our installation routine:
1. Drop Extended Stored procs
2. Unload OLD TSWSQLXP DLL {DBCC TSWSQLXP(FREE) - DLL Name is TSWSQLXP.dll }
3. Rename BIN directory to BINxxx (where xxx = our software version)
{We rename the BIN directory to restore files in case of errors during
install}
4. Install NEW TSWSQLXP DLL into new BIN directory
5. Install Extended Stored procs
6. Call one of the newly installed Extended Stored procs
7. Delete renamed directory (fails because OLD TSWSQLXP DLL still in
use-manual delete fails, also)
We ARE able to delete NEW TSWSQLXP DLL from the new BIN directory even
though the references in the Exptended Stored proc point to the NEW TSWSQLXP DLL.
Even using MoveFileEX with the MOVEFILE_DELAY_UNTIL_REBOOT flag won't
allow the directory to be deleted when the system reboots. I have double
checked the registry key (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\
Control\Session Manager\FileRenameOperations) and it is correct.
Any help here would be greatly appreciated.
November 6, 2006 at 4:49 am
I've two thoughts - there are some procs which register and deregister extended proc calls.
Why are you changing dll's if you think processes are running? If you're worried about that then surely you shouldn't be changing a dll on the fly so to speak? It sounds fine to me that the dll wouldn't be released, it's sort of the behavoir I'd expect - not used extended procs for many years but i'd worry if a dll could just be dropped from a running server.
[font="Comic Sans MS"]The GrumpyOldDBA[/font]
www.grumpyolddba.co.uk
http://sqlblogcasts.com/blogs/grumpyolddba/
November 6, 2006 at 7:21 am
Well, that's what "DBCC TSWSQLXP (FREE)" is supposed to do.
November 7, 2006 at 7:44 am
According to KB Article Q300965:
http://support.microsoft.com/default.aspx?scid=kb;en-us;Q300965
We have been 'registering' the TSWSQLXP.DLL wrongly for ages.
We have experienced loads of trouble trying to get a new
version installed and remove the old version due to this. We
MUST stop the MSSQL Service but it also takes some time before
the DLL is able to be removed.
We've tried dropping all the SP's, then issuing the DBCC
dllname (FREE) but it still would not allow us to delete the
old DLL. The new SPs, when added point to the new DLL but the
OLD one is the one that SQL Server is still holding on to.
In our installation, we even STOP the service, and wait 10
seconds before we attempt to rename and move the DLL to
another directory. We are successful in renaming and moving it
but SQL Server still won't let us delete it.
Viewing 4 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply