Is it possible to implement control access on the line level usning standard
features?
I had to implement several tables User, groupe, article ..., map users to
groups and articles as well as some Sps in order that users or group of users
acces articles they are allowed to diplay.
I would highly appreciate any help
Thanks
"SalamElias" <eliassal@.online.nospam> wrote in message
news:644C3FAF-8D72-4EF4-847F-82E96B13ADD8@.microsoft.com...
> Is it possible to implement control access on the line level usning
> standard
> features?
> I had to implement several tables User, groupe, article ..., map users to
> groups and articles as well as some Sps in order that users or group of
> users
> acces articles they are allowed to diplay.
> I would highly appreciate any help
> Thanks
>
Not sure what you mean by "line level". If you mean on a per-row level,
then yes it is.
Especially if you use stored procs.
I'd keep a table of users and values. Each row would have a corresponding
value.
Do all DML work through a stored proc. So if you want a user to view data,
the stored proc would look at their credentials and as part of the WHERE
clause would select only rows that meet that set of credentials (plus any
others required for that specific query.)
It's also possible to do this via views if you want.
Greg Moore
SQL Server DBA Consulting
sql (at) greenms.com http://www.greenms.com
|||"SalamElias" <eliassal@.online.nospam> wrote in message
news:644C3FAF-8D72-4EF4-847F-82E96B13ADD8@.microsoft.com...
> Is it possible to implement control access on the line level usning
> standard
> features?
> I had to implement several tables User, groupe, article ..., map users to
> groups and articles as well as some Sps in order that users or group of
> users
> acces articles they are allowed to diplay.
> I would highly appreciate any help
> Thanks
>
I think your question is about row-level security. Use stored procedures and
views to limit the rows that individual users can access.
David Portas, SQL Server MVP
Whenever possible please post enough code to reproduce your problem.
Including CREATE TABLE and INSERT statements usually helps.
State what version of SQL Server you are using and specify the content
of any error messages.
SQL Server Books Online:
http://msdn2.microsoft.com/library/ms130214(en-US,SQL.90).aspx
Showing posts with label article. Show all posts
Showing posts with label article. Show all posts
Sunday, March 25, 2012
Access controlon line level
Is it possible to implement control access on the line level usning standard
features?
I had to implement several tables User, groupe, article ..., map users to
groups and articles as well as some Sps in order that users or group of users
acces articles they are allowed to diplay.
I would highly appreciate any help
Thanks"SalamElias" <eliassal@.online.nospam> wrote in message
news:644C3FAF-8D72-4EF4-847F-82E96B13ADD8@.microsoft.com...
> Is it possible to implement control access on the line level usning
> standard
> features?
> I had to implement several tables User, groupe, article ..., map users to
> groups and articles as well as some Sps in order that users or group of
> users
> acces articles they are allowed to diplay.
> I would highly appreciate any help
> Thanks
>
Not sure what you mean by "line level". If you mean on a per-row level,
then yes it is.
Especially if you use stored procs.
I'd keep a table of users and values. Each row would have a corresponding
value.
Do all DML work through a stored proc. So if you want a user to view data,
the stored proc would look at their credentials and as part of the WHERE
clause would select only rows that meet that set of credentials (plus any
others required for that specific query.)
It's also possible to do this via views if you want.
Greg Moore
SQL Server DBA Consulting
sql (at) greenms.com http://www.greenms.com|||"SalamElias" <eliassal@.online.nospam> wrote in message
news:644C3FAF-8D72-4EF4-847F-82E96B13ADD8@.microsoft.com...
> Is it possible to implement control access on the line level usning
> standard
> features?
> I had to implement several tables User, groupe, article ..., map users to
> groups and articles as well as some Sps in order that users or group of
> users
> acces articles they are allowed to diplay.
> I would highly appreciate any help
> Thanks
>
I think your question is about row-level security. Use stored procedures and
views to limit the rows that individual users can access.
--
David Portas, SQL Server MVP
Whenever possible please post enough code to reproduce your problem.
Including CREATE TABLE and INSERT statements usually helps.
State what version of SQL Server you are using and specify the content
of any error messages.
SQL Server Books Online:
http://msdn2.microsoft.com/library/ms130214(en-US,SQL.90).aspx
--
features?
I had to implement several tables User, groupe, article ..., map users to
groups and articles as well as some Sps in order that users or group of users
acces articles they are allowed to diplay.
I would highly appreciate any help
Thanks"SalamElias" <eliassal@.online.nospam> wrote in message
news:644C3FAF-8D72-4EF4-847F-82E96B13ADD8@.microsoft.com...
> Is it possible to implement control access on the line level usning
> standard
> features?
> I had to implement several tables User, groupe, article ..., map users to
> groups and articles as well as some Sps in order that users or group of
> users
> acces articles they are allowed to diplay.
> I would highly appreciate any help
> Thanks
>
Not sure what you mean by "line level". If you mean on a per-row level,
then yes it is.
Especially if you use stored procs.
I'd keep a table of users and values. Each row would have a corresponding
value.
Do all DML work through a stored proc. So if you want a user to view data,
the stored proc would look at their credentials and as part of the WHERE
clause would select only rows that meet that set of credentials (plus any
others required for that specific query.)
It's also possible to do this via views if you want.
Greg Moore
SQL Server DBA Consulting
sql (at) greenms.com http://www.greenms.com|||"SalamElias" <eliassal@.online.nospam> wrote in message
news:644C3FAF-8D72-4EF4-847F-82E96B13ADD8@.microsoft.com...
> Is it possible to implement control access on the line level usning
> standard
> features?
> I had to implement several tables User, groupe, article ..., map users to
> groups and articles as well as some Sps in order that users or group of
> users
> acces articles they are allowed to diplay.
> I would highly appreciate any help
> Thanks
>
I think your question is about row-level security. Use stored procedures and
views to limit the rows that individual users can access.
--
David Portas, SQL Server MVP
Whenever possible please post enough code to reproduce your problem.
Including CREATE TABLE and INSERT statements usually helps.
State what version of SQL Server you are using and specify the content
of any error messages.
SQL Server Books Online:
http://msdn2.microsoft.com/library/ms130214(en-US,SQL.90).aspx
--
Access controlon line level
Is it possible to implement control access on the line level usning standard
features?
I had to implement several tables User, groupe, article ..., map users to
groups and articles as well as some Sps in order that users or group of user
s
acces articles they are allowed to diplay.
I would highly appreciate any help
Thanks"SalamElias" <eliassal@.online.nospam> wrote in message
news:644C3FAF-8D72-4EF4-847F-82E96B13ADD8@.microsoft.com...
> Is it possible to implement control access on the line level usning
> standard
> features?
> I had to implement several tables User, groupe, article ..., map users to
> groups and articles as well as some Sps in order that users or group of
> users
> acces articles they are allowed to diplay.
> I would highly appreciate any help
> Thanks
>
Not sure what you mean by "line level". If you mean on a per-row level,
then yes it is.
Especially if you use stored procs.
I'd keep a table of users and values. Each row would have a corresponding
value.
Do all DML work through a stored proc. So if you want a user to view data,
the stored proc would look at their credentials and as part of the WHERE
clause would select only rows that meet that set of credentials (plus any
others required for that specific query.)
It's also possible to do this via views if you want.
Greg Moore
SQL Server DBA Consulting
sql (at) greenms.com http://www.greenms.com|||"SalamElias" <eliassal@.online.nospam> wrote in message
news:644C3FAF-8D72-4EF4-847F-82E96B13ADD8@.microsoft.com...
> Is it possible to implement control access on the line level usning
> standard
> features?
> I had to implement several tables User, groupe, article ..., map users to
> groups and articles as well as some Sps in order that users or group of
> users
> acces articles they are allowed to diplay.
> I would highly appreciate any help
> Thanks
>
I think your question is about row-level security. Use stored procedures and
views to limit the rows that individual users can access.
David Portas, SQL Server MVP
Whenever possible please post enough code to reproduce your problem.
Including CREATE TABLE and INSERT statements usually helps.
State what version of SQL Server you are using and specify the content
of any error messages.
SQL Server Books Online:
http://msdn2.microsoft.com/library/ms130214(en-US,SQL.90).aspx
--
features?
I had to implement several tables User, groupe, article ..., map users to
groups and articles as well as some Sps in order that users or group of user
s
acces articles they are allowed to diplay.
I would highly appreciate any help
Thanks"SalamElias" <eliassal@.online.nospam> wrote in message
news:644C3FAF-8D72-4EF4-847F-82E96B13ADD8@.microsoft.com...
> Is it possible to implement control access on the line level usning
> standard
> features?
> I had to implement several tables User, groupe, article ..., map users to
> groups and articles as well as some Sps in order that users or group of
> users
> acces articles they are allowed to diplay.
> I would highly appreciate any help
> Thanks
>
Not sure what you mean by "line level". If you mean on a per-row level,
then yes it is.
Especially if you use stored procs.
I'd keep a table of users and values. Each row would have a corresponding
value.
Do all DML work through a stored proc. So if you want a user to view data,
the stored proc would look at their credentials and as part of the WHERE
clause would select only rows that meet that set of credentials (plus any
others required for that specific query.)
It's also possible to do this via views if you want.
Greg Moore
SQL Server DBA Consulting
sql (at) greenms.com http://www.greenms.com|||"SalamElias" <eliassal@.online.nospam> wrote in message
news:644C3FAF-8D72-4EF4-847F-82E96B13ADD8@.microsoft.com...
> Is it possible to implement control access on the line level usning
> standard
> features?
> I had to implement several tables User, groupe, article ..., map users to
> groups and articles as well as some Sps in order that users or group of
> users
> acces articles they are allowed to diplay.
> I would highly appreciate any help
> Thanks
>
I think your question is about row-level security. Use stored procedures and
views to limit the rows that individual users can access.
David Portas, SQL Server MVP
Whenever possible please post enough code to reproduce your problem.
Including CREATE TABLE and INSERT statements usually helps.
State what version of SQL Server you are using and specify the content
of any error messages.
SQL Server Books Online:
http://msdn2.microsoft.com/library/ms130214(en-US,SQL.90).aspx
--
Access Control and Security?
Are there any books/article/forum posts out there that document the
best practices for SQL Server security?
For example, what account should create the database?
What account should create the schema?
In a given database should there be a login that is solely responsible
for DDL and a seperate account that only does DML and Queries?
What conventions are people using?
I'm kind of clueless about this and trying to figure out where to
start.
-ThxWhat version of SQL Server are you using? Best practices for SQLS 2000
do not necessarily apply to 2005, where there are expanded options not
available in earlier versions. A good starting point is always SQLS
Books Online, supplemented with a good searh engine :)
-mary
On Wed, 22 Aug 2007 05:58:08 -0700, kilik3000@.gmail.com wrote:
>Are there any books/article/forum posts out there that document the
>best practices for SQL Server security?
>For example, what account should create the database?
>What account should create the schema?
>In a given database should there be a login that is solely responsible
>for DDL and a seperate account that only does DML and Queries?
>What conventions are people using?
>I'm kind of clueless about this and trying to figure out where to
>start.
>-Thx|||On Aug 23, 1:45 pm, "Mary Chipman [MSFT]" <mc...@.online.microsoft.com>
wrote:
> What version of SQL Server are you using? Best practices for SQLS 2000
> do not necessarily apply to 2005, where there are expanded options not
> available in earlier versions. A good starting point is always SQLS
> Books Online, supplemented with a good searh engine :)
> -mary
> On Wed, 22 Aug 2007 05:58:08 -0700, kilik3...@.gmail.com wrote:
> >Are there any books/article/forum posts out there that document the
> >best practices for SQL Server security?
> >For example, what account should create the database?
> >What account should create the schema?
> >In a given database should there be a login that is solely responsible
> >for DDL and a seperate account that only does DML and Queries?
> >What conventions are people using?
> >I'm kind of clueless about this and trying to figure out where to
> >start.
> >-Thx
SQL 2005.
-Thx|||That's a tough one. Basic information is in SQLS Books Online
(http://msdn2.microsoft.com/en-us/library/ms161948.aspx) but it
doesn't directly answer your questions, you have to infer the answers.
Also, your security architecture depends on your needs. DDL has gotten
a lot easier with user-schema separation in 2005 once you understand
it. Erland Sommarskog's web site has some good resources - see Giving
Permissions through Stored Procedures
(http://www.sommarskog.se/grantperm.html).
-mary
On Tue, 28 Aug 2007 20:01:27 -0000, kilik3000@.gmail.com wrote:
>On Aug 23, 1:45 pm, "Mary Chipman [MSFT]" <mc...@.online.microsoft.com>
>wrote:
>> What version of SQL Server are you using? Best practices for SQLS 2000
>> do not necessarily apply to 2005, where there are expanded options not
>> available in earlier versions. A good starting point is always SQLS
>> Books Online, supplemented with a good searh engine :)
>> -mary
>> On Wed, 22 Aug 2007 05:58:08 -0700, kilik3...@.gmail.com wrote:
>> >Are there any books/article/forum posts out there that document the
>> >best practices for SQL Server security?
>> >For example, what account should create the database?
>> >What account should create the schema?
>> >In a given database should there be a login that is solely responsible
>> >for DDL and a seperate account that only does DML and Queries?
>> >What conventions are people using?
>> >I'm kind of clueless about this and trying to figure out where to
>> >start.
>> >-Thx
>SQL 2005.
>-Thx
best practices for SQL Server security?
For example, what account should create the database?
What account should create the schema?
In a given database should there be a login that is solely responsible
for DDL and a seperate account that only does DML and Queries?
What conventions are people using?
I'm kind of clueless about this and trying to figure out where to
start.
-ThxWhat version of SQL Server are you using? Best practices for SQLS 2000
do not necessarily apply to 2005, where there are expanded options not
available in earlier versions. A good starting point is always SQLS
Books Online, supplemented with a good searh engine :)
-mary
On Wed, 22 Aug 2007 05:58:08 -0700, kilik3000@.gmail.com wrote:
>Are there any books/article/forum posts out there that document the
>best practices for SQL Server security?
>For example, what account should create the database?
>What account should create the schema?
>In a given database should there be a login that is solely responsible
>for DDL and a seperate account that only does DML and Queries?
>What conventions are people using?
>I'm kind of clueless about this and trying to figure out where to
>start.
>-Thx|||On Aug 23, 1:45 pm, "Mary Chipman [MSFT]" <mc...@.online.microsoft.com>
wrote:
> What version of SQL Server are you using? Best practices for SQLS 2000
> do not necessarily apply to 2005, where there are expanded options not
> available in earlier versions. A good starting point is always SQLS
> Books Online, supplemented with a good searh engine :)
> -mary
> On Wed, 22 Aug 2007 05:58:08 -0700, kilik3...@.gmail.com wrote:
> >Are there any books/article/forum posts out there that document the
> >best practices for SQL Server security?
> >For example, what account should create the database?
> >What account should create the schema?
> >In a given database should there be a login that is solely responsible
> >for DDL and a seperate account that only does DML and Queries?
> >What conventions are people using?
> >I'm kind of clueless about this and trying to figure out where to
> >start.
> >-Thx
SQL 2005.
-Thx|||That's a tough one. Basic information is in SQLS Books Online
(http://msdn2.microsoft.com/en-us/library/ms161948.aspx) but it
doesn't directly answer your questions, you have to infer the answers.
Also, your security architecture depends on your needs. DDL has gotten
a lot easier with user-schema separation in 2005 once you understand
it. Erland Sommarskog's web site has some good resources - see Giving
Permissions through Stored Procedures
(http://www.sommarskog.se/grantperm.html).
-mary
On Tue, 28 Aug 2007 20:01:27 -0000, kilik3000@.gmail.com wrote:
>On Aug 23, 1:45 pm, "Mary Chipman [MSFT]" <mc...@.online.microsoft.com>
>wrote:
>> What version of SQL Server are you using? Best practices for SQLS 2000
>> do not necessarily apply to 2005, where there are expanded options not
>> available in earlier versions. A good starting point is always SQLS
>> Books Online, supplemented with a good searh engine :)
>> -mary
>> On Wed, 22 Aug 2007 05:58:08 -0700, kilik3...@.gmail.com wrote:
>> >Are there any books/article/forum posts out there that document the
>> >best practices for SQL Server security?
>> >For example, what account should create the database?
>> >What account should create the schema?
>> >In a given database should there be a login that is solely responsible
>> >for DDL and a seperate account that only does DML and Queries?
>> >What conventions are people using?
>> >I'm kind of clueless about this and trying to figure out where to
>> >start.
>> >-Thx
>SQL 2005.
>-Thx
Monday, February 13, 2012
ABout identity column in replication
Hi Guys,
I read the microsoft article about how to handle the identity column in
replication. There is sentence: " If you are using transactional replication
with the immediate-updating Subscribers option, do not use the IDENTITY NOT
FOR REPLICATION design." That means I can not use the IDENTITY NOT FOR
REPLICATION option when I want to use transactional replication with the
immediate-updating Subscribers options, is that correct? That also means I
cannot created identity column in subscriber, right? If I do need to create
identity column in the subscriber, how can I work around? Thanks
This isn't correct. If you have immediate updating you don't need NFR as the
transaction is applied on the publisher before the subscriber.
You can use NFR and identity columns on the subscriber, however, but it is
not necessary.
Hilary Cotter
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
"Iter" <Iter@.discussions.microsoft.com> wrote in message
news:43F4ECD0-EDC3-4932-AF29-C2782E66CEDD@.microsoft.com...
> Hi Guys,
> I read the microsoft article about how to handle the identity column in
> replication. There is sentence: " If you are using transactional
> replication
> with the immediate-updating Subscribers option, do not use the IDENTITY
> NOT
> FOR REPLICATION design." That means I can not use the IDENTITY NOT FOR
> REPLICATION option when I want to use transactional replication with the
> immediate-updating Subscribers options, is that correct? That also means I
> cannot created identity column in subscriber, right? If I do need to
> create
> identity column in the subscriber, how can I work around? Thanks
I read the microsoft article about how to handle the identity column in
replication. There is sentence: " If you are using transactional replication
with the immediate-updating Subscribers option, do not use the IDENTITY NOT
FOR REPLICATION design." That means I can not use the IDENTITY NOT FOR
REPLICATION option when I want to use transactional replication with the
immediate-updating Subscribers options, is that correct? That also means I
cannot created identity column in subscriber, right? If I do need to create
identity column in the subscriber, how can I work around? Thanks
This isn't correct. If you have immediate updating you don't need NFR as the
transaction is applied on the publisher before the subscriber.
You can use NFR and identity columns on the subscriber, however, but it is
not necessary.
Hilary Cotter
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
"Iter" <Iter@.discussions.microsoft.com> wrote in message
news:43F4ECD0-EDC3-4932-AF29-C2782E66CEDD@.microsoft.com...
> Hi Guys,
> I read the microsoft article about how to handle the identity column in
> replication. There is sentence: " If you are using transactional
> replication
> with the immediate-updating Subscribers option, do not use the IDENTITY
> NOT
> FOR REPLICATION design." That means I can not use the IDENTITY NOT FOR
> REPLICATION option when I want to use transactional replication with the
> immediate-updating Subscribers options, is that correct? That also means I
> cannot created identity column in subscriber, right? If I do need to
> create
> identity column in the subscriber, how can I work around? Thanks
Subscribe to:
Posts (Atom)