We are running Windows Server 2008 R2 (64-bit), SQL Server 2008 R2 (64-bit) and a 32-bit Java application all on the same server. The application uses the Microsoft JDBC Driver v3. The application can use Java 5 or Java 6, but both as 32-bit JRE's. So the driver can be type 3 or type 4.
Here's what we see: When the application runs, database access can become quite slow when under any type of load. When you remove the load, it will be okay. Put it under load again, and it becomes slow.
The complex part of this is: If we run the application on a separate but equal server from the database, it is not slow.
So it appears that the behavior of the driver is different. When driver and database are on the same server (reached through the local stack), then the mix of 32-bit and 64-bit slows things down. When the driver and database are separate from each other (reached through the network), then the mix does not cause a slow down.
Any thoughts?
We do not expect the application and database to be on the same server. But we have sales people who demonstrate on a single laptop, so they need it all together. Currently, we look like we will be forced to isolate using VM's or similar. Not what sales wants.
Technically, we are curious why introducing the network makes a difference.
Related
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 have been working on a project using Visual Studio 2015 along with vb.net and mysql. I deployed my application using ClickOnce to my company server then installed on all the computers in my company. It is working fine. Recently, i have it installed on three new computers which has the exact same os and specs with the existing computers, however, the application installed on the three new computers showed a very significant difference in performance comparing to the existing computers, it is much slower in the new computers.
I have checked through
the networks
the connection to MySql database
the memory it consumes
the .net framework version
but it is all exactly the same with the existing computers. does anyone have any idea what might be the cause? Or anyway to troubleshoot this problem?
Just add timers, stopwatches, etc to instrumented builds. In fact, in an application of any size I build-in, from the off, at least a skeletal diagnostic system with a display window and stopwatches that can be used to time specific bits of code - typically database queries. With that in place, it's simple to add specifics to produce instrumented builds to drill down to any problems that only occur on end-users' machines. You can also download DbgView from Microsoft and use that in conjunction with Trace statements in your code.
My company has developed an application with Visual Basic 6.
The application uses an Access database via an ODBC datasource.
The Access database is a file with the ".mdb" extension.
We have not noticed any slow data access when running the application in the following environment :
OS : Windows 7 32 bits.
Installed version of MS Access : Access 2007.
Access driver used by the OBDC datasource : Microsoft Access Driver (*.mdb) version 6.01.7601.17632.
But we have noticed slow data access when running the application in the following environment :
OS : Windows 7 64 bits.
Installed version of MS Access : Access 2010 or 2003.
Access driver used by the ODBC datasource : Microsoft Access Driver (*.mdb) version 6.01.7601.17632.
I have googled for a while to find a solution.
Other developpers have experienced the same problem according to articles found on the Internet.
For information the tracing feature is not enabled in my ODBC 32 bits administrator.
The following page mentions the tracing feature :
http://answers.microsoft.com/en-us/office/forum/office_2010-access/my-solution-to-access-being-slow-with-odbc/a5a6522f-a70f-421e-af1b-48327075e010
I have also tried without success to disable the LLMNR protocol as mentionned in the following page :
http://accessexperts.net/blog/2011/11/02/windows-7-64bit-slow-with-access-2007-solved/
Any help will be greatly appreciated
There are number things to check, the first and foremost thing you want to do is create in your application what we call a persistent connection. A persistent connection simply means that somewhere in your startup code, you open up a table from the back end to a record set, and keep it open for the duration of any other operations you do in that application.
The reason why a persistent connection often makes a huge difference is that the newer operating systems tend to do have a tremendous amount of additional security and overhead when a connection to the databases created. And it turns out that generally opening and closing tables in access databases requires that these connections are also opened and closed. If you force the persistent connection to remain open at all times, then this very slow and large overhead process that interferes with general performance of general updates in your code will now not be incurred.
Give the above a try, since this setup very often cure is this performance issue and problem.
I usually make applications with the front end in Access 2003 - 2007 and the back-end on SQL Server 2008. When I create an ODBC to link the tables in access I have two choices in the ODBC Data Source Administration page on my Windows XP PC:
Server 2008: SQL Server Native Client 10.0 v.2007.100.2531.00
SQL Server v. 2000.85.1132.00
Which of these should be better and compatible on PCs with just Access 2000?
The native client has support for some additional (more advanced?) features of sql server 2008 (and 2005 I believe).
However, out of the box, you are far more likely to find the standard sql server driver installed on the computer.
Unless you are using some type of installer, or some other software installs this native client driver, then you are best to stick with the default non native driver for maximum compatibility. And, there is just the plain issue that the standard driver is most likely to be already installed on your client side computer.
So, that new native driver not going to be installed by default, and you likely have somewhat better luck with the non native default driver. I had a few issues come up with exporting date columns when using the new native driver (can't recall just right now what the issue was, but there was an issue).
Note that your connection strings are/will be slightly different for the native driver, and if you have some re-link code, that code will fail on computers without the native driver. So, while you have both on your computer, you can't assume this will be the case on other computers. So, you should have special and good reaons to choose/use the new native drivers for 2008/2005, but if not, then use the standard ones.
We have just moved our high volume ASP classic website from Windows server 2003, 32bit, iis6, Mysql to server 2008, 64bit, IIS7.
We are experiance some truncated data and page slow downs on some pages that make a lot of calls on the DB. We are using ODBC Driver 3.51.
We are pretty sure it is the ODBC driver but have no idea how to fix it
Any ideas
Thanks in advance.
The answer is simple. Many of the sql queries on the site are handled badly by ODBC Driver 3.51.
Slowness and truncation of data being some of the obvious problems and can often be fixed by rewriting the way loops through data can be handled. Handling a lot of processing in memory has also helped.
We are going to test a newer version of ODBC client soon to see if that is faster and more stable.