>OK, yeah, I see that KB was rolled into SP2 now, but the DisableFlushOnCleanup was not automatically added to the registry so I manually made that change, but to no affect.
>
>Here's my problem: I can run a sample insert/modify/select routine on a file-based database and it takes:
>1. 3 seconds for accessing database/tables via local hard drive, non-shared access
>2. 3 seconds for accessing database/tables via local hard drive, shared access (another computer has database/tables open, but no activity).
>3. 7 seconds for accessing database/tables over the network, but non-shared access (sounds about right)
>3. 35 seconds for accessing database/tables over the network, shared access (another computer has database/tables open, but no activity). What the hell???!!!
>
>Some stats:
>1. The total database is 150MB.
>2. 58 tables in the database.
>3. The largest table is 37MB.
>4. The simple routine is merely adding records, doing some seeks (using existing indexes), making some field changes, and then performing a SQL-Select. The insert/change section is wrapped in a BEGING TRANSACTION... END TRANSACTION, but again, the other workstation isn't doing anything, just has the database/tables open.
>
>
>Anyone have an idea what is going on?

The pattern (slowdown only if the "breaking process" is on another WS, no slowdown on 2 processes on one machine) is rather typical for Oplock behaviour (WS "eliminating" network speed bottleneck by caching.) Base your optimization on Oplock set off (if you already checked SharingViolations settings). The 7 seconds imply that the WS has local caching: even in a GB network the bottleneck in throughput compared to local disk should be larger, if I assume current HW. 3 secs can move a lot of data locally, especially if ample caching is involved.

One thing I would check: have you measured without the transaction overhead ?

regards

thomas