Question Locked

need help from a VB.net expert.... Hitting SQL server taking 3 minutes....

0 helpful
4 replies
Closed to new repliesThis discussion is closed. It stays readable, but it takes no new replies.

Hi all.

Here is my problem.

We have a SQL procedure that we were calling in a development environment, no problem... ran fairly fast.... no difference between the time it took to run in SQL server management studio and the VB app.

We move it to a staging environment...

The proc takes a few seconds longer to process on SQL Server, (about 12 seconds) but it takes about 3 minutes to process through Visual studio.net.

The only thing I changed was the server name in the connection string.

Does anyone know what could do this?

4 replies

by tony hopkinson

More data in live.

Different schema in live (been known to happen, missing index, oops

Different network path.

Where you go from here depends on how much access you are allowed to the live system.

If it's none, and I've been there. My solution was to stick a command line parameter, (app.config would be more modern :D )

With a flag and a file, and then just dump a load of elapsed times to see where in the code the problem was.

Once it turned out to be a DNS server temorarily out of service and the other one went though a convoluted route that somehow how blocked reverse DNS lookup, so the actual problem was in achieving a connection which of course this code did on the fly.

by tell it like i see it

Put some code in place to essentially log exactly when certain points are reached in your program. Run it and see where the most time is spent.

Given a suspicion I have, put such statements immediately before you open your connection and immediately after it is opened.

I've seen times where an initial connection to the server would take a very long time; but once the initial connection was made, everything worked quickly.

Another way to test this is to change the connection string so it uses the server's IP address instead of the server name.

In my case, it was found that the client machine (which took so long), was pointing to a DNS server that no longer existed. It
took everyone by surprise because this machine was set up with a hard-coded DNS entries instead of getting them automatically.

If the issue is not DNS-related and you need help, then it may be good to post some additional information on exactly where the code is slow.

by aikimark

Is the volume of data different between the development and production databases? Maybe the development tables were small enough to process a table scan quickly, and the production table requires an index.

This discussion is closed to new replies.