Please start any new threads on our new site at https://forums.sqlteam.com. We've got lots of great SQL Server experts to answer whatever question you can come up with.

 All Forums
 SQL Server 2008 Forums
 SQL Server Administration (2008)
 Slow Native Client?

Author  Topic 

markjack99
Starting Member

3 Posts

Posted - 2011-03-02 : 10:46:57
We are developing an application which uses SQL Server 2008 R2 Express Edition. The application reads an index file, processes the lines, and inserts data into the database. On two machines, a particular import process takes 3 minutes - on two other machines, the same process takes 13 minutes. We cannot figure out what is causing the difference.

We are running the same application code on all 4 machines (so it is not a code issue).
We have tested each machine using a SQL Server instance installed locally on each machine (so it is not a network issue).
We changed to have the machines use the same SQL Server instance on a separate server (so it is not a SQL Server difference issue).
Since we are reading a file (4000+ lines), I temporarily stripped out all the SQL statements to see how fast the application was reading and processing the lines in the file (less than 1 second) (so it is not an issue with reading and processing the lines in the file).
All machines have the same version native client dll (sqlncli10.dll), which I believe deals with communication to SQL Server.

It seems to be slow when executing any code which interacts with SQL Server - but only on two machines.

Does anyone know what else we to check with regard to this interaction?

Any help is greatly appreciated.

markjack99
Starting Member

3 Posts

Posted - 2011-03-03 : 10:01:25
Finally found it

While using a process explorer to compare dlls running on each machine, we noticed the slow machines were running an odbctrac.dll (trace file).

Our application has a sql configuration file (sql.ini) where we put such information as DSN settings. The sql.ini files on the slow machines had a trace file listed which was obviously causing the trace to be run - the fast machines had this line commented out.

Commented this line out on the slow machines and they are up to speed.

Seems simple now that we found it.
Go to Top of Page
   

- Advertisement -