In short, we are sending several statements to the database from one source
(my application). When this application is running nobody else will be
accessing the database.
If I do a table lock isnâ't it still releasing that lock after each statement?
I ask because each update I send to the database will be effecting only one
row at a time so I donâ't think I would get performance gains because I lock
the table for one record update then lock it again etc etc. The manager
itself could most likely do that faster anyway.What do you mean by 'doing a table lock'? Do you mean using a lock hint?
Which hint? What is the statement that is affecting the data?
Have you started an explicit transaction with BEGIN TRAN?
We need to see exactly what you are doing to lock the table to be able to
answer your questions, but in general, it is better to let SQL Server's lock
manager handle all the necessary locking automatically.
Why are you updating only one row at a time? If you are interested in
performance, you might consider figuring out a way to process all the rows
at once. That's what a relational database is good at.
--
HTH
Kalen Delaney, SQL Server MVP
"Sean" <Sean@.discussions.microsoft.com> wrote in message
news:5C5D6009-F702-4100-BCE1-F194E3695DAC@.microsoft.com...
> In short, we are sending several statements to the database from one
> source
> (my application). When this application is running nobody else will be
> accessing the database.
> If I do a table lock isn't it still releasing that lock after each
> statement?
> I ask because each update I send to the database will be effecting only
> one
> row at a time so I don't think I would get performance gains because I
> lock
> the table for one record update then lock it again etc etc. The manager
> itself could most likely do that faster anyway.
>sql
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment