views:

185

answers:

2

Hello, I am working on making an application run on both Postgres and SQL Server.

in PostgreSQL you can do something like

lock mytable exclusive;

which would keep the entire table from being written to(insert/updated). I need the entire table to be locked while certain things are updated(and RIDs can not be changed or else it'll screw it up)

I am not seeing any simple way to force Sql Server to do this though. The only things I'm seeing are for one query and are only "hints" which may or may not be followed. How can I lock a table so that it is read-only in SQL Server for the duration of a transaction?

A: 

On SQL Server you can set the Transaction Isolation Level to be read commited or serializable for the relevant connection. That should ensure the locking you need.

Oded
PotgreSQL will do that as well, of course, but there are cases where applications have to, or just prefer, to use explicit locking.
Magnus Hagander
+3  A: 

A locked table is not read-only. Is locked.

SQL Server does not allow explicit locking of engine primitives (tables, partitions, pages, rows, metadata etc). It only allows you to aquire explicitly application locks via sp_getapplock.

If you want to ensure correctness under concurency conditions, you're going to have to do it the way everyone else does it: via transactions, proper isolation level and correct update order. Many concurency race conditions can be avoided using the OUTPUT clause of UPDATE/DELETE/INSERT.

Ultimately you can place an X lock on a table with a SELECT ... FROM Table WITH (TABLOCKX) WHERE..., but I would call that extremly poor programing flair.

Remus Rusanu
The problem is also attempting to keep our subset of "commonly used" SQL to be compatible with both SQL Server and Postgres.. It's not fun maintaining slightly different SQL queries
Earlz
Cross platform SQL will always have to reside to the least common denominator and that common denominator is seldom of any use for real projects. Frankly, I don't know of any successful project that managed to get away with having one single set of SQL queries cross multiple platforms. Anything besides the trivial single key selecte/insert/update/delete. Even join queries require vendor specific syntax unfortunately, at least if they do anything interesting.
Remus Rusanu
You'd be surprised at how few troubles we are having doing this... Our application is pretty complex too.. It's just knowing how to write SQL code to write on both of them.. we do not have very many places where we must have 2 versions of a query.. Course were also not going crazy with stored procs either though.
Earlz
I'm glad you're doing better than most. But I have to ask, if you have the skillset to pull that off, why do you try to do something like lock an entire table exclusively? Is the processing so complicated, or is a place where you realy don't care about scalability?
Remus Rusanu
The table would only be locked in an administration mode which is to rarely be used(like less often than once every week) and the transaction/query is not complex or anything.... It's just a shame there isn't a `select scope_identity()` in PostgreSQL or else it'd be ok to use that..
Earlz