Controlling Data Modification at row level

Hi,
I'm writing an application that involves data that has a set of users
that are allowed to perform certain operations on it.
i.e. Only the row owner can modify a row, but there is a set of users
who can view it.

At the moment, I've started to implement this by calling a UDF at the
beginning of each stored procedure that validates that the user is
allowed to call the procedure on that particular row (trusting a higher
teir to verify the user), and throws an error if they are not.

I don't particularly like this solution, as I need a UDF for each
procedure, and will have to re-write the udf's if the access rules
change (which they might).

Can anyone suggest a method of implementing a more generic row
permissions system?

Cheers,
Ben"Bomza" <benelvin@.hotmail.com> wrote in message
news:1106584255.027100.151190@.c13g2000cwb.googlegr oups.com...
> Hi,
> I'm writing an application that involves data that has a set of users
> that are allowed to perform certain operations on it.
> i.e. Only the row owner can modify a row, but there is a set of users
> who can view it.
> At the moment, I've started to implement this by calling a UDF at the
> beginning of each stored procedure that validates that the user is
> allowed to call the procedure on that particular row (trusting a higher
> teir to verify the user), and throws an error if they are not.
> I don't particularly like this solution, as I need a UDF for each
> procedure, and will have to re-write the udf's if the access rules
> change (which they might).
> Can anyone suggest a method of implementing a more generic row
> permissions system?
> Cheers,
> Ben

Unfortunately there's no built-in or generic solution, so you need to
implement something yourself. Here's an alternative view-based approach,
which might give you some more ideas:

http://vyaskn.tripod.com/row_level_...r_databases.htm

Simon|||Views are of good use when situations like this.
In your table create a field called userID and assing the userID to
each row that has modifying permission. Create a view like this for
egsample....

Create view <name>
AS
Select col1, col2, col3
from <table>
where userid = sUser_sName().

Then update the table by updating this view so that only those records
that are visible to that user can update these records on the
destination table....!

Also create another view where userID<> sUser_sName() and grant only
view permission to the users... So they cant update the table thru this
view...!

This is just a guess. I have not tried it myself. So feel free to
comment on this..!!

Good luck..!|||They're both interesting ideas, and are probably a fair bit faster than
the way I came up with. I like the idea of being able to throw an
error when a client does something illegal rather than just doing
nothing and as I'm using ADO.NET, my "authorising" UDF method provides
a neat way of doing it. At worst the UDF does an EXISTS on a SELECT
statement, so its not a totally horrible method.

It must be a fairly common problem, so when I'm finished I might turn
it into a generic framework where you can grant and evoke various
permissions to any users on any rows, but at the moment I've just got
to get this working :) I think its all been addressed in SQL 2005
anyway...|||Bomza (benelvin@.hotmail.com) writes:
> It must be a fairly common problem, so when I'm finished I might turn
> it into a generic framework where you can grant and evoke various
> permissions to any users on any rows, but at the moment I've just got
> to get this working :) I think its all been addressed in SQL 2005
> anyway...

Not really. There is no particular support in SQL 2005 for row-level
security either.

--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techin.../2000/books.asp|||"Bomza" <benelvin@.hotmail.com> wrote in message
news:1106598807.774687.263530@.z14g2000cwz.googlegr oups.com...
<<>>
> It must be a fairly common problem, so when I'm finished I might turn
> it into a generic framework where you can grant and evoke various
> permissions to any users on any rows, but at the moment I've just got
> to get this working :) I think its all been addressed in SQL 2005
> anyway...

I usually address this in the front end design.
Something like.
All users see everything in one screen is read only.
There are links butons or whatever take them to another screen to do
updates.
The update screen is only available to supervisors or when you pick data is
maintained by your team.

This does of course rely on users not trying to break the system by
connecting up using odbc or something.
But.
I suspect others use the same sort of approach and that's why there aren't
loads of solutions available.

--
Regards,
Andy O'Neill

Contains(@v1, @v2) Is this legal?

I am attempting to perform a contains of one variable string in another.
here is a simple example of what I am attempting to do, this should return
true, but I am not sure if this is a limitation of sql server, that it will
now allow a contains on two datatypes. Any ideas?
declare @.t1 varchar(30),
@.t2 varchar(30)
set @.t1 = 'Te'
set @.t2 = 'Test'
if (Contains(@.t2, @.t1))
print 'true'
else
print 'false'
Thanks.Hi, kapsolas
You probably want to use the CHARINDEX function:
IF CHARINDEX(@.t1,@.t2)<>0 ...
For more informations, see:
http://msdn2.microsoft.com/en-us/library/ms186323.aspx
Razvan|||"kapsolas" <kapsolas@.discussions.microsoft.com> wrote in message
news:F05CD410-BFDD-4627-8308-5B774805A2AA@.microsoft.com...
>I am attempting to perform a contains of one variable string in another.
> here is a simple example of what I am attempting to do, this should return
> true, but I am not sure if this is a limitation of sql server, that it
> will
> now allow a contains on two datatypes. Any ideas?
> declare @.t1 varchar(30),
> @.t2 varchar(30)
> set @.t1 = 'Te'
> set @.t2 = 'Test'
> if (Contains(@.t2, @.t1))
> print 'true'
> else
> print 'false'
> Thanks.
Another solution:
declare @.t1 varchar(30),
@.t2 varchar(30)
set @.t1 = 'Te'
set @.t2 = 'Test'
if @.t2 like '%' + @.t1 + '%'
print 'true'
else
print 'false'|||Raymond,
that is the solution I have implemented. Using the LIKE. I wanted to clean
it up a bit to make it more readable by using the Contains.
I'll play with the char index as recommended in the other post as well.
"Raymond D'Anjou" wrote:

> "kapsolas" <kapsolas@.discussions.microsoft.com> wrote in message
> news:F05CD410-BFDD-4627-8308-5B774805A2AA@.microsoft.com...
> Another solution:
> declare @.t1 varchar(30),
> @.t2 varchar(30)
> set @.t1 = 'Te'
> set @.t2 = 'Test'
> if @.t2 like '%' + @.t1 + '%'
> print 'true'
> else
> print 'false'
>
>|||"kapsolas" <kapsolas@.discussions.microsoft.com> wrote in message
news:F5F39D6F-0723-4EE5-B032-E425A6942D33@.microsoft.com...
> Raymond,
> that is the solution I have implemented. Using the LIKE. I wanted to clean
> it up a bit to make it more readable by using the Contains.
> I'll play with the char index as recommended in the other post as well.
I have no experience with Contains.
This is the information I got in BOL:
...You can use the CONTAINS predicate to search a database for a specific
phrase. Of course, such a query can be written using the LIKE predicate.
However, many forms of CONTAINS provide far more text query capabilities
than can be obtained with LIKE. Additionally, unlike using the LIKE
predicate, a CONTAINS search is always case insensitive...
So, if you are not using the extra "query capabilities" of Contains, I
suggest you use one of the other solutions that you got for this post.
Of course, the best would be to test all solutions with your database and
data to find the one that performs the best.|||Thanks for that piece Raymond.
For now I'll use the LIKE and as soon as I have a bit more time i'll
investigate the contains a bit more.
Thanks for your help
"Raymond D'Anjou" wrote:

> "kapsolas" <kapsolas@.discussions.microsoft.com> wrote in message
> news:F5F39D6F-0723-4EE5-B032-E425A6942D33@.microsoft.com...
> I have no experience with Contains.
> This is the information I got in BOL:
> ...You can use the CONTAINS predicate to search a database for a specific
> phrase. Of course, such a query can be written using the LIKE predicate.
> However, many forms of CONTAINS provide far more text query capabilities
> than can be obtained with LIKE. Additionally, unlike using the LIKE
> predicate, a CONTAINS search is always case insensitive...
> So, if you are not using the extra "query capabilities" of Contains, I
> suggest you use one of the other solutions that you got for this post.
> Of course, the best would be to test all solutions with your database and
> data to find the one that performs the best.
>
>|||> that is the solution I have implemented. Using the LIKE. I wanted to clean
> it up a bit to make it more readable by using the Contains.
I don't know why you think that's cleaner or more readable. I guess for
someone who has never used T-SQL and only used FTS, but I think that'd be a
pretty rare bird.
A

CONTAINS in SQL Server

