I'm trying to figure out what query will get the host OS, whether if it's a Linux or Windows OS.
Querying sys.dm_os_host_info seems to get the results I need but that table doesn't seem to exist on SQL Server < 2017.
Related
Microsoft® Access® for Microsoft 365 MSO (Version 2202 Build 16.0.14931.20888) 64-bit
Microsoft SQL Server 2019 - 15.0.4261.1 (X64) Copyright (C) 2019 Microsoft Corporation Standard Edition (64-bit) on Windows Server 2016 Datacenter 10.0
System Type 64 bit operating system, x64-based processor
I've created an ODBC 64-bit file DSN connection for a MS Access Pass-Through Query to a SQL Server database. I've got a large query that runs on the client side in around five minutes; the query appears to run and correctly return the requested records. The ODBC Timeout is set to 540 (seconds). The problem is that the server shows that the query ran for over forty-five minutes before I was contacted by a DBA. I terminated Access and that severed the connection.
Would anyone know why this might happen or how I could troubleshoot?
You can trace a query to see when different phases of the query complete.
Typically, when something impossible seems to be going on, when you look closer there's some easy explanation. Is there a transaction that's left open? Does running the query trigger updating statistics? Why does the DBA think the query keeps running? There's nothing unique about ODBC querying the database that would allow it to keep running without terminating. A first step might be to just run the query directly within SQL Studio and see if you can reproduce.
https://learn.microsoft.com/en-us/troubleshoot/sql/database-engine/performance/troubleshoot-never-ending-query?tabs=2008-2014
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 Windows 7 running on my machine (I know it's old) and when I try to install SQL Server 2017 using the setup utility, I get this error:
The operating system on this computer does not meet the min requirements for SQL Server 2017. To determine the min required OS supported for this SQL server release, see the hardware and software requirements.
This is the link provided: Hardware and Software Requirements for Installing SQL Server
I don't see anything there that stands out that my machine does not have. I know people have installed SQL Server 2017 on Windows 7 boxes, so that can't be the issue.
I tried changing the compatibility mode by right clicking the setup file and properties too, to Windows 7 but I still can't get passed that error message.
I think at the link you provided Windows 7 is actually not in the list of OS supported? Here it's also mentioned SQl Server 2017 can only be installed on Windows 8 or Windows Server 2012 and later versions.
I need to create Link Server in SQL Server 2012 Enterprise 64 using Oracle ODAC.
I have done everything I know, including multiple re-installation of Windows Server 2012 Standard R2 64. The ODAC is also 64bit.
I am able to connect to Oracle 11g using Oracle SQL Developer using TNS as Connection Type.
I am beginning to think this may have something to do with Windows Server. Because I have never experience this issue on other systems not running Windows Server.
I get this error:
returned message "ORA-12154: TNS:could not resolve the connect identifier specified.
Thanks
After combining through hundreds of internet posts and install/reinstall. I discovered the problem was the ORACLE ODAC Components. Every article on the internet tells you to install 64bit ODAC if you are running 64bit database, however, this is not accurate.
After spending two days trying to get this to work, I decided to try the 32bit ODAC and it worked.
In case anyone is having this same issue.
I have a SQL Server 2012 database with an Access 2007 front-end. My problem is that Access does not recognise SQL Server's dates as they are in a different format.
SQL Server-s format is YYYY-MM-DD
Access' format is DD-MM-YYYY
When the date is displayed in a text-box, it is displayed as a string (without the little calendar icon next to it).
Is there anyway I can configure my Access front-end so that it recognises SQL Server's dates?
I used Microsoft SQL Server Migration Assistant for Access to migrate the data into SQL Server
As this DB is in development I have the SQL Server on my local machine in C drive (no virtual drives)
From my research I have found this answer:
The problem the user has encountered is with a Driver. Microsoft has a new DLL that must be put on a client
workstation (or server in the case of Citrix). Once that is done, all the dates in MS Access will work
properly. My lastest experience with Access 2010 was exactly the same as Access 2003.
It required a DLL. From there, investigate using a DNS-Less connection string
Where would I find this DDL driver and how would I install it.
Thanks
Maggs
I found that SSMA for some reason converted all the datetimes to datetime2. I went into SQL Server Management Studio and changed them to datetimes and it fixed the issue. You could also check the field mapping in SSMA and adjust it before migrating.
(I have the exact same environment - SQL Server 2012 and Access 2007, using SSMA.)
I am using SQL Server 2012 on my local PC (Vista) and have an Access 2010 frontend with ~75 linked tables.
The table in SQL Server has a column named 'EnteredDate' that is defined as 'datetime'.
In Access the 'EnteredDate'column is defined as 'Date/Time'.
In Access, I just ran the following query with proper results:
SELECT DataError.Description, DataError.EnteredDate
FROM DataError
WHERE (((DataError.EnteredDate) Between #1/1/2010# And #1/31/2010#));