March 9, 2005 at 12:24 pm
Hello,
We are upgrading the last 6.5 database and already were able to overcome all database upgrde problems. Now we have the application connection "opportunity" (like that joke: we don't have problems, we have tasks and opporunities....)
The application is 16 bit third-party stuff and the third party well, out of business for many years. Source code is not accessible. The app uses DBNMP3.DLL which is Mamed Pipes 16 bit DLL , see some references in
http://support.microsoft.com/default.aspx?scid=kb;en-us;137635
We have no problem moving the database to 6.5 development server and the applications connect to it from Windows XP or Windows 2000 computers. The application can not connect when we switch to SQL Server 2000 on the same or different servers from the same workstations. The SQL Server 6.5 standard installation does contain DBNMP3.DLL in the MSSQL\BINN folder and SQL 2000 does not contain it. The 32-bit version of this DLL is well-known DBNMPNTW.DLL that you can find in your 2000 Client Network Utility.
THE QUESTION: How can I make the application that uses the 16-bit Named Pipes DBNMP3.DLL connect to SQL Server 2000?
All suggestions are highly appreciated even if you don't have the experience but just feel that it may work.
Yelena
Regards,Yelena Varsha
March 9, 2005 at 2:07 pm
I am shooting in the dark here but:
If you move the db to SQL Server 2000 and run
EXEC sp_dbcmptlevel 'yourdb', 65
are you able to connect?
* Noel
March 9, 2005 at 2:35 pm
Noel,
This was a good point. Yes, the database compatibility level is 6.5 on the SQL Server 2000. It can not connect to the server to get a lis of applicable databases at all. It is exactly the step where the timeout happens. All other SW is able to connect to this database from the same workstation: Query Analyzer, ODBC Data Sources etc. We think that it is because the application calls this 16 bit Named Pipes DLL
I guess the question is: How can I enable SQL Server 2000 to listen on this 16 bit protocol? Or if I can create some sort of relay? I found an article for other connection types for earlier version:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/bldgapps/ba_highprog_56pc.asp
Connecting Early Version Clients to SQL Server 2000
It just does not tell you how to do it.
Yelena
Regards,Yelena Varsha
March 9, 2005 at 3:18 pm
I don't agree with the 16 bit theory. From your link it is suggested that sql will use Tabular Data Stream (TDS) 4.2 which is independent of the 16 bit / 32 bit of the DLL.
I think you don't have to do anything on the server but somehow is the authentication (windows in this case) is what is failing.
Can you check all permissions are OK on the server machine for the logins that you are using?
* Noel
March 9, 2005 at 3:33 pm
BTW You are not using a named instance, are you?
* Noel
March 9, 2005 at 3:35 pm
Logins are OK. I can connect with those logins using any other tool. The connection never reach the server: I ran a Profiler.
No named instances. Good thinking!
Yelena
Regards,Yelena Varsha
March 9, 2005 at 3:46 pm
>>I can connect with those logins using any other tool.<<
are those --> 6.5 Tools ?
* Noel
March 9, 2005 at 6:11 pm
ODBC source is a common tool for 6.5 and 2000, Query Analyzer version and Entrprise Manager version were 6.5 when connecting to 6.5 server and 2000 when connecting to 2000 server. I did not try connecting with 6.5 Query Analyzer to 2000 server, will try tomorrow. The only thing I can tell you that when I tried to use Client network utility on the server that has both 6.5 and 2000 and I used it from 6.5 menu when the machine was switched to 6.5 on the tab where you create aliases (this form looks really different in 6.5) the DLL for named Pipes was not the old one DBNMP3.DLL as on the picture in the 6.5 Books Online but it was a new one, DBNMPNTW.DLL maybe because this is a Windows 2000 server. But the app does use the old DLL from the app folder. You don't really install this Win16 stuff, you just copy a folder. I searched the registry, this DBNMP3.DLL is not there, just in the file system. Maybe I am missing something simple.
Yelena
Regards,Yelena Varsha
March 10, 2005 at 5:47 am
The 16 bit and 32 bit client tools are completely independent and don't care about each other.
16 bit clients use these files in \Windows\System (not System32): DBMSSOC3.DLL, DBNMP3.DLL, DBMSSPX3.DLL, MSDBLIB3.DLL, W3DBLIB.DLL
Run W3DBVER.EXE to set up how 16 but apps connect.
I had to do this last week for one of our apps, so it's fresh in my mind.
March 10, 2005 at 8:24 am
Hello Dbn,
Thanks for the advice. Could you post a short description how I should run W3DBVER.EXE?
I will look up it myself too, but any advice is welcome.
Yelena
Regards,Yelena Varsha
March 10, 2005 at 8:27 am
It's in the SQL client tools folder.
Select "Named Pipes" in the drop down, click "Change" and that should be it.
March 18, 2005 at 7:17 am
As it turns out, that wasn't the problem at all... a communications dll location on the client side turned out to be the culprit...(should have been in c:\windows\system and it wasn't) but there were several other issues w/the database after that... Several tables migrated now had dbo as the owner as opposed to syssql (as evidenced by the differences report created) and that caused the application not to be able to log in to the migrated db. Once we asked Yelena to reassign the objects to syssql as the owner, all those issues were resolved.. the 16-bit application has been successfully able to log into the migrated db..
A happy ending...
March 18, 2005 at 8:33 am
Colleen,
It is a pleasure to see you here!
There was also several other objects that have to be re-create in 2000 completely, not only the ownership, like a couple of views that well, had the same names as system tables. Additionally some syntax had to be changed.
I was absolutely sure it iwas a client issue because W3DSBVER.exe is a client network utility version for 6.5, but I was looking for some counterpart of Server Network utility.
Anyway, putting stuff to Windows\System was a very good move, don't forget we put dlls on the server to all 3: System, System32 and MSSQL\Bin of 2000 version AND in System on the client. Also one of the attempts was done on the test server where BOTH application and SQL 2000 were on the same machine. Whatever worked, I am so happy!
Yelena
Regards,Yelena Varsha
Viewing 13 posts - 1 through 12 (of 12 total)
You must be logged in to reply to this topic. Login to reply