I would answer: of the SQL query is as optimized as it can get and operating under set parameters, and the code loop is as optimized as it can get and operating under the described parameters, my answer would be 'Sit on it Potsie!'
No, seriously. if you have the SQL call as optimized as you can get it (ie reducing the necessity for as much looping as possible), and your code is good, then the answer is : slow and correct is always better than fast and wrong. The raw answer to the project leader of course is: That depends on what the business requirements of the code are.
Perhaps there is a bandwidth issue, you might be testing on a dog of a machine, or operating under reduced system resources. Who knows, the server might be a turd. You might have a virus on the client or server machines.
You might try paging your data, flushing after each line written, but given the question parameters there is not a whole lot you will be able to do if your SQL and code are correct and optimized.
I would also look at the code in Query Analyzer (on SQL server) to see the execution plan, test it on another client or server box.
Been there, done that. The PM has a case of RCI (Rectal Cranial Inversion) 
YM |
