I am having difficulty getting an application that uses SQL native client to connect to my SQL Server, which up until this point functioned just fine. SQL Profiler on the source server indicates my troublesome application isn't even connecting to the server. I can't find anything in the applications logs or the Windows Event logs.
I would like to independently prove that the issue is not SQL configuration on the machine by using another application to connect. I have tried ODBC with the SQLNCLI Driver, and it works fine but I'm not sure if that is the same as code that directly uses SQLNCLI. The matter is even more confused by the fact there are 32 bit and 64 bit versions of the driver available on my server. Are there any stand alone or command line utilities that I can use to emulate an applications connection to SQL and analyse any debug messages I might get back.
I'm on a server 2008 x64 machine, connecting to the SQL Server 2008 x64 Mirror.
Related
In our company we have to support a large legacy system built on Microsoft Access 2010 as frontend and SQL Server 2008 R2 as backend. The backend SQL server runs on Windows Server 2008 R2. Currently our users works on Terminal Server sessions on a Windows Server 2008 R2. A couple of days ago we started to test Windows Server 2019 and Notebooks with the latest version of Windows 10. We recognized a big performance difference while executing the same Access databases on the different environments.
For instance the creation of a report takes 27 seconds (new environment) instead of 7 seconds (old environment). The database.accdb is identical, the backend is identical (still Windows 2008 R2 Server with SQL Server 2008 R2 and SP2), only the execution environment (Windows) changed.
Does anyone of you have an idea how to explain this?
In Access 2010 the SQL server tables are linked using System-DSN data sources. On the old environment ODBC is used (Driver: SQL Server, Version: 6.01.7601.17514).
On the new environment I tested the following drivers:
ODBC Driver 11 for SQL Server (2014.120.5543.11)
ODBC Driver 17 for SQL Server (2017.173.01.01)
SQL Server (10.00.17763.01)
SQL Server Native Client 10.0 (2009.100.4000.00)
SQL Server Native Client 11.0 (2011.110.5058.00)
I created a new System-DSN using the different drivers and updated the linked tables in Access. But in any case the performance is still bad. I also tested the latest version of Access which comes with Office 2019, but again it is slow.
Sounds like your terminal sessions are getting throttled. Despite the fact that you have a SQL Server back end, Access is still doing a fair bit of thunking with the result sets, so any resource throttling differences between your Server 2008 and Server 2019 policies could be choking Access in the new server.
I think your answer is going to be found in Windows System Resource Manager. The page says it's not being maintained, but following the "Recommended Version" link leads to a generic Server 2019 page. Here's another article about how WSRM might be throttling sessions: Using WSRM to control RDS Dynamic Fair Share Scheduling.
Compare the Weighted_Remote_Sessions policy in 2008 and 2019 servers. There's either been a change to the default settings or behavior or the 2008 server policy was modified in the past to get to the current performance level.
Ok, a number of things to check.
First thing to check:
Launch the ODBC manager and check if SQL log tracing is on. I don’t know why, but I see sql logging turned on.
You NEED to be 100% sure it is turned off.
You MUST launch the ODBC manager from the command line or start menu, since the one in the control panel is for the x64 bit version, and you are using Access x32 (I assume).
So launch this version:
c:\Windows\SysWOW64\odbcad32.exe
So VERY important to launch the x32. It is assumed you are using a FILE dsn. So check these two settings:
(Make sure they are un-checked).
Next up?
Link access using the IP address of the sql server.
So, place of say:
myServer\SQLEXPRESS
Use:
10.50.10.101\SQLEXPRESS
(Of course use the IP address of sql server, not the above “example” IP).
The above things are quite easy to check.
Still no performance fix?
Then disable the fire wall on your new Terminal server (I seen this REALLY cause havoc).
And, disable windows defender on the new TS server if running.
The above tips should fix your issues.
If above don’t work, then next would be to check the priority settings for the TS server (GUI over server).
However, I am betting the above checks should restore your performance.
I have "inherited" a computer that has multiple ODBC driver's installed on it. Before I go removing anything, how do I tell which driver SQL Server is actually using? Does it just use the most updated one?
I am running SQL Server 2014, version 12.0.5207.0 (64 bit). I am also using SQL Server Management Studio 2017, version 17.5.
Additional question - I am planning to update the ODBC driver to 13.1, would I install the 64 bit since the server is 64 bit? When I look at the ODBC data sources the drivers are installed in both the 32-bit and 64-bit dialogues, so I am a bit confused. Total noob question, I realize, but I am very new to this.
That's not an easy answer. Let's break it into parts.
What driver is being used? The one the application requests. A driver is used by a client application to connect to the server, and the client application is the one that has the final say. You can look at the ODBC data sources configured in the machine to see the driver, but an application might not use an ODBC data source and instead embed the driver name into the application or some configuration file.
How can you tell? One way is to uninstall a driver and see what breaks. Usually not a good plan. Maybe you can use Process Monitor and check if any process load the drivers, but not Always feasible. If in doubt, leave the drivers alone. They are usually small and don't tend to cause trouble on their own.
As for SQL Server database engine and SQL Server Management Studio (SSMS), they normally don't use ODBC drivers. SSMS uses a .NET provider to connect to SQL Server. SQL Server database engine can use an ODBC driver if you have a linked server to another server.
If this is a database server and not an application server, chances are most drivers are rarelly used. If this is an application server, I'd leave the drivers alone. If it's a workstation, probably leave them alone too.
As for the new driver version, you need the 64-bit package to install, and it will install both 32 and 64-bit drivers. The reason is a 32-bit need a 32-bit driver, and a 64-bit application need a 64-bit driver. It's not the server bitness that matter in this case.
I am using the 64-bit version of SQL Server 2016 Express, trying to connect to a 32-bit Pervasive SQL v10 database. I am setting up a Linked Server in SQL Server via ODBC connection, but I am receiving this error that has given me a lot of pain in the past:
The specified DSN contains an architecture mismatch between the Driver and Application
I had a similar issue not long ago trying to connect to a Microsoft Access database, but with help here I was able to obtain the 64-bit ODBC driver for Access. However, there does not seem to be one for Pervasive v10 at all, only for PSQL v11+, which does not help me in this case.
Previous question: SQL Server Linked Server to MS Access - DSN Architecture Mismatch Error
So if anyone has a suggestion for connecting to a 32-bit client from a 64-bit SQL Server installation, when there does not exist a 64-bit ODBC driver for this client, please let me know.
One of the suggested solutions was to use an OLEDB link instead (but no details provided on this, and I'm not sure how it would differ from the linked server I am already trying to create, which is already using OLEDB).
There was also mention somewhere of installing an entirely separate 32-bit SQL Express client, and chaining an additional ODBC link to point to the first one, but I would rather avoid all that overhead if possible, especially since this is a production server that is already running Sage 50 in addition to our own software and web services with SQL Server...
Other details: The client that is built on Pervasive SQL v10 that I am trying to connect to is Peachtree 2017 - Sage 50. This is all running on Windows Server 2012 R2 Standard.
More reading here:
https://support.na.sage.com/selfservice/viewdocument.do?noCount=true&externalId=12693&sliceId=1&cmd=displayKC&dialogID=50216&docType=kc&noCount=true&isLoadPublishedVer=&stateId=50217&docTypeID=DT_Article&ViewedDocsListHelper=com.kanisa.apps.common.BaseViewedDocsListHelperImpl
https://www.experts-exchange.com/questions/23995371/Installing-Pervasive-SQL-Client-on-Windows-2008-64bit-missing-ODBC-Driver.html
Edit:
Thanks for the comments! After further investigation... it looks like this IS actually PSQL v11, not v10. Now, I'm not sure why the 64-bit ODBC driver is not already installed... but I am looking into this now...
This question may seems a bit silly. The thing is I'm programming a WPF using VS2010, which contains a .sdf database (connection is ADO.NET).
Someone told me that if I use a SQL Server Express database it can be run on any PC even it has no SQL Server installed. But after I tried executing in my virtual machine (win7 & win xp), seems it cannot even start up.
So, can someone brief me, what database do people normally use in developing WPF software? Is it true that my program using a SQL Server database file cannot execute on PC without SQL Server installed?
Much appreciate in advance!
Yes, it can!
SQL Server Compact (that produces and uses .sdf) is the only SQL Server edition that does not require a server to be installed. All its code and logic is contained in the handful of DLL's that you need to include with your application. Just ship your app with those DLL's and you should be fine.
Read more about SQL Server Compact and how to use and deploy it on MSDN.
SQL Server Express (and any of the other editions, like Web, Standard, Developer, Enterprise) on the other hand does require an installation of the SQL Server Express edition - either on that machine, or somewhere in the network where your app runs (remote connections from the network are disabled by default, but can be enabled).
I have two issues both related to (I believe) my SQL Server setup. I have installed SQL Server (the full thing) from MSDN downloads of the x64 version on my Vista 64 Home Premium box. After running into multiple issues I finally got it working. This is a new box so I ported over a database that I need to work on from another server. That also worked fine. My first issue however came when I tried to open a database in SQL Server Management Studio:
"Unable to find the requested .Net Framework Data Provider. It may not be installed. (System.Data)"
The box itself isn't new and definitely has .NET installed (version 3 I believe). I found that someone posted this as a bug but as the team (SQL Server team) could not reproduce it, they removed it. I've tried installing the recommended SP3 patch to no avail. It's only when I try to open a table for viewing the data (right-click and "Open Table"). I can even execute queries and retrieve results (from inside management studio). I'll follow pretty much any suggestion to try and get this working.
My second issue is that I cannot connect to the server. I thought I could just work around it (with queries), but I did not find that it added any ODBC connections on the box, just the drivers. Management Studio can access the DB just fine, but the machine itself doesn't appear to recognize that anything is running on it, at least on the default port (1433) and no, I do not have a named instance. When trying to manually add the server to the DSN or any datasources it cannot find the SQL server (under Control Panel > Administrative Tools > Data Sources (ODBC). Under SQL Server Management Studio it appears as a registered database server (I think this is because it connects on port 1434 from what I hear? not sure). This is my primary problem, and even if I can't open the tables (the first issue) I absolutely NEED to be able to set it up so that I can connect to it. The language source I am connecting from is ColdFusion which is set up as a stand-alone server (IIS not installed, not using it right now).
As for connecting to it, make sure all the services are running. SQL Server Agent in particular.
Also, check in the SQL Server 2005 Surface Area configuration for Services and Connections. Check under "Remote Connections" to see if "local and remote" connections are on. It might be set to "local only".
CF versions 6+ do not use the OS's ODBC connections. They use JDBC over IP to connect. You need to make sure you have allowed TCP/IP connections to the DB using the SQL Server Configuration Studio. Then, use the Data Sources page in the CF Administrator page (usually localhost:port/cfide/administrator, replacing "port" with the port you're using for the CF built-in server).
Why though, would it default to this
and why would this be an issue with my
own machine (local testing)?
SQL Server 2005 is meant to be more secure by default, so not all the protocols are opened up by default.
Sql Server Agent doesn't have anything
to do with remote connections, but I
seemed to recall there being an issue
with doing discovery on the network if
the Agent wasn't started
Maybe you're thinking of the SQL Browser with named instances.
Did you try this process?
http://oakleafblog.blogspot.com/2007/03/orcas-march-ctp-on-vista-database.html