Slow connection/interaction with SQL Server 2008

  • 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/sql query construction issue).

    We have tested each machine using a SQL Server instance installed locally on each machine (so it is not a network issue).

    We tested all four machines using the same SQL Server 2008 instance located on a separate server (so it is not a SQL Server version difference issue).

    All machines have the same version native client dll (sqlncli10.dll), which I believe deals with communication to SQL Server.

    All machines are comparable in processor speed and RAM.

    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).

    So it appears the communication between the application and SQL Server differs on the machines. Is there more to the communication than the Native Client dll I listed above?

    Any suggestions on what else I can check with regard to this communication?

    Thanks in advance

  • Hello, I impact with same problem and my resolve was install SQL Server Enterprise edition (with trial 180-days licence). It's problem often occur with express edition of sql server.

    English is my second language, therefore sorry for mistakes 🙂

  • 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.

Viewing 3 posts - 1 through 2 (of 2 total)

You must be logged in to reply to this topic. Login to reply