Showing results for 
Search instead for 
Do you mean 
Community Home Request Access Read Blogs Share Your Ideas Search Community View My Settings
Reply
Copper Elite Contributor
Posts: 153
Registered: ‎02-27-2010

Errors with Native Client testing migration from SQL2000 to SQL2005

We are currently using 7.2.2 (on SQL 2000) planning to upgrade to 7.5.4 (SQL 2005). Our first step is to upgrade to SQL 2005 which we are currently testing. Two "Network" users (our DBA/Admin and another admin) are getting in without issue but 3 other testing users (one admin) are all getting the following error:

 

"Database login failed: SQL Network Interfaces: Error Locating Server/Instance Specified [xFFFFFFFF]"

 

And during Data Link setup for the failing users, the following error is generated:

 

"Unable to initialize data dictionary"

 

Searches on Google, SLX Knowledgebase and SLX Community have not offered any clear insights on how best to proceed. I was curious if anyone could offer any direction. We hopefully will be calling Sage later today (Invoice payment delays!)

 

Thanks,

Larry Esposito

New Member
Posts: 20
Registered: ‎08-23-2010

Re: Errors with Native Client testing migration from SQL2000 to SQL2005

Did you modify the link in the Connection Manager? Make sure you're using the Native Client driver, and sometimes the client machines will need the SQL Native Client installed on it also.

Gold Super Contributor
Posts: 3,087
Registered: ‎03-19-2009

Re: Errors with Native Client testing migration from SQL2000 to SQL2005

You ohave to make sure the correct SQL Native Client drivers are setup on both sides (Server and client apps).

 

Check this blog post:

  http://blog.rjlsystems.net/2012/03/19/problem-connecting-network-clients-to-slx-server/

--
RJ Ledger - rjledger@rjlSystems.net +1 603.369.3047 x101

".. Innovators in Mobility - Experts in Workflow Automation..."
http://www.rjlSystems.net - blog: www.rjlSystems.net/blog.html
Copper Elite Contributor
Posts: 153
Registered: ‎02-27-2010

Re: Errors with Native Client testing migration from SQL2000 to SQL2005

All testing users have SQL Native Client installed (part) of the testing and I'm 99% certain that DBA setup Connection with SQL Native Client Connector since it was a pain point in earlier testing.

Thanks,
Larry Esposito
Copper Elite Contributor
Posts: 153
Registered: ‎02-27-2010

Re: Errors with Native Client testing migration from SQL2000 to SQL2005

That just "might" be it! My SQL Native Client and all testing users that failed are using the SQL Native Client install (9.00.3042.00)that came in the Redist folder of the 7.2.2 Install CD. Our DBA, being a DBA, may be using a more current version thus the incompatibility. Although it wouldn't explain why the other admin is working but... Just checked and THAT'S IT - he's using 9.00.4035.00 installed by our DBA. I'll confirm that our problem has been corrected and 'Accept as Solution" if it works.

RJL, As Always...

Thanks again,
Larry Esposito
Copper Elite Contributor
Posts: 153
Registered: ‎02-27-2010

Re: Errors with Native Client testing migration from SQL2000 to SQL2005

It looks like the server had the same version (3042) as the failing PCs. Furthermore, it looks like if we make and test a SQL Server connection in ODBC Data Source Administrator that the errors go away and the users connect. It could be a network architecture issue on our end (there've been issues in the past). I'll post findings later but I suspect this issue is going to be site specific to us.

Thanks,
Larry Esposito
Copper Elite Contributor
Posts: 153
Registered: ‎02-27-2010

Re: Errors with Native Client testing migration from SQL2000 to SQL2005

It turns out that we simply had to create an alias to the Server\Instance on each Network Client using cliconfg (SQL Server Client Network Utility). Our testing described in an earlier post had done this for us behind the scenes but creating the alias, which I had remembered seeing in this SLXDeveloper Post,didn't require any testing or secure passwords. Since someone else had the same problem with the same fix I suspect this issue is not necessarily specific to our environment but my guess is that the alias helps point to the specific instance rather than the default instance (which works fine without an alias).

 

Thanks,

Larry Esposito