December 20, 2006 at 5:43 pm
Hi,
I was trying to register an extended sp which is working fine in the SQL 2000 servers into my new SQL 2005 64bit version server which is installed on win 2004 64 bit and get the following error.
Msg 17750, Level 16, State 0, Procedure xp_startbackupexe_2005, Line 1
Could not load the DLL c:\XPS\xp_startexe.dll, or one of the DLLs it references. Reason: 193(error not found).
Can anyone help me to resolve this issue?
This was installed successfully on SQL 2000 server on Win 2003 64bit server.
I used sp_addextendedproc to add this XP.
Thanks
December 20, 2006 at 5:58 pm
Was your sql server 2000 also 64 bit?
Is your dll compatable with 64bit OS?
Adding an Extended Stored Procedure to SQL Server
http://msdn2.microsoft.com/en-us/library/ms164653.aspx
MohammedU
Microsoft SQL Server MVP
December 20, 2006 at 6:34 pm
My SQL 2000 is not 64 bit but it was running on 64 bit OS. I haven't done anything to the dll.
I think my dll is compatible with 64bit OS becasue it runs on SQL 2000 installed on 64bit. But not on SQL 2005 64 bit version.
how can i make my dll compatible with 64bit?
December 30, 2007 at 4:21 pm
I'm having the same problem but I don't have the source of the DLL as it is a closed source application that uses it.
Is there any way that 32bit dlls compatible with SQL Server 2000 can be run under SQL Server 2005 x64? For example with WOW64?
December 31, 2007 at 5:32 am
I have found that if the DLL is in the default folder (e.g. c:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Binn) then running sp_addextendedproc without specifying the full path of the DLL works OK. If you do not put the DLL in the default folder then you must specify the path. See the article referenced by Mohammed Uddin
Original author: https://github.com/SQL-FineBuild/Common/wiki/ 1-click install and best practice configuration of SQL Server 2019, 2017 2016, 2014, 2012, 2008 R2, 2008 and 2005.
When I give food to the poor they call me a saint. When I ask why they are poor they call me a communist - Archbishop Hélder Câmara
December 31, 2007 at 5:53 am
I have the DLL in this directory and have tried with and without the full path (Microsoft recommends with) but both produce the same problem.
Every reference to 193 (error not found) I find seems to be about migrating dlls that were working fine on 2000 32bit to 2005 64bit, so I am sure that this is the problem.
December 31, 2007 at 6:04 am
Try putting the 32-bit DLLs into the Windows sysWOW folder. When I needed to use some custom 32-bit OCX components in DTS packages I was installing on 64-bit SQL 2005, I found that putting them into sysWOW got things working.
Original author: https://github.com/SQL-FineBuild/Common/wiki/ 1-click install and best practice configuration of SQL Server 2019, 2017 2016, 2014, 2012, 2008 R2, 2008 and 2005.
When I give food to the poor they call me a saint. When I ask why they are poor they call me a communist - Archbishop Hélder Câmara
June 14, 2010 at 6:10 am
Hi,
For an extended stored procedure, will the application automatically read the reference from the sysWow64 folder.
or do we require to explicitly provide with the full path of the C:\windows\system32\syswow64 folder on that server ?
Please confirm, as I have run into a similar scenario where I require to execute a 32 bit programmed binary into sql server 2008 / binn directory to get it running, this is as a part of the sql server 2008 upgrade.
thanks in advance for you help.
Viewing 8 posts - 1 through 7 (of 7 total)
You must be logged in to reply to this topic. Login to reply