Hi,
I have a question about MS SQL Server 2005:
I have a table in the database that contains 70 fields. I must perform
full-text search in about 60 fields. I use for that the full-text
searching "CONTAINS" like that:
SELECT ProductName
FROM Products
WHERE CONTAINS(ProductName, '"laugh*" NEAR lager')
My question is: for the 60 fields in the table that I want to do
full-text search for the same expression, may I write a query like
that:
Select f1, ..., fm
From table
Where CONTAINS(f1, expr) and CONTAINS(f2, exp) ... and
CONTAINS(f60,expr)
Or there is a more compact way to write this query.
Thank you very much for your answer,
Regard,
Djamila.that's one way. If you don't care which column the hit is found in you could
do this.
Select f1, ..., fm From table
Where CONTAINS(*, expr)
Hilary Cotter
Director of Text Mining and Database Strategy
RelevantNOISE.Com - Dedicated to mining blogs for business intelligence.
This posting is my own and doesn't necessarily represent RelevantNoise's
positions, strategies or opinions.
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
<djamilabouzid@.gmail.com> wrote in message
news:1159835993.016620.306290@.h48g2000cwc.googlegroups.com...
> Hi,
> I have a question about MS SQL Server 2005:
> I have a table in the database that contains 70 fields. I must perform
> full-text search in about 60 fields. I use for that the full-text
> searching "CONTAINS" like that:
> SELECT ProductName
> FROM Products
> WHERE CONTAINS(ProductName, '"laugh*" NEAR lager')
> My question is: for the 60 fields in the table that I want to do
> full-text search for the same expression, may I write a query like
> that:
> Select f1, ..., fm
> From table
> Where CONTAINS(f1, expr) and CONTAINS(f2, exp) ... and
> CONTAINS(f60,expr)
> Or there is a more compact way to write this query.
> Thank you very much for your answer,
> Regard,
> Djamila.
>

CONTAINS

Hi,
I would like to perform a search which returns records that are like a
string variable I pass into the query - so to catch spelling mistakes etc.
Eg. string = Commmercial would return Commercial from my reference table.
Could someone recommend the best way to do this. I am using VB.NET and
ADO.NET to execute my sql statement.
Should I use a WHERE CONTAINS clause. If so how does one enable full-text
indexed? I always get this error even using Northwind. "Cannot use a
CONTAINS or FREETEXT predicate on table 'mytable' because it is not
full-text indexed."Have a look at the SOUNDEX command, it may help.
Peter
"11Oppidan" wrote:

> Hi,
> I would like to perform a search which returns records that are like a
> string variable I pass into the query - so to catch spelling mistakes etc.
> Eg. string = Commmercial would return Commercial from my reference table.
> Could someone recommend the best way to do this. I am using VB.NET and
> ADO.NET to execute my sql statement.
> Should I use a WHERE CONTAINS clause. If so how does one enable full-text
> indexed? I always get this error even using Northwind. "Cannot use a
> CONTAINS or FREETEXT predicate on table 'mytable' because it is not
> full-text indexed."
>
>|||Thanks Peter - thats great!
"Peter 'Not Peter The Spate' Nolan"
<PeterNotPeterTheSpateNolan@.discussions.microsoft.com> wrote in message
news:23F80AF0-26B9-48F4-9501-290999F78877@.microsoft.com...
> Have a look at the SOUNDEX command, it may help.
> Peter
> "11Oppidan" wrote:
>

Constant scan when querying an identity field over linked server

When I perform a simple query over a linked server that is looking for a
specific identity value, SQL Server performs a constant scan instead of a
remote query. Running the same query locally gives expected results. Also,
forcing a data type conversion in the criteria gives expected results.
Example problematic query:
Select MyID
From Server2.MyDB.dbo.MyTable
Where MyID = 1
0 records are returned, but a record with a MyID = 1 does exist.
The following works as expected:
Select MyID
From Server2.MyDB.dbo.MyTable
Where MyID Like 1
Select MyID
From Server2.MyDB.dbo.MyTable
Where Cast(MyID As varchar) = 1
Any ideas as to why this is happening and how to permanently prevent it?
Thanks!!
In case i wasn't clear on this point, it only happens when the criteria is
checking an identity field. Another other field works as expected.
"Robert Davis" wrote:

