Trying to setup an ODBC connection for UPS to access our SQL server, from our shipping client computer.
I have scoured as much as I can an ran across:
runas /netonly /user:domain\account "c:\windows\system32\odbcad32.exe"
Now, using this method, on my current client computer, I was able to setup an odbc connection successfully using SQL Native Client 11 (5058). I am using Win 10. Our shipping computer, with multiple manifest systems on it, is still using Win 7, but otherwise is setup the same on the domain.
Using the same process as above, the connection ultimately times out, and states that the server is not online/not available/not allowing remote connections.
Is there a step I'm missing? Both clients have same rules for firewall, both are using the same user/password in the runas cmd. The only difference between the two clients is Win 10 vs. Win 7, and the current logged in user is different (but that shouldn't matter with the runas cmd?)
Thanks!
So after several days/hours of trying various solutions and suggestions from all over the interwebs, I came across this solution/tips.
In SQL Server Configuration, checking the network configuration protocols/clients/aliases. In my case, there was an aliases established for 32-bit, and not 64-bit. I disabled the 32-bit one.
I then found suggestions to us the ip (which I had tried in the past, with no success), but this time, after ensuring all the tcp/ip protocols were enabled and the 32-bit aliases was disabled, I was able to connect the 32-bit to the 64-bit SQL server, using the xxx.xxx.xxx.xxx address of the server.
Test came back successful!
Related
This is the thing, I have a server working perfectly allowing LAN connections, now im setting up a second one for maintenance purposes, but for some reasons I can't connect to him using windows authenticacion, but I still can to the first one, or using sql server login but I dont what to, I want to use Windows Authenticacion... I keep getting error message:
login failed for user "the user is not associated with a trusted SQL connection. (microsoft sql server, error:18452)
UPDATE: Both servers are running under Windows 7 (they are not for buissness use) they both are configure exactly equal.
UPDATE 2: I can connect from the same computer but not from a network one.
After few time, I realize the problem was at the layer eight (me), the best way to use windows authentication for SQL server is configuring a domain server, then add those domains users to sql and give them the desired privileges to connect to a database, and that' all it's that simple (at least for me it was) so after that, I created a System DSN Connection using windows authentication.
Has anyone accomplished pushing files to a BOE server using SSIS? I am trying to develop a SQL Server 2008 SSIS package that will push report (Excel) files to our Business Objects Enterprise (BO XI 3.1) server. Via a Script Task, I am using the Business Objects .NET SDK components to authenticate and connect to the BOE Server.
I have a copy of the package deployed to a local instance of SQL Server 2008 running on my Windows XP desktop. The package executes successfully (via a SQL Agent Job) and delivers the file to the designated location on the BOE server.
When I deploy the package to our development SQL server (SQL Server 2008 on Windows Server 2008 64-bit) and attempt to execute the package via a SQL Agent job, I receive the error message "File Repository Server Input is down" when the script task attempts to "Commit" the file to the BOE server. The package is able to open a session with the BOE Server, create a new info object, but fails on the infoStore.Commit command.
I have another SSIS package that executes successfully from our development SQL server - it communicates with the BOE server and searches for user sessions. It does not communicate with the Input File Repository - that seems to be the key distinction.
I have found limited information related to this error that indicates firewalls and ports between the SQL Server and BOE server may be the cause. I have reviewed the BOE Administrator's Guide to no avail (most likely due to my lack of understanding related to firewalls and ports). Both servers are within the same subnet and neither server has the firewall turned on. The ports for the BOE CMS servers and the Input/Output File Repository servers have been set to static port ids. Our network guy indicates there should be nothing preventing communication between the servers based on firewall or port settings.
Any help would be greatly appreciated!
Have you tried all the usual 'run as 32 bit' solutions? I guess yuor SDK is a 32 bit one, not a 64 bit one.
http://www.bidn.com/blogs/ShawnHarrison/ssis/2362/ssis-basics-running-a-package-in-32-bit-mode
However the fact the the SDK works for different services implies that it runs OK in 64 bit. So if you want to troubleshoot ports, I found this link http://scn.sap.com/thread/2027785 which indicates that the BOE ports are 6400 to 6411. To check that a given port is open, you go to a DOS prompt and type
TELNET hostname port
So if your BOE server is BOESERVER then you'd try this:
TELNET BOESERVER 6400
to test port 6400. You should get a black screen to indicate it's connected.
However, again, the fact that you seem to be able to connect and operate but not commit implies there is not a port problem as you can connect, just can't commit.
Are there any logs in the BOE side to give you a better idea of the issue?
A resolution to this issue has been identified and verified. The Windows AD account used by the proxy the SQL Agent job uses to execute the SSIS package did not have sufficient privileges on the network. Our DBA gave the account local Windows administrator privileges on the SQL server and this resolved the "File Repository Server Input is down" error I was receiving.
Thanks to those who responded and gave me other ideas to investigate.
A client of mine gave me a server name which is fully qualified [servername].somedomain.net
to try to connect to their SQL Server instance over VPN.
So I tried, using the username and password they gave me. No luck. I can ping it but cannot connect, I get the error that the username and password is incorrect.
So I log onto the actual server, verify that my login is in security and has rights and it appears there. Workgroup\mylogin and it appears that workgroup\ actually is the same as somedomain.net\mylogin. Because when I try to add somedomain.net\mylogin, it resorts to saying that it's already added which is workgroup\mylogin.
Not sure what else to check here. I gave myself sysadmin role in SQL Server. I can ping the server's IP.
I looked at how they are authenticating me and they have my user in SQL Server set up to use Windows Auth. Well, the error I get is that it cannot trust cross domain when trying to use windows auth when I try to connect locally here in my management studio. I'm connected tot their VPN so what could be the problem?
They're not available right now to try to troubleshoot it and I'm just curious what else I might try to try and resolve this on my own if I can.
Basically, when you failed to connect to your SQL Server, the issue could be:
Network issue,
SQL Server configuration issue.
Firewall issue
Client driver issue
Application configuration issue.
Authentication and logon issue.
Step 1: Network issue
You might be able to make local connection without a working network, but that's a special case. For remote connection, a stable network is required. The first thing to trouble shoot SQL connectivity issues is to make sure the network we rely on is workable and stable. Please run the following commands:
ping -a (use -4 and -6 for IPv4 and IPv6 specifically)
ping -a
nslookup (type your local and remote machine name and IP address multiple times)
Be careful to see any mismatch on the returned results. If you are not able to ping your target machine, it has high chance that either the network is broken or the target machine is not running. It's possible the target machine is behind a firewall and the firewall blocks the packets sent by ping, though. Windows firewall does not block ping (ECHO) packet by default. The correctness of DNS configuration on the network is vital to SQL connection. Wrong DNS entry could cause of all sorts of connectivity issue later. See this link for example, "Cannot Generate SSPI Context" error message, Poisoned DNS.
Step 2: SQL Server configuration issue
You need to make sure the target SQL Server is running and is listening on appropriate protocols. You can use SQL Server Configuration Manager (SCM) to enable protocols on the server machine. SQL Server supports Shared Memory, Named Pipes, and TCP protocols (and VIA which needs special hardware and is rarely used). For remote connection, NP and/or TCP protocols must be enabled. Once you enabled protocols in SCM, please make sure restart the SQL Server.
You can open errorlog file to see if the server is successfully listening on any of the protocol. The location of errorlog file is usually under:
%ProgramFile%Microsoft SQL Server/MSSQLxx.xxx/MSSQL/Log
If the target SQL instance is a named instance, you also need to make sure SQL Browser is running on the target machine. If you are not able to access the remote SQL Server, please ask your admin to make sure all these happen.
Step 3: Firewall issue
A firewall on the SQL Server machine (or anywhere between client and server) could block SQL connection request. An easy way to isolate if this is a firewall issue is to turn off firewall for a short time if you can. Long term solution is to put exception for SQL Server and SQL Browser.
For NP protocol, please make sure file sharing is in firewall exception list. Both file sharing and NP use SMB protocol underneath.
For TCP protocol, you need put the TCP port on which the SQL Server listens on into exception.
For SQL Browser, please put UDP port 1434 into exception.
Meanwhile, you can put sqlservr.exe and sqlbrowser.exe into exception as well, but this is not recommended. IPSec between machines that we are not trusted could also block some packets. Note that firewall should never be an issue for local connections.
Step 4: Client driver issue
At this stage, you can test your connection using some tools. The tests need to be done on client machine for sure.
First try:
telnet
You should be able to telnet to the SQL server TCP port if TCP is enabled. Otherwise, go back to check steps 1-3. Then, use OSQL, SQLCMD, and SQL Management Studio to test sql connections. If you don't have those tools, please download SQL Express from Microsoft and you can get those tools for free.
OSQL (the one shipped with SQL Server 2000) uses MDAC.
OSQL (the one shipped with SQL Server 2005 & 2008) uses SNAC ODBC.
SQLCMD (shipped with SQL Server 2005 & 2008) uses SNAC OLEDB.
SQL Management Studio (shipped with SQL Server 2005 & 2008) uses SQLClient.
Possilbe command use be:
osql -E -SYour_target_machine\Your_instance for Windows Auth
osql -Uyour_user -SYour_target_machine\Your_instance for SQL Auth
SQLCMD also applies here. In addition, you can use “-Stcp:Your_target_machine, Tcp_port” for TCP, “-Snp:Your_target_machine\Your_instance” for NP, and “-Slpc:Your_target_machine\Your_instance” for Shared Memory. You would know if it fails for all protocols or just some specific procotols.
At this stage, you should not see general error message such as error 26 and error 40 anymore. If you are using NP and you still see error 40 (Named Pipes Provider: Could not open a connection to SQL Server), please try the following steps:
a) Open a file share on your server machine.
b) Run “net view \your_target_machine” and “net use \your_target_machine\your_share” (You can try Map Network Drive from Windows Explorer as well)
If you get failure in b), it's very likely you have OS/Network configuration issue, which is not SQL Server specific. Please search on internet to resolve this issue first.
You can try connection using both Windows Authentication and SQL Authentication. If the tests with all tools failed, there is a good chance that steps 1-3 were not set correctly, unless the failure is logon-related then you can look at step 6.
If you succeeds with some of the tools, but fails with other tools, it's probably a driver issue. You can post a question on our forum and give us the details.
You can also use “\windows\system32\odbcad32.exe” (which ships with Windows) to test connection by adding new DSN for various drivers, but that's for ODBC only.
Step 5: Application issue
If you succeed with steps 1-4 but still see failure in your application, it's likely a configuration issue in your application. Think about couple of possible issues here.
a) Is your application running under the same account with the account you did tests in step 4? If not, you might want to try testing in step 4 under that account or change to a workable service account for your application if possible.
b) Which SQL driver does your app use?
c) What's your connection string? Is the connection string compatible to your driver? Please check http://www.connectionstrings.com/ for reference.
Step 6: Authentication and logon issue
This is probably the most difficult part for sql connectivity issues. It's often related to the configuration on your network, your OS and your SQL Server database. There is no simple solution for this, and we have to solve it case by case. There are already several blogs in sql_protocols talking about some special cases and you can check them see if any of them applies to your case. Apart from that, things to keep in mind:
a) If you use SQL auth, mixed authentication must be enabled. Check this page for reference http://msdn.microsoft.com/en-us/library/ms188670.aspx
b) Make sure your login account has access permission on the database you used during login ("Initial Catalog" in OLEDB).
c) Check the eventlog on your system see if there is more information
Reference: http://blogs.msdn.com/b/sql_protocols/archive/2008/04/30/steps-to-troubleshoot-connectivity-issues.aspx
Sorry for this wall of text, i hope that something from here can help you solve your issue!
Regards.
If you want to access that server you are going to need a domain account from that domain or use SQL authentication. I would recommend just using SQL authentication - it's a lot more straight forward - if they allow it.
I had the same problem, other machines could connect to sql server but one computer was not connecting and displaying the error "a network related or instance specific error...", the problem was solved when I changed the network protocol in the login window of SSMS, in advanced options from TCP/IP to Named Pipes. Please see the below screenshots.
Please note that you should be on the same domain, and your credentials should be valid on the server.
I've got a small Windows network with 3 machines. One of them has SQL 2005 installed. As of last week, the other two machines have had no problems connecting to the SQL instance.
Today, one machine - running Vista, if that matters - all of a sudden cannot connect. I get the generic message saying "A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections."
I'm pretty sure everything is set up correctly on the SQL 2005 box, because the third computer on the network still connects with no problem.
Vista computer has no firewalls set up, nothing has changed with the exception that I created a connection to a VPN a few days ago. When connected to the VPN, local network connectivity is hosed, but I've double checked many times that I am NOT connected to the VPN when trying to access SQL Server. I mention this only because it's the only thing I can think of that's changed.
I've rebooted all computers many times. No change.
I'm connecting via SQL Integrated Security. The login works fine from the third machine.
One other weird thing on the Vista box. Occasionally - maybe 5% of the time - it'll connect, but then when trying to access a table (like, just right clicking and choosing "open") it pauses then gives an "unspecified error."
Any ideas? I'm totally perplexed. This has been working for about 18 months without any errors, and I can't think of anything that's changed other than the VPN connection mentioned above. And just to reiterate - I am definitely NOT connected to the VPN when I'm getting this error.
Check the protocols used to connect ot SQL Server; I'm wondering whether it's trying to communicate over Named Pipes rather than TCP/IP (speaking from recent experience -- I had an issue with Named Pipes that went away when I disabled Named Pipes and enabled TCP/IP).
You can check this on the server with the SQL Server Configuration Tool, and see which protocols are enabled (under the Network Configuration branch in the navigation tree) for the SQL Server instance.
First off, we know that there is no client server communication here. So, based on the error, it isn't permissions or authentication (you have to connect before you can be denied access).
Try the following:
1) Ping - can you get to the server? Run this command in command prompt:
ping servername
If this works, then at least the name is resolving and the client can communicate.
If this fails, try the same thing with the server's IP.
2) Telnet - Assuming you don't have a non-standard port (explicitly changed or named instance of SQL Server), run this in command prompt:
telnet servername 1433
If this opens an empty screen, then the client can get to the port.
If this fails, try the same command with the IP. If that still fails, you don't have a path to the SQL Server from that machine. You will either need to verify an external firewall or other network connectivity issues.
I have a Delphi application running on SQL Server 2000, but it's taking awfully long to connect to the database!
But when I run this application on my development server it connects pretty fast!
I am running on Windows 2003 server, SQL Server 2k personal edition, when I look on my MDAC version in the registry, I see version 2.8 already installed!
Any ideas why this happens on the production machine but not on the development machine?
There's a reasonable chance that this is down to a network level issue connecting to the database. Depending on whether you're running the application and database on the same box of course.
Try connecting to the database from the same machine using a different tool. You could set up a data source and test it from the control panel as an alternative. If the connection is slow from another tool test the connectivity between the servers for other types of connection (e.g. run a ping). It may be that it's resolving the server via broadcast rather than the domain, for instance. Or any number of other issues - firewall, switch, wins etc.
If you are connecting using integrated authentication also ensure that the database can resolve the application server as well as vice versa. This is part of the authentication process and I've seen it cause slow downs in creating database connections before.
In short, I'd be confident that this isn't a problem specific to delphi / sql, but something in the communications between your production servers.
Good luck!
Keep your connection open once you have established it. This is called connection pooling and will improve performance. I have no clue how to do it with a delphi application.
Your problem most likely is network or transport layer related
Are you connecting through TCP, Named Pipes or another mechanism?
Have you tried tracing opening a connection with Microsoft SQL Profiler?
regards,
Lieven
I had a problem a long time ago like this, and it came down to the workstation section of the connection string. its possible if you've copied the connection string from your dev machine that the workstation parameter is still in the connection string and pointing to your dev machine which probably does not exist on your deployment network.
In this case your connection to the database has to wait until the network tries to connect ot a non-existant machine (which obviously takes time). Remove the workstation cluse and it will speed up no end.