• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 217
  • Last Modified:

SQL 2000 - WINDOWS 2000 - WINDOWS NT - For the GURU's

Id be grateful if anyone could help on this very complicated problem

I am trying to connect to a new sql2000 server running windows 2k on a different doamin

The set up

All clients are running Windows NT  and are on domain one
I have tried to connect via odbc to this new server and it fails if i point to a server on the existing domain which is running SQL 6.5 it fails. I sign on to the same domain as the other clients, the really strange thing is that it will connect fine from my workstation to the new server on the new domain. I do have a lot of software installed on my work station.


The server is running windows 2000 with sql 2000 (standard) - The security within SQ2000 is set to SQL database security


The error I get is

Connection Failed
SQLSTATE '01000'
SQL Server Error :1326
Microsoft ODBC SQLserver Driver ........
Connection failed
SQL State '08001'
SQL Server Error 1326
Client unable to establish connection


Thank You
0
marksynnott
Asked:
marksynnott
  • 4
  • 3
  • 2
  • +4
1 Solution
 
TimCotteeCommented:
Mark, is there a trust relationship between the two domains? If not is the GUEST account in the new domain disabled. As I understand it the error 1326 is actually an authentication error across the two domains. Normally a trust relationship should solve this problem however in a non-trust situation the guest account comes into play. I am not a great NT/2000 guru but this may be worthwhile posting a zero-point link in the winnt ta cross-posted to here as I think that is where the problem lies.
0
 
marksynnottAuthor Commented:
Tim Thanks for the hint.

I was getting trust errors when I had the NT authentication option switched on on the sql server 2000 box so i put the sql 2000 database security blaa on.

My machine which is on the same domain as the other works and connects fine connecting with sa. All other pcs seem to get this error which is great since im trying to roll out the appliacation to 1500 users. I preseume it coulnt software versions..They do work fine on sql6.5 on same domain.


Where is the winnt question forum  ?????

Your a star thanks
0
 
mor4eusCommented:
Have you tried installing query analyzer on one of the workstations in the other domain.  If this works then you have an odbc problem.  And we can sort that out.  Firstly try this though.
0
VIDEO: THE CONCERTO CLOUD FOR HEALTHCARE

Modern healthcare requires a modern cloud. View this brief video to understand how the Concerto Cloud for Healthcare can help your organization.

 
SimonECommented:
Using query analyzer is  a good tip for all of these sorts of problems.

I would also try getting away from the NT/2000 integrated security and try to connect using SQL Server authentication.  

Set up an ODBC DSN to your new machine, using user sysdba and password masterkey. If this hooks up, you should then be able to use the same login details in any apps that you are developing.

Hope this helps
0
 
marksynnottAuthor Commented:
Hi Folks

I think I have located the problem. When my client connects to a database the default is to use NAMED PIPES - If I change this to TCP/IP all is fine.

I know named pipes is an option on sql server 6.5 set up however our server group are saying that its not an option for sql server 2000 under windows 2000 ( I am dubious about this)

Can anyone know let me know about named pipes the advantages and disadvantages etc .

Thanks again

Mark
0
 
ZhongYuCommented:
When using named pipew, the client computer must first login to the server computer using the credential of the current user. It is only after that, SQL login will happen using provided SQL login and password.

The first login is not performed if you use TCP/IP.

You can force the client using TCP/IP by configuring SQL client or by setting IP address (instead of server netbios name) in the ODBC source.
0
 
marksynnottAuthor Commented:
Thanks

Im using VB ado to conenct to ther server is there a parameter i can put in connection string to tell it to connect it via tcp/ip as its defaulting tp Named Pipes ??

I need to install the app on 1200 users desktops so I dont want to have to go around and manually change eacj computer to tcp in odbc...
0
 
ZhongYuCommented:
You do not have to set up an odbc source on every computer. The following connection string can be used:

Provider=MSDASQL; Driver=SQL Server; UID=sa; PWD=pwd; Server=10.10.10.10; Database=youdatabase"

You may have to use a newer odbc driver. I am not sure if this will work with ancient drivers. Neither am I sure about VB (I use ASP for most part of my work).

0
 
TimCotteeCommented:
Mark, it sounds like you have found a solution. Here is a sneaky hack that might help:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLServer\Client\ConnectTo="DBMSSOCN"

When your application runs, just modify the above key to this value (Named Pipes=DBNMPNTW) and it should then use the TCP/IP connection. You could always change it back afterwards to prevent sneaky people trying to connect with the standard SQL tools such as query analyzer.
0
 
marksynnottAuthor Commented:
Tim Thanks again fpor your help

Jus one thing I have a vb prog tochange registry settings.

But if I look at the "connect to" key there are entries for each server i set up via the control panel. I use ado to connect to the server which of them should i change etc.
 
0
 
TimCotteeCommented:
I assume then that you have specific server alias configurations such as

TICOTTE = DBMSSOCN,TICOTTE,1433
TICOTTE1 = DBNMPNTW,\\TICOTTE1\pipe\sql\query

If so then you would need to change the one for your specific server from the named pipes convention to the TCP/IP convention.
0
 
ibroCommented:
Do you use named pipes or TCP/IP to connect to SQL Server.
You can check that with the Client Network Configuration utility on the client and with Server Network Configuration on the server.
 I will suggest you to use TCP/IP. However you shall be able to ping the server from each client machine.
Do you have some kind of firewall on your network. By default SQL Server is listening on port 1433. If you have firewall, check the permissions to this port.
 hope this helps
0
 
DanRollinsCommented:
Hi marksynnott,
It appears that you have forgotten this question. I will ask Community Support to close it unless you finalize it within 7 days. I will ask a Community Support Moderator to:

    Refund points and save as a 0-pt PAQ.
    *** It looks to me like marksynnott solved the specific problem himself.  If he responds, he could award, say, TimCottee out of gratitude...

marksynnott, Please DO NOT accept this comment as an answer.
EXPERTS: Post a comment if you are certain that an expert deserves credit.  Explain why.
==========
DanRollins -- EE database cleanup volunteer
0

Featured Post

Upgrade your Question Security!

Add Premium security features to your question to ensure its privacy or anonymity. Learn more about your ability to control Question Security today.

  • 4
  • 3
  • 2
  • +4
Tackle projects and never again get stuck behind a technical roadblock.
Join Now