Running Windows 2019 servers in my lab.
An application has a SQL client. But the client cannot find an ODBC connection.
Created a "System DSN" via the ODBC Data Source administrator (32-bit). As I usually do in my lab. I found some articles on registry placement, all appear OK. I compare another server and that machine has no issue.
Both 2019 servers are on the latest MS hotfixes.
I'm found no specific articles that can help me isolate the fault. I see no errors in the Windows Event Logs.
ODBC System DSN passes testing in the configuration window.
Can anyone help?
Related
I've installed SQL Server 2016 (Standard Edition) on a Windows Server 2016, selecting Integration Services to be installed too. I've also installed SSMS and SSDT from the same installation media.
I am running SSMS as administrator and can connect to the local Database engine.
My user is a Windows and SQL Server admin.
However I cannot connect (explicitly using the server name) or even browse to the local Integration Services?
Receiving the following error.
SSIS not browsable and can't connect
Having already searched for an answer to this problem, many suggest checking that the service is running etc. which can be seen in the Services and SQL Configuration Manager.
Services shown as running
I've also tried turning off the Windows Firewall to establish if that is the cause of the problem but it had no effect.
Anyone got any ideas what might be preventing it from being accessible?
I've had this problem last month. In my case I had to install the 32-bit version of access database engine (on my 64 bit windows).
Sql data tools works with 32-bit
https://www.microsoft.com/en-us/download/details.aspx?id=54920
The later SSMS versions (16.x and 17.x) will only connect to their respective versions SQL 2016 and SQL 2017. Microsoft is planning to retire the older method in favor of the SSISDB, which is more secure.
Link to the official statement from Microsoft (in the note box).
I have had the same problem and the solution was to install the old interface on top of the existing one (SQL Server Management Studio 2016). Here's link to the installation file. After having installed this, I can now connect to the integration services. You will have to set it up of course and give yourself Rights
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!
I read another article concerning this problem when getting the file in use message. I went into SQL Management studio and disconnected the database but still no success in connecting. Here's what's happening step by step:
I downloaded SQL Express 2014 and installed it. I created a DB called MyEntertainmentDB, then created a couple of files (Movies and Rating). I added some data to both. I fired up VS and in VB I created a form added various controls including a datagrid. The DB exists in the default location used by MS SQL. I clicked the Smart Tag and the data grid view tasks window appears. I click the choose data source drop down arrow and then add project data source. Database is highlighted and I click next. Dataset is highlighted and I click next. Now I click new connection and select Microsoft SQL Server Database File (Data provider is .NET Framework Data Provider for SQL Server (the only thing in that drop down box)) and I click Continue. Now I'm shown a window that has the data source as Microsoft SQL Server Database File (SqlClient) in the first box and I browse to where my database is located and select it (which is C:\Program Files\Microsoft SQL Server\MSSQL12.SQLEXPRESS\MSSQL\DATA\MyEntertainmentDB.mdf). Everything is going well and I'm using Windows Authentication. I click ok. Now it waits several minutes and I get this message:
The attempt to attach to the database failed with the following message: 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 the instance name is correct and that SQL Server is configured to allow remote connections. (provider: SQL Network Interfaces, error: 50 - Local Database Runtime error occurred. Cannot create an automatic instance. See the Windows Application event log for error details.
I looked in theSQL Server log but nothing was mentioned shedding any light. I could not find any VS log. I checked the windows logs but could not find anything seemingly relevant. I'm at a loss for this problem and am about ready to trash MS SQL server and just go with MS Access 2010 or MySQL. Does anybody see where I'm going wrong? If so, please help, I've tried to be very specific and hope I've provided all info necessary.
First of all you must configure your MSSQL Express Server to respond.
To do that you must open SQL Server Configuration Manager (on Windows 8.1 just go in the upper right corner, hit Search and type: SQL Server Configuration Manager. If you are using Windows 7 you can find it on Start Menu).
On SQL Config Manager you must go to expand SQL Server Network Configuration and you'll see Protocols for (your DB instance). Click on that.
After you click on Protocols for (your DB instance) in the right window you will see Shared Memory, Named Pipes and TCP/IP. Double click on each and set them to Enabled = Yes.
Now your MSSQL Server must listen to standard port 1433. To do this double click on TCP/IP, select IP Addresses (Now you will see IP1 config, IP2 config, etc), scroll down to IPAll and set TCP Dynamic Ports to 0 and TCP Port to 1433.
Now restart your SQL Server Service. If don't know how to this, just reboot your computer. After reboot open command prompt and type netstat -a to see if your MSSQL is listening on port 1433.
Now in Visual Studio when you are connecting to your SQL Server on Server Name type server IP (your IP or 127.0.0.1) or you can select your SQL Server instance from dropdown list without any problems.
You can check this tutorial too: Allow SQL Server Express to accept remote connections
Alright, I finally solved the problem and not in a way people would think. First off, I want to thank everyone who responded with the intelligent answers, but we were off base on this one and I'm not sure why, but your responses ultimately led to my defeating this problem. I've been wrestling with this problem for the last 3 days almost exclusively - I don't like being beaten - and 1 entire night. I've uninstalled and re-installed several times and even got superstitious and waved a chicken bone - lol - at it but nothing worked! I've asked this question on several web sites and finally I went to a link that stated the .msi file was included with MS SQL Server 2012 Management objects I and was hesitant to download as they pertained to the 2012 version. So after tinkering to no avail I downloaded the 2012 CLR Types and Management Objects and looked in the Windows\assemblies folder and still no v 11. But I guess 2012 installation installed them in Program Files (x86)\Microsoft SQL Server\110\SDK\assemblies\Microsoft.SqlServer.Management.Sdk.Sfc.dll v11.0.2100.60. I ran VS 2013 and added the data source. After going through all this problem I'm wondering why Microsoft invents all these places to put things when one would work. Every version of windows from 3 to present has always been totally revised and I wonder for what. Improvements are okay but quit reinventing the wheel. Without your help I might not have ever found the solution and perhaps would have been an oracle or mysql guru or not. Your the men. Thanks all.
Do not connect to mdf, connect to the SQL Server and use MyEntertainmentDB database from there.
The MDF file is locked by the SQL Server for reading/writing data.
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.
I have a problem connection to a SQL Server 2012 instance running on Windows Server 2012. I have a .NET 4.5 windows forms application installed on a client machine running Windows 7. The error I get is this:
A connection was successfully established with the server, but then an error
occurred during the pre-login handshake. (provider: SSL Provider, error: 0 -
The wait operation timed out.)
My connection string looks like this:
server=SERVERNAME;database=DATABASENAME;User Id=someuser;password=somepassword;Timeout=60;app=LabelMaker
I tried connecting to the SQL Server from the client machine using QueryExpress
and that worked! My app is 64-bit if that is of any help. I've checked every setting I can think of in SQL Server. No force encryptions are enabled on the protocols (shared memory and tcp/ip), the domain firewall is open on the server. I've tried various connection strings with all kinds of unheard off parameters, always the same result, failure.
I'm really confused about why it works with QueryExpress? My app works when connected to a remote instance of SQL SERVER Express on another machine, it also works if I run it on the SQL Server 2012 machine.
I've also tried connecting to the server from the client machine with LinqPad and this is also really weird, with the new version based on net4/4.5 (Version: 4.43.06) it fails but when I use the old version of Linqpad (2.x) based on net3.5 it works!
It seems like Panda Security is causing the problem, I ran
netsh winsock show catalog
and found a few panda entries, I then did a reset
netsh winsock reset
now my application works fine, I then rebooted the machine, ran the catalog command again,
the panda entries were back and my app is having the same problem as before.
Here are the Panda entries in the winsock catalogue: https://gist.github.com/pellehenriksson/5159883
All ideas and suggestions are appreciated.
UPDATE
Panda Security v5 is the cause of this problem, this has been confirmed by Panda support.
The root cause of the problem is explained by Alex below. The customer will do an upgrade to v6 of Panda Security, I will test again after the upgrade.
CONCLUSION
Moving to Panda Security v6.0 fixed this issue.
This seems to be a non-Microsoft related issue: Visual Studio 11 beta installation disabled my abillity to connect remote MS SQL Server but not local databases.
The ticket has been closed as external.
The only workaround available at this time on Microsoft Connect is:
Posted by Lars Joakim Nilsson on 5/4/2012 at 5:03 AM
My machine had this problem. The work around for me was to remove non-IFS LSP installed Winsock Catalog Provider. Se
http://support.microsoft.com/kb/2568167
/Lars Nilsson
The SetFileCompletionNotificationModes API causes an IO completion port not work correctly with a non-IFS LSP installed link gives the resolution:
Not specifying the FILE_SKIP_COMPLETION_PORT_ON_SUCCESS flag or
removing any non-IFS Winsock LSPs installed. Also moving from a
non-IFS LSP to Windows Filter Platform (WFP) can resolve this issue.
So, you should remove Panda Security or, as an alternative, you may try to execute netsh winsock reset as a pre-build command (although I'm not sure if this is effective without a reboot), which would let you develop/debug your application.
[UPDATE]
More information about application compatibility is given here: Application Compatibility in the .NET Framework 4.5:
Data
SQLClient
Feature
Ability to connect to a SQL Server database from managed code that
runs under the .NET Framework 4.5.
Change
The existing synchronous API code path was modified to add
asynchronous support.
Impact
The presence of non-IFS Winsock Base Service Providers (BSPs) or Layered Service Providers (LSPs) may interfere with the ability to
connect to SQL Server. For more information, see
SetFileCompletionNotificationModes API causes an IO completion port
not work correctly with a non-IFS LSP installed on the Microsoft
Support website.
I hate to say it, but restarting Visual Studio and my Microsoft SQL Server Management Studio solved this problem.