>Another observation that we made is with transactions. Tae following example -
> 1> insert hundred records in a table
> 2> after each record is inserted, commit the transaction.
>Now these steps give different output on different machines. On Windows 7 and XP they give results in 1.5 seconds.

>But on Windows 2008 R2 this takes 22 seconds. Now when we changed the application to commit at the end or hundred inserts then output was >almost same on both the machines.

>Any thoughts on this?

If you do the same test, but with READING instead of writing does it also behave the same way?

It might be your network card rather than your OS. AFAIK for every transaction started, it need to renegotiate the network speed, so if you have a network consisting of a mix of 100 base and 1000 base (Gigabit) cards then the network controller is constantly having to decide at what speed to run for each new transaction. Try setting all PC's on the network to run at 100 base, and see if it improves the speed. Also, check you have the correct cabling, and hubs for the network speed you are running. In addition, some cards have a throttling setting that deliberately slow down the network if to many packets are thrown at it. (supposed to be a security thing I think) We've only really come across that once or twice though.

Lately though, I've just started analysing all my code where I have to fire off a whole lot of read queries in a row, and am now making sure I start one single shared read-only transaction before starting my load routine, and it's made a good difference even on PC's that didn't seem to be experiencing this problem.

If reading is fine, and it's only writing that's slow, then I'd guess the problem is elsewhere though.. maybe that's when it's writing to disk.

Just my 2c, hope it helps. I must say though, that when we get reports of speed issues, Windows 2008 usually is usually mentioned a lot, so I'm also watching this thread with interest ;-)

Maya