Inherited a system that causes a lot of dead locks because of the IX locks and IS locks on the system. It will be dead easy if simple sql didn't
attempt any lock on a sql when you only want a snapshot of the data.
Releasing locks quickly for applications that support high numbers of users is more important in SQL Server than in Oracle. Releasing locks quickly is usually a matter of keeping transactions short. If possible, a transaction should neither span multiple round-trips to the server nor wait for the user to respond. You also need to code your application to fetch data as quickly as possible because unfetched data scans can hold share locks at the server and thus block updaters.
But I would shoot any developer who codes long transaction in ANY platform.
Have you looked at the VB Code?
I bet it's dynamic SQL, openening a rs connection with SELECT * FROM yourTable...
And then, the guy/gal goes to lunch...about right?
worse, stored procs with EXEC and then then they pass the WHERE clause as a parameter, a lot of compiler locks.
Dunno why they implemented stored procs if they can't use it properly.
To make things worse, my company bought this product with it's source
before anyone evaluated it because this people took it to Microsoft for
their stamp of approval, and then claim it comforms to MS DNS fs
standards. Makes me sick...
Thanks for the input anyway, seems a rewrite is the only option...