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.
Related
Having to support an older VB.Net application, I get performance issues when several workstations are working with the MySQL database via ODBC at the same time. I'm now thinking about switching from ODBC to the MySQL Connector/NET.
I don't know Connector/NET at all. Does anybody have experiences with a switch like this? Are there any caveats? Is it even worthwile? Would it be a lot of work (the app relies heavily on MySQL)? I didn't find anything about the efford needed. Any thoughts? Thanks.
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.
Well, this is a bit awkward. I currently have a set of reports on a 32-bit sql server 2005 instance that references an access database on a network location. I'm currently trying to migrate these over to my new reporting services instance (sql server 2008 64-bit), and i've ran into an issue.
Well, i did a google search on the error and got a bunch of stuff saying to compile to use x86 and use 32-bit, etc., but none of it even touch on if i was getting this in rpeorting services.
My question is, is there a way to "fix" this, or some sort of work-around? Perhaps there's another provide i can use to get to the access database?
Any ideas would be much appreciated.
Ran into the exact same problem today, as you alluded to there is no 64-bit Microsoft.Jet.OLEDB.4.0 provider available. This impacts reports that attempt to use Excel and Access datasources on a 64-bit Reporting Services instance. Here is the KB article confirming that no 64-bit Jet driver is available:
http://support.microsoft.com/kb/957570
The solution I found is from this forum post on MSDN:
http://social.msdn.microsoft.com/Forums/en-US/sqlreportingservices/thread/9e999fb4-5a39-41c4-8fd7-46193a223673/
It involves creating an SSIS package that reads the Excel or Access data source, running the SSIS package in 32-bit mode, and using the SSIS package as the report datasource. Not ideal, but it works.
I'm afraid this is the nasty workaround to which we're limited.
I ran across this, which worked in a specific case:
http://danielcai.blogspot.com/2011/02/solution-run-jet-database-engine-on-64.html
From that post:
Microsoft has released a 64-bit compatible Jet database engine last year. The following is the procedure that you may use to fix this issue:
Download Microsoft Access Database Engine 2010 Redistributable (of
course you'll need to choose the right bit for your server), and
install it on your server
Change your connection string in your code or configuration file from
Provider=Microsoft.Jet.OLEDB.4.0;
to
Provider=Microsoft.ACE.OLEDB.12.0;
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.
I have a client, that uses SQLDMO for a portion of a custom application that was written against SQL Server 2000, and they recently upgraded to SQL Server 2008.
The majority of the app still runs fine (doesn't use SQLDMO), but the admin functions which rely on SQLDMO stopped working.
I installed the SQL2005 backward compatibility pack, and now SQLDMO partially works, i.e. I can run "select" type queries, but any "Update" queries fail with the error message:
to connect to the server you must use SQL Server management studio or sql server management objects (SMO)
Any thoughts? Should the backward compatibility pack give me ALL the functionality back, or is this a known issue?
BTW: I realize SQLDMO has been deprecated and will go away next release, none-the-less I need to do what I can to solve the problem at hand.
OK, I figured it out. Not only do you need to apply the "Backward compatibility pack" to the server, you also need to install (and register), the newest SQLDMO.DLL file on each of the client workstations.
Hopefully this save someone else a bit of time someday.