> When I perform a simple query over a linked server that is looking for a
> specific identity value, SQL Server performs a constant scan instead of a
> remote query. Running the same query locally gives expected results. Also,
> forcing a data type conversion in the criteria gives expected results.
> Example problematic query:
> Select MyID
> From Server2.MyDB.dbo.MyTable
> Where MyID = 1
> 0 records are returned, but a record with a MyID = 1 does exist.
> The following works as expected:
> Select MyID
> From Server2.MyDB.dbo.MyTable
> Where MyID Like 1
> Select MyID
> From Server2.MyDB.dbo.MyTable
> Where Cast(MyID As varchar) = 1
> Any ideas as to why this is happening and how to permanently prevent it?
> Thanks!!
>
|||Look at the provider properties for the OLE DB provider you are using for
this linked server; they are sensitive to this attributes and they are
global, meaning they will affect all linked servers and remote queries using
this provider.
Sincerely,
Anthony Thomas

"Robert Davis" <RobertDavis@.discussions.microsoft.com> wrote in message
news:4B3A73A3-D24B-479B-9799-ADBC9054BAAB@.microsoft.com...
In case i wasn't clear on this point, it only happens when the criteria is
checking an identity field. Another other field works as expected.
"Robert Davis" wrote:

> When I perform a simple query over a linked server that is looking for a
> specific identity value, SQL Server performs a constant scan instead of a
> remote query. Running the same query locally gives expected results. Also,
> forcing a data type conversion in the criteria gives expected results.
> Example problematic query:
> Select MyID
> From Server2.MyDB.dbo.MyTable
> Where MyID = 1
> 0 records are returned, but a record with a MyID = 1 does exist.
> The following works as expected:
> Select MyID
> From Server2.MyDB.dbo.MyTable
> Where MyID Like 1
> Select MyID
> From Server2.MyDB.dbo.MyTable
> Where Cast(MyID As varchar) = 1
> Any ideas as to why this is happening and how to permanently prevent it?
> Thanks!!
>
|||Robert .. or anyone
Did you mange to resolve this issue and if so what was the solution?
Thanks
Chris Longstaff
choppertoo
Posted via http://www.webservertalk.com
View this thread: http://www.webservertalk.com/message555779.html

Constant scan when querying an identity field over linked server

When I perform a simple query over a linked server that is looking for a
specific identity value, SQL Server performs a constant scan instead of a
remote query. Running the same query locally gives expected results. Also,
forcing a data type conversion in the criteria gives expected results.
Example problematic query:
Select MyID
From Server2.MyDB.dbo.MyTable
Where MyID = 1
0 records are returned, but a record with a MyID = 1 does exist.
The following works as expected:
Select MyID
From Server2.MyDB.dbo.MyTable
Where MyID Like 1
Select MyID
From Server2.MyDB.dbo.MyTable
Where Cast(MyID As varchar) = 1
Any ideas as to why this is happening and how to permanently prevent it?
Thanks!!In case i wasn't clear on this point, it only happens when the criteria is
checking an identity field. Another other field works as expected.
"Robert Davis" wrote:
> When I perform a simple query over a linked server that is looking for a
> specific identity value, SQL Server performs a constant scan instead of a
> remote query. Running the same query locally gives expected results. Also,
> forcing a data type conversion in the criteria gives expected results.
> Example problematic query:
> Select MyID
> From Server2.MyDB.dbo.MyTable
> Where MyID = 1
> 0 records are returned, but a record with a MyID = 1 does exist.
> The following works as expected:
> Select MyID
> From Server2.MyDB.dbo.MyTable
> Where MyID Like 1
> Select MyID
> From Server2.MyDB.dbo.MyTable
> Where Cast(MyID As varchar) = 1
> Any ideas as to why this is happening and how to permanently prevent it?
> Thanks!!
>|||Look at the provider properties for the OLE DB provider you are using for
this linked server; they are sensitive to this attributes and they are
global, meaning they will affect all linked servers and remote queries using
this provider.
Sincerely,
Anthony Thomas
"Robert Davis" <RobertDavis@.discussions.microsoft.com> wrote in message
news:4B3A73A3-D24B-479B-9799-ADBC9054BAAB@.microsoft.com...
In case i wasn't clear on this point, it only happens when the criteria is
checking an identity field. Another other field works as expected.
"Robert Davis" wrote:
> When I perform a simple query over a linked server that is looking for a
> specific identity value, SQL Server performs a constant scan instead of a
> remote query. Running the same query locally gives expected results. Also,
> forcing a data type conversion in the criteria gives expected results.
> Example problematic query:
> Select MyID
> From Server2.MyDB.dbo.MyTable
> Where MyID = 1
> 0 records are returned, but a record with a MyID = 1 does exist.
> The following works as expected:
> Select MyID
> From Server2.MyDB.dbo.MyTable
> Where MyID Like 1
> Select MyID
> From Server2.MyDB.dbo.MyTable
> Where Cast(MyID As varchar) = 1
> Any ideas as to why this is happening and how to permanently prevent it?
> Thanks!!
>|||Robert .. or anyone
Did you mange to resolve this issue and if so what was the solution?
Thanks
Chris Longstaf
-
chopperto
----
Posted via http://www.webservertalk.co
----
View this thread: http://www.webservertalk.com/message555779.htm

