ROWLOCK hint does not seem to have any effect

Hi
Here is the situation.
Many clients simulteneously update the same table, but *never*
the same rows. Each client has its *own* subset of rows.
So there is theoretically no concurrency problem.
Yet we are having locking issues.
We use ROWLOCK hint but it looks like it does not do anything.
Here is my simple test of it.
From one connection, I begin a transaction and update a record in a table
with the ROWLOCK hint.
Then I leave it as is
and
From another connection, I try to update a different record in the same
table also with the ROWLOCK hint.
Second command does not do anything until a transaction in the first
connection is commited.
If it is being locked by row, why is this happenning ?
Thanks
Alex
Hi
If SQL Server has to do a Table or Range Scan to get to data, the 2
operations may step on each other.
Correct indexing, espacially clustered indexes can help a lot.
Post DML and DDL so that we can look at it.
Mike Epprecht, Microsoft SQL Server MVP
Zurich, Switzerland
MVP Program: http://www.microsoft.com/mvp
Blog: http://www.msmvps.com/epprecht/
"Alex" wrote:

> Hi
> Here is the situation.
> Many clients simulteneously update the same table, but *never*
> the same rows. Each client has its *own* subset of rows.
> So there is theoretically no concurrency problem.
> Yet we are having locking issues.
> We use ROWLOCK hint but it looks like it does not do anything.
> Here is my simple test of it.
> From one connection, I begin a transaction and update a record in a table
> with the ROWLOCK hint.
> Then I leave it as is
> and
> From another connection, I try to update a different record in the same
> table also with the ROWLOCK hint.
> Second command does not do anything until a transaction in the first
> connection is commited.
> If it is being locked by row, why is this happenning ?
> Thanks
> Alex
>
>
>
sql

row level security without views

I want to implement row level security in SQL Server 2005 without
implementing views. The desired effect is firing a query on a table
like "select * from <tablename>" should return only rows which are
accessible to the logged in user. Which rows are accessible will be
decided using some data in another table. This table will have user
login name and one or more IDs associated with it. These IDs will be FK
in the table on which we fire select (or update/delete) query. I need
to device a solution such that the select query will return all rows
from the table which contain the ID that is assigned to the logged in
user. Is it possible in SQL Server 2005 without implmenting views on
each table?
Thanks in advance.
Nikhil.Hi
http://www.microsoft.com/technet/pr...5/multisec.mspx
"Nikhil" <nikhilukidwe@.gmail.com> wrote in message
news:1159253428.573628.105420@.d34g2000cwd.googlegroups.com...
>I want to implement row level security in SQL Server 2005 without
> implementing views. The desired effect is firing a query on a table
> like "select * from <tablename>" should return only rows which are
> accessible to the logged in user. Which rows are accessible will be
> decided using some data in another table. This table will have user
> login name and one or more IDs associated with it. These IDs will be FK
> in the table on which we fire select (or update/delete) query. I need
> to device a solution such that the select query will return all rows
> from the table which contain the ID that is assigned to the logged in
> user. Is it possible in SQL Server 2005 without implmenting views on
> each table?
> Thanks in advance.
> Nikhil.
>|||Thanks Uri,
I have already seen this article. This article explains the
"implementation" of row-level security using existing constructs like
tables,views and roles. I wanted to know if SQL Server 2005 has any
built-in support for the row level security and I think it is not
there.
Please correct me if I am wrong.
Nikhil.
Uri Dimant wrote:[vbcol=seagreen]
> Hi
> http://www.microsoft.com/technet/pr...5/multisec.mspx
>
> "Nikhil" <nikhilukidwe@.gmail.com> wrote in message
> news:1159253428.573628.105420@.d34g2000cwd.googlegroups.com...|||> tables,views and roles. I wanted to know if SQL Server 2005 has any
> built-in support for the row level security and I think it is not
> there.
> Please correct me if I am wrong.
Not , that I 'm aware
"Nikhil" <nikhilukidwe@.gmail.com> wrote in message
news:1159335152.141657.291800@.m7g2000cwm.googlegroups.com...
> Thanks Uri,
> I have already seen this article. This article explains the
> "implementation" of row-level security using existing constructs like
> tables,views and roles. I wanted to know if SQL Server 2005 has any
> built-in support for the row level security and I think it is not
> there.
> Please correct me if I am wrong.
> Nikhil.
> Uri Dimant wrote:
>

Row Height Affected When Adding New Row

I am attempting to add a new row to a table. Every time I add the new row (doens't matter where) it has an effect on the height of the other rows in the table when displayed on screen (makes them taller). However the rows retain the required height when printed. I haven't any idea what might be causing this behaviour. The only explanation I can think of is that this is a bug.

I know it's a bit obscure but has anyone else come across this or have any idea what might be causing it?

After much trial and error I've discovered that for my particular reports that if I add a new row (to the Header say) and don't set the CanGrow property for the textboxes on that row to false then the rows in the detail expand (even though CanGrow is set to False). This is a bug in my book.

The reason for adding the new row is to insert a sub-report into the header of the table. The sub-report does not have a CanGrow property. Therefore I can't add it without affecting the other rows on the report. This is pretty annoying.

Mark