Background:
I've been supporting a legacy MS Access Front end with Linked Tables to SQL Server for about a year. The code is terrible, and we're re-writing as an MVC App. But for the next year or so we still have to support it.
Last week I upgraded my laptop. More RAM, bigger HHD etc ... On my old laptop, I had a copy of the SQL Express Database, and the Access, and it ran fine. I open a form in Access, and it appeared after a couple of seconds.
New laptop. Twice the RAM ... takes minutes to load the same form with the same database running locally. When I look at the SQL Server, I see the queries that the Access is calling and they're all with ASYNC_NETWORK_IO
My task manager on my PC shows memory running at 40%, and CPU at 30%. There is no network as Access and SQL are on the same PC.
Does anyone know why the Access front end would be taking minutes on my new laptop, compared to seconds on the old, to load the same form?
Thanks in advance.
Answering my own question for the next unfortunate person who has the issue.
On my old laptop I was running SQL Express 2019
On my new laptop I installed SQL Developer Edition 2019
Clutching at straws, I installed Express 2019 on the new laptop, changed the connection string, and it's back to working normally!
Unbelievable that using Developer Edition caused so much more heartache than Express ... would love if someone could answer that for me!
Related
I know this is a well trodden path, but my review of SO posts around this yielded no results. So this is a fresh installation of MySQL and Visual Studio 2019 on my dev machine - like both literally vanilla tonight. I used the Development installation for MySQL:
So I can connect to a test database just fine with Server Explorer. I can also Add Connection fine (that is it sees the remote database), but when I come to click next on Choose your data connection, I get this error:
I come across this problem every time I try to set up MySql and VS together. On this occation, I'm working with the latest MySQL version and thus have gone for the latest MySql binaries. As I say, I've reviewed all of the historic SO posts, but cant apply them to this. Does anyone have any ideas? (I had to downgrade to VS2019 because there's no MySql for VS 2022).
Until now we were Running a MSSQL 2019 Enterprise Server on Windows Server 2016. The MSSQL-Server is used for Business Intelligence, so it's also executing SSIS-Packages, stored in the Integration Services Catalog, using a SQL Server Agent Job. On the Windows 2016 Server this job took about 4 minutes for a regular refresh.
After switching to the new Windows Server 2019 it takes about 12 minutes, or three times slower. I already checked all settings of SQL Server and Databases. They all match the old setup. Disk, CPU and RAM also match and benchmarks show no issues. Also the new Server uses new Storage which is much faster than the old one. So it all comes down to Network Performance which seems to be far worse in Windows Server 2019 than 2016.
Does anyone have any idea what could be the issue here? I googled around and couldn't find any real solution to this. It seems like it's known that Win 2019 has less Performance than 2016. But the threads talking about this (without a solution) are several years old. I can't believe that this hasn't been resolved in the last 3 years.
Any help is appreciated.
Edit: Additional Explanation:
The SSIS Packages load Data from different locations. Another MSSQL-Server running on a Win 2016 Server and several Postgres-DBs running on Debian. The Data is stored on the mentioned SQL Server on Win 2016 (old) / 2019 (new) Server. Sure there are Lookups in the Packages. But the Packages are exactly the same. Also are the Databases, Tables, SQL Server Configuration and so on. The only difference is the Operating System. I'm exoecting the issue being around the Network Interface/Functionality of the OS because CPU, RAM, SSD are all ruled out because they are also identical and Benchmarks show no Issues. Also I noticed huge differences on Copying a 1GB File to the Servers using Remote-Desktop. The Copy on 2016 Server takes about 1:40min and on the 2019 Server 3:30min. Will do more benchmarks.
Update: I made additional tests. I wanted to know where exactly the ssis-Packages take longer to execute. So I made this setup: I installed Visual Studio 2019 Enterprise on both Windows Servers, the 2016 and the 2019 one. Then I copied the SSIS-Project to both machines and configured them to use the MSSQL-Database of it's localhost. Then I first executed single packages and then a larger Master-Package. After this I compared the Execution Times. And there was no difference. All packages executed in Visual Studio directly on the Server took almost the same amount of time.
Then I created a simple SQL Agent Job on both machines to execute the larger Master Package and only that. In Visual Studio the execution took about 2:40 minutes on both Machines. When I executed the same packe with the SQL Agent Job I got the following durations:
Windows Server 2016 with SQL Server 2019: 2:01 minutes
Windows Server 2019 with SQL Server 2019: 3:43 minutes
So the 2016 Setup was faster using the SQL Agent (which is reasonable because less overhead than the VS Execution), but the 2019 Setup was about 30% slower. As the Visual Studio Execution is virtualy the same than the SQL Server Agent Execution there has to be an issue with the SQL Server Agent causing it o be much slower as the one of the SQL Server running on Windows 2019. I have no idea what this could be.
We solved the mystery. Our environment is a ProxMox Virtualization Environment. The Harddisks of the SQL Server were mounted as SCSI. After we switched to SATA it got a huge increase in Perfomance. I don't know why because SCSI should be faster. All the drivers were up to date and the SCSI Controller was in Write Back-Mode. But this is an issue of our IT where I'm not involved. The reason for the drop in perfomance was because the old Server used SATA und the new one SCSI, as I said.
We have an Access Database-Solution with Frontend and Backend Database running for years.
Now within the last two days problems occurred. E.g.
Set db = DBEngine.OpenDatabase(strDatabasePath, False, True, "MS Access;PWD=" & strPassword)
Does result in Error 3050 - File could not be locked. ONLY when the Backend Database is on a network share (if it's on a local drive everything works as expected).
The error occurs on any share:
a Shared Folder from a Windows PC
a Shared (Samba) Folder on a NAS
independently whether the share is accessed via a UNC-Path (\server\share) or a mapped drive-path.
The error was introduced by a faulty Office Patch (seems it was V2111 - 14701.20240)
In the first version of this post I thought that Windows-Update KB5008212 was causing the problem.
Thanks to #Gustav for identifying the problem.
How do we find out WHEN MS pleases to fix the problem?
From Microsoft:
This is due to today’s (Patch Tuesday) update to Office. The problem
was introduced by a security fix, so it impacts all active versions of
Access. We are working on a fix, and will deliver it as quickly as
possible.
The update has only been set to automatically update a very small
percentage of users, and it looks like we will be able to pause
automatic updates, so it will not propagate.
There will be a page added to the
Fixes or workarounds for recent issues in Access (microsoft.com),
which will then be the place to go
for updates.
These are the updates that introduced the problem:
KB 5002104 for Office 2013
KB 5002099 for Office 2016
Office 2019 Version 1808, build 10381.20020
Office LTSC 2021 Version 2108, build 14332.20204
Microsoft 365 Apps:
Current Channel Version 2111, build 14701.20248
Monthly Enterprise Channel Version 2110, build 14527.20340
Monthly Enterprise Channel Version 2109, build 14430.20380
Semi-Annual Enterprise Channel (Preview) Version 2108, build 14326.20692
Semi-Annual Enterprise Channel Version 2102, build 13801.21086
Semi-Annual Enterprise Channel Version 2008, build 13127.21842
If you did get updated to one of those builds, the only solution
currently is to move back to an earlier build in the channel.
Installing version 2008, in fact, resolved the issue for me. Microsoft just released new builds of versions 2108 and 2112 yesterday, 01/11/2022, that also resolved this same issue for me.
We had the same problems.
Uninstalling Office 365 (32-bits) and re-installing Office 365 (32-bits) from the OfficeWeb-Portal seems to solve the problem.
Ours is not manifesting in the same way. I seem to get a lot of orphaned lock files. Users are having some problems getting in to the databases but usually If I delete the lock file and have them wait 5 minutes, the problem goes away. Since this started it has been a game of running daily backups to a separate file just in case. Major Pain in the you know what. I'll keep an eye on what crops up here. Thanks folks (Yes this is more of a comment than an Answer, but I needed more characters)
We've got some MS Access 2007 apps here. I'm responsible for one. Normally, it never gives any problems. I haven't heard from the users of this app for over a year, until today. It was written years ago by someone (I don't know who) that is long gone, with little documentation. We're in the process of replacing all of our Windows 7 machines with Windows 10 machines. At first I thought that was the issue. However, one of my colleagues, who is responsible for a number of Access 2007 apps, said that his users are able to use their Access apps with no problem.
Looking back at the user's error, it says simply, "ODBC - call failed". No error number; just that. So, my next thought was maybe there was a missing DSN on the new Windows 10 machine. However, I asked the PC tech to check one of the working Windows 7 machines. He told me there were no DSN's in them. I'm not an Access developer, so I asked my colleague, who does do Access development, what he could discover. He found that the tables are all linked tables from a SQL Server database. Looking at what he was referring to (now that I know where to look) I saw what he meant. The connection to each of those tables uses trusted connections. They're all pointing to the correct SQL database server. That server is there. When I got into SSMS I could easily see data in the tables.
So, what could be causing that error to occur, especially since it doesn't look like it needs a DSN to make a connection to the SQL db?
I presume your Windows 10 is 64-bit.
And probably your Access is 32-bit.
Its important to know!
If my assumptions are correct, you need to use the 32-bit version of ODBC admin to setup the DSN.
The 32-bit version is 'C:\Windows\SysWOW64\odbc32.exe'
The 64-bit version is 'C:\Windows\System32\odbc32.exe'
32-bit Access will look for a DSN setup using the 32-bit version of ODBC admin, even on a 64-bit OS. If you setup the DSN with the 64-bit version of ODBC admin, then a 32-bit Access will not see it!
Go back on the Windows 7 PC, and check exactly how the DSN is setup.
Is it a System, User, or File DSN?
Which drivers are installed for SQL Server?
(There are various different ODBC clients available for SQL Server.)
Replicate this DSN configuration when you create the DSN on Windows 10.
It sounds like you using the 'SQL Server Native Client' on Windows 7,
so make sure to install that on Windows 10.
See: Installing SQL Server Native Client
I am running about 10 asp.net websites on a hosted virtual server.
The server runs Server 2008 - each website is backed by its own database running on SQL server 2008 on the same box.
Lately the box has seemed really slow. The only kind of discovery i could think of doing was looking in the task manager, where i can see w3wp and sqlserver.exe jumping to 40% cpu usage every 5-10 seconds.
What are the steps i can take to determine which of my websites is taking these resources and or what database is getting hit the most? I have of course ssms installed on the machine as well.
As you can tell, my sysadmin skills are very very limited - any help would be much appreciated.
This may be better asked at serverfault.com