Constant scan when querying an identity field over linked server

When I perform a simple query over a linked server that is looking for a
specific identity value, SQL Server performs a constant scan instead of a
remote query. Running the same query locally gives expected results. Also,
forcing a data type conversion in the criteria gives expected results.
Example problematic query:
Select MyID
From Server2.MyDB.dbo.MyTable
Where MyID = 1
0 records are returned, but a record with a MyID = 1 does exist.
The following works as expected:
Select MyID
From Server2.MyDB.dbo.MyTable
Where MyID Like 1
Select MyID
From Server2.MyDB.dbo.MyTable
Where Cast(MyID As varchar) = 1
Any ideas as to why this is happening and how to permanently prevent it?
Thanks!!In case i wasn't clear on this point, it only happens when the criteria is
checking an identity field. Another other field works as expected.
"Robert Davis" wrote:

> When I perform a simple query over a linked server that is looking for a
> specific identity value, SQL Server performs a constant scan instead of a
> remote query. Running the same query locally gives expected results. Also,
> forcing a data type conversion in the criteria gives expected results.
> Example problematic query:
> Select MyID
> From Server2.MyDB.dbo.MyTable
> Where MyID = 1
> 0 records are returned, but a record with a MyID = 1 does exist.
> The following works as expected:
> Select MyID
> From Server2.MyDB.dbo.MyTable
> Where MyID Like 1
> Select MyID
> From Server2.MyDB.dbo.MyTable
> Where Cast(MyID As varchar) = 1
> Any ideas as to why this is happening and how to permanently prevent it?
> Thanks!!
>|||Look at the provider properties for the OLE DB provider you are using for
this linked server; they are sensitive to this attributes and they are
global, meaning they will affect all linked servers and remote queries using
this provider.
Sincerely,
Anthony Thomas
"Robert Davis" <RobertDavis@.discussions.microsoft.com> wrote in message
news:4B3A73A3-D24B-479B-9799-ADBC9054BAAB@.microsoft.com...
In case i wasn't clear on this point, it only happens when the criteria is
checking an identity field. Another other field works as expected.
"Robert Davis" wrote:

> When I perform a simple query over a linked server that is looking for a
> specific identity value, SQL Server performs a constant scan instead of a
> remote query. Running the same query locally gives expected results. Also,
> forcing a data type conversion in the criteria gives expected results.
> Example problematic query:
> Select MyID
> From Server2.MyDB.dbo.MyTable
> Where MyID = 1
> 0 records are returned, but a record with a MyID = 1 does exist.
> The following works as expected:
> Select MyID
> From Server2.MyDB.dbo.MyTable
> Where MyID Like 1
> Select MyID
> From Server2.MyDB.dbo.MyTable
> Where Cast(MyID As varchar) = 1
> Any ideas as to why this is happening and how to permanently prevent it?
> Thanks!!
>|||Robert .. or anyone
Did you mange to resolve this issue and if so what was the solution?
Thanks
Chris Longstaff