Friday, March 30, 2012
Pervasive SQL in same box as MSSQL 2000 ?
would there be any problems setting both up in the same box ?
It works. Still have a few of those in production environment. Hope you are
not using Pervasive for new stuff:-) Bad enough to have legacy crap depend
on it. We are phasing out all Pervasive stuff (and SQL 2000 for that matter)
hope it helps
"Dennis" <Dennis@.discussions.microsoft.com> wrote in message
news:F019D688-692A-4F5E-9273-425E0D671C86@.microsoft.com...
> Has anyone installed pervasive SQL in the same box as MSSQL 2000 ?
> would there be any problems setting both up in the same box ?
Pervasive SQL in same box as MSSQL 2000 ?
would there be any problems setting both up in the same box ?It works. Still have a few of those in production environment. Hope you are
not using Pervasive for new stuff:-) Bad enough to have legacy crap depend
on it. We are phasing out all Pervasive stuff (and SQL 2000 for that matter)
hope it helps
"Dennis" <Dennis@.discussions.microsoft.com> wrote in message
news:F019D688-692A-4F5E-9273-425E0D671C86@.microsoft.com...
> Has anyone installed pervasive SQL in the same box as MSSQL 2000 ?
> would there be any problems setting both up in the same box ?sql
Wednesday, March 21, 2012
permissions problem
objects. Here's the situation... I have one database (Central) that I want
to allow inserts to a table (Queue) on via a stored procedure. That stored
procedure I am storing in the master database so that any of the other
databases I have running can execute it.
I am doing the insert in the procedure by referencing "INSERT INTO
Central.dbo.Queue..." That procedure is set to allow EXEC permissions by
the guest and public roles.
I have logins from the other databases 'Permit in Database Role' set to
public for the Queue table. The error I am getting is "INSERT permission
denied on object 'Queue', database 'Central', owner 'dbo'.
What am I missing'> What am I missing'
If your stored procedure is owned by 'dbo', then your Central database needs
to also be owned by 'sa' so that the ownership chain is unbroken. Also, if
you are running SQL 2000 SP3+, you'll need to enable cross-database chaining
('db chaining' database option) un the Central database.
Note that you should enable cross-database chaining in an sa-owned database
when only sy
database.
Hope this helps.
Dan Guzman
SQL Server MVP
"Random" <cipherlad@.hotmail.com> wrote in message
news:u2otNyjOFHA.244@.TK2MSFTNGP12.phx.gbl...
>I have what I'm sure is a simple problem with setting permissions on some
>objects. Here's the situation... I have one database (Central) that I want
>to allow inserts to a table (Queue) on via a stored procedure. That stored
>procedure I am storing in the master database so that any of the other
>databases I have running can execute it.
> I am doing the insert in the procedure by referencing "INSERT INTO
> Central.dbo.Queue..." That procedure is set to allow EXEC permissions by
> the guest and public roles.
> I have logins from the other databases 'Permit in Database Role' set to
> public for the Queue table. The error I am getting is "INSERT permission
> denied on object 'Queue', database 'Central', owner 'dbo'.
> What am I missing'
>|||Thank you for replying. The owner on the Central database is 'sa'.
Where is the option for 'db chaining' set? I can't locate it in books
online.
I have also ensured that only sy
in the database.
"Dan Guzman" <guzmanda@.nospam-online.sbcglobal.net> wrote in message
news:ecJw5QkOFHA.2708@.tk2msftngp13.phx.gbl...
> If your stored procedure is owned by 'dbo', then your Central database
> needs to also be owned by 'sa' so that the ownership chain is unbroken.
> Also, if you are running SQL 2000 SP3+, you'll need to enable
> cross-database chaining ('db chaining' database option) un the Central
> database.
> Note that you should enable cross-database chaining in an sa-owned
> database when only sy
> that database.
> --
> Hope this helps.
> Dan Guzman
> SQL Server MVP
> "Random" <cipherlad@.hotmail.com> wrote in message
> news:u2otNyjOFHA.244@.TK2MSFTNGP12.phx.gbl...
>|||The 'db chaining' database option is aka cross-database chaining. One
method to turn it on is with sp_dboption via Query Analyzer:
EXEC sp_dboption 'Central' ,'db chaining', true
Hope this helps.
Dan Guzman
SQL Server MVP
"Random" <cipherlad@.hotmail.com> wrote in message
news:OErPV0rOFHA.3444@.tk2msftngp13.phx.gbl...
> Thank you for replying. The owner on the Central database is 'sa'.
> Where is the option for 'db chaining' set? I can't locate it in books
> online.
> I have also ensured that only sy
> objects in the database.
>
> "Dan Guzman" <guzmanda@.nospam-online.sbcglobal.net> wrote in message
> news:ecJw5QkOFHA.2708@.tk2msftngp13.phx.gbl...
>|||FYI, setting the 'db_chaining' option did the trick. I found the
documentation and read about the security implications, so I've got it
covered now. Thanks for the tips!
"Dan Guzman" <guzmanda@.nospam-online.sbcglobal.net> wrote in message
news:OY7$75vOFHA.2520@.tk2msftngp13.phx.gbl...
> The 'db chaining' database option is aka cross-database chaining. One
> method to turn it on is with sp_dboption via Query Analyzer:
> EXEC sp_dboption 'Central' ,'db chaining', true
> --
> Hope this helps.
> Dan Guzman
> SQL Server MVP
> "Random" <cipherlad@.hotmail.com> wrote in message
> news:OErPV0rOFHA.3444@.tk2msftngp13.phx.gbl...
>
Permissions on a database
them to have access to this database and nothing else.
At the moment, we want them to have full access to the database (create
tables, delete tables, look at data, update data, create and modify stored
procedures etc.) and any objects they create. They are building an Web
Application for us and we don't want to restrict them while they are
building it.
But we don't want them granting access or revoking access to anyone
(especially not me - I don't think they can since I am the sysadmin). I
later want to be able to restrict their access and limit access to sensitive
information in the database.
I thought about initially setting them up with db_owner access.
Will this prevent me from restricting them later?
If they create the tables, will they still have full access to the tables
(since they were db_owner when they created them)?
Thanks,
Tom.
I would suggest giving them a Windows Authenticated Account and then mapping
that account as the dbo_owner in the database you specify.
If they are good, they will create their objects with the dbo.ObjectName
prefix. If they are not good, then you will end up with objects that look
like Rick.Table1.
You could do and sp_addalias and mark them as dbo in the database.
This should do what you want it to. By using the Windows account, you also
get the benefits of restricting everything else that they might wish to do
on your server as well as evaluate log in times, log outs, minimum password
lengths and so forth.
HTH
Rick Sawtell
MCT, MCSD, MCDBA
|||"Rick Sawtell" <r_sawtell@.hotmail.com> wrote in message
news:OYOEMjttEHA.2876@.TK2MSFTNGP14.phx.gbl...
>I would suggest giving them a Windows Authenticated Account and then
>mapping
> that account as the dbo_owner in the database you specify.
>
But then could I down grade them later, or would they always have dbo access
to objects they created?
> If they are good, they will create their objects with the dbo.ObjectName
> prefix. If they are not good, then you will end up with objects that
> look
> like Rick.Table1.
Would this be a problem for me down the line?
> You could do and sp_addalias and mark them as dbo in the database.
What does that do?
> This should do what you want it to. By using the Windows account, you
> also
> get the benefits of restricting everything else that they might wish to do
> on your server as well as evaluate log in times, log outs, minimum
> password
> lengths and so forth.
I didn't want to give them access to the Windows server at all. That was
why I was having them do Sql Server Authentication. Do I also have to give
them Windows Access also? If that is the case, I why would anyone use the
Sql Server Authentication anyway?
I am just trying to figure out the best way to do this.
Thanks,
Tom.
>
> HTH
> Rick Sawtell
> MCT, MCSD, MCDBA
>
>
|||Can't you let them develop with full access now... and once they are done..
you can change the pwd for that login. That way they will not have complete
access. And for their limited acesss, create a new read only login for their
future use.
Thanks
GYK
"tshad" wrote:
> "Rick Sawtell" <r_sawtell@.hotmail.com> wrote in message
> news:OYOEMjttEHA.2876@.TK2MSFTNGP14.phx.gbl...
> But then could I down grade them later, or would they always have dbo access
> to objects they created?
>
> Would this be a problem for me down the line?
>
> What does that do?
>
> I didn't want to give them access to the Windows server at all. That was
> why I was having them do Sql Server Authentication. Do I also have to give
> them Windows Access also? If that is the case, I why would anyone use the
> Sql Server Authentication anyway?
> I am just trying to figure out the best way to do this.
> Thanks,
> Tom.
>
>
|||
> Would this be a problem for me down the line?
Yes! dbo should own all of the objects in the database. Period.
> What does that do?
It maps them into the database as a dbo rather than as their UserName who is
a member of the db_owners role.
If they are mapped as the dbo, they can do things like: CREATE TABLE Frog
This will make it dbo.Frog by default.
If they are mapped in as a User who is a member of db_owners role, then the
same CREATE TABLE Frog would come back as
UserName.Frog rather than dbo.Frog.
[vbcol=seagreen]
do
> I didn't want to give them access to the Windows server at all. That was
> why I was having them do Sql Server Authentication. Do I also have to
give
> them Windows Access also? If that is the case, I why would anyone use the
> Sql Server Authentication anyway?
If you don't give them access to the Windows computer how do you expect them
to connect to the SQL Server? The SQL Authentication is used to allow SQL
Server to authenticate access to SQL Server rather than Windows
authenticating access to SQL Server.
> I am just trying to figure out the best way to do this.
> Thanks,
=)
Rick
> Tom.
>
Permissions on a database
them to have access to this database and nothing else.
At the moment, we want them to have full access to the database (create
tables, delete tables, look at data, update data, create and modify stored
procedures etc.) and any objects they create. They are building an Web
Application for us and we don't want to restrict them while they are
building it.
But we don't want them granting access or revoking access to anyone
(especially not me - I don't think they can since I am the sysadmin). I
later want to be able to restrict their access and limit access to sensitive
information in the database.
I thought about initially setting them up with db_owner access.
Will this prevent me from restricting them later?
If they create the tables, will they still have full access to the tables
(since they were db_owner when they created them)?
Thanks,
Tom.I would suggest giving them a Windows Authenticated Account and then mapping
that account as the dbo_owner in the database you specify.
If they are good, they will create their objects with the dbo.ObjectName
prefix. If they are not good, then you will end up with objects that look
like Rick.Table1.
You could do and sp_addalias and mark them as dbo in the database.
This should do what you want it to. By using the Windows account, you also
get the benefits of restricting everything else that they might wish to do
on your server as well as evaluate log in times, log outs, minimum password
lengths and so forth.
HTH
Rick Sawtell
MCT, MCSD, MCDBA|||"Rick Sawtell" <r_sawtell@.hotmail.com> wrote in message
news:OYOEMjttEHA.2876@.TK2MSFTNGP14.phx.gbl...
>I would suggest giving them a Windows Authenticated Account and then
>mapping
> that account as the dbo_owner in the database you specify.
>
But then could I down grade them later, or would they always have dbo access
to objects they created?
> If they are good, they will create their objects with the dbo.ObjectName
> prefix. If they are not good, then you will end up with objects that
> look
> like Rick.Table1.
Would this be a problem for me down the line?
> You could do and sp_addalias and mark them as dbo in the database.
What does that do?
> This should do what you want it to. By using the Windows account, you
> also
> get the benefits of restricting everything else that they might wish to do
> on your server as well as evaluate log in times, log outs, minimum
> password
> lengths and so forth.
I didn't want to give them access to the Windows server at all. That was
why I was having them do Sql Server Authentication. Do I also have to give
them Windows Access also? If that is the case, I why would anyone use the
Sql Server Authentication anyway?
I am just trying to figure out the best way to do this.
Thanks,
Tom.
>
> HTH
> Rick Sawtell
> MCT, MCSD, MCDBA
>
>|||Can't you let them develop with full access now... and once they are done..
you can change the pwd for that login. That way they will not have complete
access. And for their limited acesss, create a new read only login for their
future use.
Thanks
GYK
"tshad" wrote:
> "Rick Sawtell" <r_sawtell@.hotmail.com> wrote in message
> news:OYOEMjttEHA.2876@.TK2MSFTNGP14.phx.gbl...
> But then could I down grade them later, or would they always have dbo acce
ss
> to objects they created?
>
> Would this be a problem for me down the line?
>
> What does that do?
>
> I didn't want to give them access to the Windows server at all. That was
> why I was having them do Sql Server Authentication. Do I also have to giv
e
> them Windows Access also? If that is the case, I why would anyone use the
> Sql Server Authentication anyway?
> I am just trying to figure out the best way to do this.
> Thanks,
> Tom.
>
>|||
> Would this be a problem for me down the line?
Yes! dbo should own all of the objects in the database. Period.
> What does that do?
It maps them into the database as a dbo rather than as their UserName who is
a member of the db_owners role.
If they are mapped as the dbo, they can do things like: CREATE TABLE Frog
This will make it dbo.Frog by default.
If they are mapped in as a User who is a member of db_owners role, then the
same CREATE TABLE Frog would come back as
UserName.Frog rather than dbo.Frog.
do[vbcol=seagreen]
> I didn't want to give them access to the Windows server at all. That was
> why I was having them do Sql Server Authentication. Do I also have to
give
> them Windows Access also? If that is the case, I why would anyone use the
> Sql Server Authentication anyway?
If you don't give them access to the Windows computer how do you expect them
to connect to the SQL Server? The SQL Authentication is used to allow SQL
Server to authenticate access to SQL Server rather than Windows
authenticating access to SQL Server.
> I am just trying to figure out the best way to do this.
> Thanks,
=)
Rick
> Tom.
>
Permissions on a database
them to have access to this database and nothing else.
At the moment, we want them to have full access to the database (create
tables, delete tables, look at data, update data, create and modify stored
procedures etc.) and any objects they create. They are building an Web
Application for us and we don't want to restrict them while they are
building it.
But we don't want them granting access or revoking access to anyone
(especially not me - I don't think they can since I am the sysadmin). I
later want to be able to restrict their access and limit access to sensitive
information in the database.
I thought about initially setting them up with db_owner access.
Will this prevent me from restricting them later?
If they create the tables, will they still have full access to the tables
(since they were db_owner when they created them)?
Thanks,
Tom.I would suggest giving them a Windows Authenticated Account and then mapping
that account as the dbo_owner in the database you specify.
If they are good, they will create their objects with the dbo.ObjectName
prefix. If they are not good, then you will end up with objects that look
like Rick.Table1.
You could do and sp_addalias and mark them as dbo in the database.
This should do what you want it to. By using the Windows account, you also
get the benefits of restricting everything else that they might wish to do
on your server as well as evaluate log in times, log outs, minimum password
lengths and so forth.
HTH
Rick Sawtell
MCT, MCSD, MCDBA|||"Rick Sawtell" <r_sawtell@.hotmail.com> wrote in message
news:OYOEMjttEHA.2876@.TK2MSFTNGP14.phx.gbl...
>I would suggest giving them a Windows Authenticated Account and then
>mapping
> that account as the dbo_owner in the database you specify.
>
But then could I down grade them later, or would they always have dbo access
to objects they created?
> If they are good, they will create their objects with the dbo.ObjectName
> prefix. If they are not good, then you will end up with objects that
> look
> like Rick.Table1.
Would this be a problem for me down the line?
> You could do and sp_addalias and mark them as dbo in the database.
What does that do?
> This should do what you want it to. By using the Windows account, you
> also
> get the benefits of restricting everything else that they might wish to do
> on your server as well as evaluate log in times, log outs, minimum
> password
> lengths and so forth.
I didn't want to give them access to the Windows server at all. That was
why I was having them do Sql Server Authentication. Do I also have to give
them Windows Access also? If that is the case, I why would anyone use the
Sql Server Authentication anyway?
I am just trying to figure out the best way to do this.
Thanks,
Tom.
>
> HTH
> Rick Sawtell
> MCT, MCSD, MCDBA
>
>|||Can't you let them develop with full access now... and once they are done..
you can change the pwd for that login. That way they will not have complete
access. And for their limited acesss, create a new read only login for their
future use.
Thanks
GYK
"tshad" wrote:
> "Rick Sawtell" <r_sawtell@.hotmail.com> wrote in message
> news:OYOEMjttEHA.2876@.TK2MSFTNGP14.phx.gbl...
> >I would suggest giving them a Windows Authenticated Account and then
> >mapping
> > that account as the dbo_owner in the database you specify.
> >
> But then could I down grade them later, or would they always have dbo access
> to objects they created?
> > If they are good, they will create their objects with the dbo.ObjectName
> > prefix. If they are not good, then you will end up with objects that
> > look
> > like Rick.Table1.
> Would this be a problem for me down the line?
> >
> > You could do and sp_addalias and mark them as dbo in the database.
> What does that do?
> >
> > This should do what you want it to. By using the Windows account, you
> > also
> > get the benefits of restricting everything else that they might wish to do
> > on your server as well as evaluate log in times, log outs, minimum
> > password
> > lengths and so forth.
> I didn't want to give them access to the Windows server at all. That was
> why I was having them do Sql Server Authentication. Do I also have to give
> them Windows Access also? If that is the case, I why would anyone use the
> Sql Server Authentication anyway?
> I am just trying to figure out the best way to do this.
> Thanks,
> Tom.
> >
> >
> > HTH
> >
> > Rick Sawtell
> > MCT, MCSD, MCDBA
> >
> >
> >
>
>|||> > If they are good, they will create their objects with the dbo.ObjectName
> > prefix. If they are not good, then you will end up with objects that
> > look
> > like Rick.Table1.
> Would this be a problem for me down the line?
Yes! dbo should own all of the objects in the database. Period.
> > You could do and sp_addalias and mark them as dbo in the database.
> What does that do?
It maps them into the database as a dbo rather than as their UserName who is
a member of the db_owners role.
If they are mapped as the dbo, they can do things like: CREATE TABLE Frog
This will make it dbo.Frog by default.
If they are mapped in as a User who is a member of db_owners role, then the
same CREATE TABLE Frog would come back as
UserName.Frog rather than dbo.Frog.
> > This should do what you want it to. By using the Windows account, you
> > also
> > get the benefits of restricting everything else that they might wish to
do
> > on your server as well as evaluate log in times, log outs, minimum
> > password
> > lengths and so forth.
> I didn't want to give them access to the Windows server at all. That was
> why I was having them do Sql Server Authentication. Do I also have to
give
> them Windows Access also? If that is the case, I why would anyone use the
> Sql Server Authentication anyway?
If you don't give them access to the Windows computer how do you expect them
to connect to the SQL Server? The SQL Authentication is used to allow SQL
Server to authenticate access to SQL Server rather than Windows
authenticating access to SQL Server.
> I am just trying to figure out the best way to do this.
> Thanks,
=)
Rick
> Tom.
> >
> >
> > HTH
> >
> > Rick Sawtell
> > MCT, MCSD, MCDBA
> >
> >
> >
>
permissions on a column
i run a sqlserver 2000 and im having problems setting a permission a
column in a table..
under a database i have a User that has dataread rights on each table
in the database, but in one table i want to prevent the user from
seeing a column in one perticular table.
i have created the user under security and then i choose the database
user - properties..and i set a X in the specified column...
when i log on as the datareader user i cant see any colummn at all in
the table..
what have a done wrong?
Steve[posted and mailed, vnligen svara i nys]
steve (stebo@.privat.utfors.se) writes:
> i run a sqlserver 2000 and im having problems setting a permission a
> column in a table..
> under a database i have a User that has dataread rights on each table
> in the database, but in one table i want to prevent the user from
> seeing a column in one perticular table.
> i have created the user under security and then i choose the database
> user - properties..and i set a X in the specified column...
> when i log on as the datareader user i cant see any colummn at all in
> the table..
> what have a done wrong?
Used a GUI instead of looking up the commands in Books Online. GUIs may
do the what you expect, or they may do something else. The command to
use is DENY. Here is an example:
use tempdb
go
exec sp_addlogin accesstest, secret
exec sp_adduser accesstest
exec sp_addrolemember db_datareader, accesstest
go
CREATE TABLE tbl (a int NOT NULL, b varchar(23) NOT NULL)
INSERT tbl (a, b) VALUES (9, 'Top secret')
go
SETUSER 'accesstest'
go
SELECT * FROM tbl
go
SETUSER
go
DENY ALL ON tbl (b) TO accesstest
go
SETUSER 'accesstest'
go
SELECT * FROM tbl
go
SETUSER
go
DROP TABLE tbl
EXEC sp_dropuser accesstest
EXEC sp_droplogin accesstest
--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techin.../2000/books.asp|||thanks for your help!
I will try this, what do you think about using a VIEW, is this a good choice?
BR
Steve
--
Erland Sommarskog <esquel@.sommarskog.se> wrote in message news:<Xns959DF3D2FD2D0Yazorman@.127.0.0.1>...
> [posted and mailed, vnligen svara i nys]
> steve (stebo@.privat.utfors.se) writes:
> > i run a sqlserver 2000 and im having problems setting a permission a
> > column in a table..
> > under a database i have a User that has dataread rights on each table
> > in the database, but in one table i want to prevent the user from
> > seeing a column in one perticular table.
> > i have created the user under security and then i choose the database
> > user - properties..and i set a X in the specified column...
> > when i log on as the datareader user i cant see any colummn at all in
> > the table..
> > what have a done wrong?
> Used a GUI instead of looking up the commands in Books Online. GUIs may
> do the what you expect, or they may do something else. The command to
> use is DENY. Here is an example:
> use tempdb
> go
> exec sp_addlogin accesstest, secret
> exec sp_adduser accesstest
> exec sp_addrolemember db_datareader, accesstest
> go
> CREATE TABLE tbl (a int NOT NULL, b varchar(23) NOT NULL)
> INSERT tbl (a, b) VALUES (9, 'Top secret')
> go
> SETUSER 'accesstest'
> go
> SELECT * FROM tbl
> go
> SETUSER
> go
> DENY ALL ON tbl (b) TO accesstest
> go
> SETUSER 'accesstest'
> go
> SELECT * FROM tbl
> go
> SETUSER
> go
> DROP TABLE tbl
> EXEC sp_dropuser accesstest
> EXEC sp_droplogin accesstest|||steve (stebo@.privat.utfors.se) writes:
> thanks for your help!
> I will try this, what do you think about using a VIEW, is this a good
> choice?
I don't know your business problem, so I cannot comment on that.
--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techin.../2000/books.asp
Monday, February 20, 2012
Permission editor?
I wonder is there a tool for easy setting of custom permissions for user on
database. When i try to do this via the Enterprise Manager it shows all the
objects in the DB without any grouping so it's difficult set permissions.
For example if i want to give SELECT permissions on all tables but not to
give SELECT on the VIEWS and i want to give EXECUTE permission on all
functions i must go around the list and put check-s on the boxes manually.
Thanks in advance
Georgi Peshterski
I suggest you script your tasks instead of performing them from Enterprise
Manager. Take a look at
http://vyaskn.tripod.com/generate_sc..._sql_tasks.htm to find
some useful examples.
HTH,
Vyas, MVP (SQL Server)
SQL Server Articles and Code Samples @. http://vyaskn.tripod.com/
"Georgi Peshterski" <unseen@.mail.bg> wrote in message
news:%233VrKC2aFHA.3040@.TK2MSFTNGP14.phx.gbl...
Hi,
I wonder is there a tool for easy setting of custom permissions for user on
database. When i try to do this via the Enterprise Manager it shows all the
objects in the DB without any grouping so it's difficult set permissions.
For example if i want to give SELECT permissions on all tables but not to
give SELECT on the VIEWS and i want to give EXECUTE permission on all
functions i must go around the list and put check-s on the boxes manually.
Thanks in advance
Georgi Peshterski