Link to home
Start Free TrialLog in
Avatar of marksynnott
marksynnott

asked on

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
Avatar of TimCottee
TimCottee
Flag of United Kingdom of Great Britain and Northern Ireland image

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.
Avatar of marksynnott
marksynnott

ASKER

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
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.
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
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
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.
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...
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).

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.
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.
 
ASKER CERTIFIED SOLUTION
Avatar of TimCottee
TimCottee
Flag of United Kingdom of Great Britain and Northern Ireland image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
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
Avatar of DanRollins
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