Hi all,
I would like to save the output of a FOR XML stored procedure to a file on my hard drive with a filename of my choosing. Can anybody point me in the write direction on how to do this. (I've got the FOR XML sproc written, I just need help figuring out ho
w to persist it to a file. Thanks.
JT
Hi JT,
I noticed you make another post with topic 'Persist Sproc OUTPUT' in the
newsgroup: microsoft.public.sqlserver.programming. I found an community
member has added his reply to that thread and I will add my reply if you
have follow up questions to that thread
Thank you for your patience and cooperation. If you have any questions or
concerns, don't hesitate to let me know. We are here to be of assistance!
Sincerely yours,
Mingqing Cheng
Microsoft Online Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.
Please reply to newsgroups only, many thanks!
|||See the thread entitled "extracting results of XML stored proc to file"
started by Mike UK in this newsgroup.
Cheers,
Graeme
--
Graeme Malcolm
Principal Technologist
Content Master Ltd.
www.contentmaster.com
www.microsoft.com/mspress/books/6137.asp
"JT" <JTnospam@.verizon.net> wrote in message
news:A3758B34-4AC8-4675-8326-319C40508CFF@.microsoft.com...
> Hi all,
> I would like to save the output of a FOR XML stored procedure to a file on
my hard drive with a filename of my choosing. Can anybody point me in the
write direction on how to do this. (I've got the FOR XML sproc written, I
just need help figuring out how to persist it to a file. Thanks.
> JT
|||Thanks Graeme.
JT
Showing posts with label procedure. Show all posts
Showing posts with label procedure. Show all posts
Wednesday, March 28, 2012
Persistence Of Temporary Tables
Is it possible to create a temporary table in a 'parent' stored procedure and then access it from a 'child' or nested stored procedure? Bearing in mind that the child proc will definitely be called by the parent proc.
Look at the article from Erland:
http://www.sommarskog.se/share_data.html
HTH, jens Suessmeyer.
sqlPer-record processing?
Hi,
I am looking for a way to process each record from a SELECT query. Each record has to go through a stored procedure to be validated and different actions have to be taken depending on whether or not it passes the validation.
I'm a bit new to Transact SQL. My background is in programming, so I keep wanting to visualize a loop, which doesn't exist in TSQL, from what I understand. Can anyone help me understand how something of this type would be done?
Thank you!
SQL Server is designed for SET based operation. 'Per-Record' operations are often best left to a client application.
However, in some situations, it may be necessary to (a) gather relavent records into a temporary table, (b) set a counter variable with the @.@.Rowcount from the temporary table, (c) use a WHILE @.CurrentRecord < @.RecordCount type of loop.
However, this is guarenteed to be a non-optimal use of SQL Server. Perhaps if you were to post the select query, the stored procedure, and some sample data, folks here would help you properly design a SET based operation -if possible.
|||Thank you. I think this is just what I needed to move this into a .Net app.sqlMonday, March 26, 2012
Permissions With Dynamic SQL Within Stored Procedure
Okay, I have sort of a peculiar permissions question I am wondering if someone can help me with. Basically, here's the scenario...
I have a CLR stored procedure which does some dynamic SQL building based on values sent in via XML. It's a CLR stored procedure using XML because I want to build a parameterized statement (to guard against SQL Injection) based on a flexible number of parameters which are basically passed in the XML.
The dynamic SQL ends up reading from a table I'll call TableX and I actually discovered an (understandable) quirk with security.
Basically, the connection context is using security for a low-privilaged Windows account ("UserX") and UserX has no permission to the table referenced in the dynamic SQL but because of the dyanmic nature of the query, the stored procedure ends up adopting the security context of UserX. Naturally, this throws a security exception saying UserX has no SELECT permission on TableX.
Now, I can give UserX read permission to the table in question to get things running, but one of the points of using stored procedures is to defer security to the procedure level vs. configuration for tables or columns.
So in striving toward my ideal of security at the procedure level, my question is what is the best way to allow minimum privilege in this case?
I thought about having the internals of the CLR stored procedure run under a different (low-privalaged) security context, but I am wondering if there's an alternate configuration that may be as secure, but simpler.
PS - Please don't let this degenerate into a conversation about OR mappers. I know that happens a lot on these forums.
BoulderBum:
Basically, the connection context is using security for a low-privilaged Windows account ("UserX") and UserX has no permission to the table referenced in the dynamic SQL but because of the dyanmic nature of the query, the stored procedure ends up adopting the security context of UserX. Naturally, this throws a security exception saying UserX has no SELECT permission on TableX.
Yes, this is by design. When you EXECUTE dynamic SQL statement. When a stored procedure is run that executes a string, permissions are checked in the context of the user who executes the procedure, not in the context of the user who created the procedure.
So in earlier SQL versions you have to choose: use dynamic SQL if you do have to, or not use it if not necessary. Fortunately in SQL 2005 we have another option: using EXECUTE AS clause when creating the stored procedure. For example:
create proc sp_testper WITH EXECUTE AS SELF
as
EXEC('select * from Orders')
go
For more information about this clause, please refer to:
http://msdn2.microsoft.com/en-us/library/ms188354(d=ide).aspx
|||Thanks, lori_Jay.
That's the solution I'm probably going to end up going with, though I didn't know until a few days ago that EXECUTE AS could apply toCLRstored procedures. I was just deploying via the IDE which doesn't offer such options and the documentation I saw didn't give an example of how to use EXECUTE AS with a CLR stored procedure.
Luckily I was informed that it was indeed possible and though I haven't sat down to do it yet, and that solution suffices for my needs!
Anyway, thanks again!
|||For future readers, something else I discovered comes in handy is that you can have a predeployscripts.sql and postdeployscripts.sql file in a database project.
With those files, I was able to rig the EXECUTE AS and change the schema for my stored procedures. It took some dropping/recreating to get everything where I wanted, but it was pretty easy and worked like a charm.
I now have one-touch deployment of my CLR stored procedures through Visual Studio again!
Friday, March 23, 2012
Permissions Problem using Dynamic SQL
Hi all!
I've got a problem where I have created a stored procedure (using MS SQL Server 2000) that does a temporary table creation:
CREATE #tmpData ( [some_fields] )
and then it uses dynamic SQL to populate the data
SELECT @.ExecStr =
'INSERT INTO #tmpData
SELECT * FROM tData
WHERE [some_condition]
ORDER BY ' + @.SortColumn /* input parm to the stored proc */
EXEC (@.ExecStr)
I get a permissions error 229 when I try to run this because my user only has execute permissions for the stored procedure within the database. The only thing that I've found so far that will fix this is if I change the user's permissions to db_owner, which I don't want to do.
I've tried to explicitly grant permission within the stored proc, but since the object (the temp table) does not actually reside in the database, that gives me an error as well (4610: You can only grant or revoke permissions on objects in the current database.).
Is there anything else I can do? I really don't want to have to give the user that much freedom within the database, and removing the dynamic SQL really isn't a viable option either.
Thanks in advance for your help!
CatDynamic SQL executes within its own scope, not that of the stored procedure. So it does not inherit the stored procedures rights, and only operates under the connection's rights.
You'll need to grant READ permission to the user on table tData.|||Try this ... put your insert before your exec ...
SET NOCOUNT ON
USE master
create table #temp (dbname sysname)
declare @.sql nvarchar(255)
select @.sql = 'select name from sysdatabases'
insert into #temp
exec sp_executesql @.sql
select * from #temp
drop table #temp|||Thanks, Tom!
That was a good idea. Unfortunately it still gives me the same error.
Thanks again! If you have any other ideas, let me know.
Cat|||Your user is going to have to have select permissions on tData.|||Excellent suggestion.
You'll need to grant READ permission to the user on table tData.|||Thanks everyone!
I did get this running with just the SELECT permissions on the data tables involved. Although this is still not ideal from a security perspective, it is better than having to give them db_owner. I appreciate the feedback!
Thanks again,
Cat|||If security is a big issue, you could create a view based upon the table showing only the required columns and filtered rows, and then reference the view in your dynamic SQL. Then you can grant permissions on the view rather than on the table.|||Excellent suggestion.
Good advice is always worth repeating :cool:|||You could kludge your way around part of the problem using something like:DECLARE @.i INT
SET @.i = 1
SELECT o.name
FROM dbo.sysobjects AS o
ORDER BY
CASE @.i
WHEN 1 THEN o.name
WHEN 2 THEN Str(o.id, 20)
ELSE Convert(CHAR(30), crdate, 121)
END-PatP|||If security is a big issue,
I have to go change my pants now
"If"...good lord
I've got a problem where I have created a stored procedure (using MS SQL Server 2000) that does a temporary table creation:
CREATE #tmpData ( [some_fields] )
and then it uses dynamic SQL to populate the data
SELECT @.ExecStr =
'INSERT INTO #tmpData
SELECT * FROM tData
WHERE [some_condition]
ORDER BY ' + @.SortColumn /* input parm to the stored proc */
EXEC (@.ExecStr)
I get a permissions error 229 when I try to run this because my user only has execute permissions for the stored procedure within the database. The only thing that I've found so far that will fix this is if I change the user's permissions to db_owner, which I don't want to do.
I've tried to explicitly grant permission within the stored proc, but since the object (the temp table) does not actually reside in the database, that gives me an error as well (4610: You can only grant or revoke permissions on objects in the current database.).
Is there anything else I can do? I really don't want to have to give the user that much freedom within the database, and removing the dynamic SQL really isn't a viable option either.
Thanks in advance for your help!
CatDynamic SQL executes within its own scope, not that of the stored procedure. So it does not inherit the stored procedures rights, and only operates under the connection's rights.
You'll need to grant READ permission to the user on table tData.|||Try this ... put your insert before your exec ...
SET NOCOUNT ON
USE master
create table #temp (dbname sysname)
declare @.sql nvarchar(255)
select @.sql = 'select name from sysdatabases'
insert into #temp
exec sp_executesql @.sql
select * from #temp
drop table #temp|||Thanks, Tom!
That was a good idea. Unfortunately it still gives me the same error.
Thanks again! If you have any other ideas, let me know.
Cat|||Your user is going to have to have select permissions on tData.|||Excellent suggestion.
You'll need to grant READ permission to the user on table tData.|||Thanks everyone!
I did get this running with just the SELECT permissions on the data tables involved. Although this is still not ideal from a security perspective, it is better than having to give them db_owner. I appreciate the feedback!
Thanks again,
Cat|||If security is a big issue, you could create a view based upon the table showing only the required columns and filtered rows, and then reference the view in your dynamic SQL. Then you can grant permissions on the view rather than on the table.|||Excellent suggestion.
Good advice is always worth repeating :cool:|||You could kludge your way around part of the problem using something like:DECLARE @.i INT
SET @.i = 1
SELECT o.name
FROM dbo.sysobjects AS o
ORDER BY
CASE @.i
WHEN 1 THEN o.name
WHEN 2 THEN Str(o.id, 20)
ELSE Convert(CHAR(30), crdate, 121)
END-PatP|||If security is a big issue,
I have to go change my pants now
"If"...good lord
Wednesday, March 21, 2012
Permissions Problem using Dynamic SQL
Hi all!
I've got a problem where I have created a stored procedure (using MS SQL Server 2000) that does a temporary table creation:
Code Snippet
CREATE #tmpData ( [some_fields] )and then it uses dynamic SQL to populate the data
Code Snippet
SELECT @.ExecStr ='INSERT INTO #tmpData
SELECT * FROM tData
WHERE [some_condition]
ORDER BY ' + @.SortColumn /* input parm to the SP */
EXEC (@.ExecStr)
I get a permissions error 229 when I try to run this because my user only has execute permissions for the stored procedure within the database. The only thing that I've found so far that will fix this is if I change the user's permissions to db_owner, which I don't want to do.
I've tried to explicitly grant permission within the stored proc, but since the object (the temp table) does not actually reside in the database, that gives me an error as well (4610: You can only grant or revoke permissions on objects in the current database.).
Is there anything else I can do? I really don't want to have to give the user that much freedom within the database, and removing the dynamic SQL really isn't a viable option either.
Thanks in advance for your help!
Cat
If you are using SQL 2000, you have no choice. To use dynamic SQL requires a high level of permissions.
IF you are using SQL 2005, explore the 'EXECUTE AS' property.
Refer to Books Online, Topic: 'EXECUTE AS'
Permissions on a new stored procedure
Help!
I usually use SQL 2000 at work but upon deciding to work from home have installed and setup SQL express 2005. I use the management studio to write table and sps but for new sp I cannot find how to allow permission. I have been able to allow permission for all sps on the database I restored that I am now working on and have successfully allocated permissions to a new table but cannot do the same with the sp. The sp is viewable in the database but permission is denied when attempting to execute via my ASP script.
Any ideas?
Error Type:
Microsoft SQL Native Client (0x80040E09)
EXECUTE permission denied on object 'procBannerSlotList', database 'HotLizardWebsite', schema 'dbo'.
It seems after all this time I've managed to work it out for myself - so for anyone out there not aware of the solution - the solution is this:
In the database security - right click the role you wish permissions to be set for. Go to the Securables section, click Add and just add all objects belonging to dbo - I then just removed the dt prefixed objects that were not relevant - sp permissions now fully operational
Permissions on a Database
I have a user that need to create stored procedures but as the dbo account and not his own account so that the stored procedure is called dbo.storedprocedure and not domain\user.storedprocedure. He is a database owner but in order to have this happen I have to have him in the local Server Administrator group. What have I done wrong?
Also, he need to be able to run Enterprise Manager and SQL Ananlysis manager but I do not want him to be a local administrator but they will not start if he is just a local user. How can I accomplish it.
Thanks,
Stryder :confused:First of all, uninstall Enterprise Manager from his workstation.
All the user will need is db_owner permissions on the database. If he uses scripts, he can issue the create procedure command with the proper name (including owner) of the procedure:
create procedure [dbo].[someproc]
as
...
I do not know if this is possible in Enterprise Manager, as I never use EM to create procedures.
As for Analysis Manager, this is a bit thornier. There is a special local group on the Analysis Services Machine called Olap Administrators. Only members of this group can use Analysis Manger. The catch is that it is pretty much a binary permission. Either you are an Olap Administrator, or you are a simple user. No in between.
Hope this helps.sql
Also, he need to be able to run Enterprise Manager and SQL Ananlysis manager but I do not want him to be a local administrator but they will not start if he is just a local user. How can I accomplish it.
Thanks,
Stryder :confused:First of all, uninstall Enterprise Manager from his workstation.
All the user will need is db_owner permissions on the database. If he uses scripts, he can issue the create procedure command with the proper name (including owner) of the procedure:
create procedure [dbo].[someproc]
as
...
I do not know if this is possible in Enterprise Manager, as I never use EM to create procedures.
As for Analysis Manager, this is a bit thornier. There is a special local group on the Analysis Services Machine called Olap Administrators. Only members of this group can use Analysis Manger. The catch is that it is pretty much a binary permission. Either you are an Olap Administrator, or you are a simple user. No in between.
Hope this helps.sql
Tuesday, March 20, 2012
permissions for user to rename a table
What permissions must I grant to allow a user to rename a table?
I have my stored procedure rename a table when it is done, but it fails and
says the user does not have permission.
ThanksI figured it out
I had to add the user as a user in the MASTER db and then grant exec on
sp_rename to the user
Thanks
"Tarren" <noemailplease@.thanks.com> wrote in message
news:%23zYU59NXFHA.1468@.tk2msftngp13.phx.gbl...
> What permissions must I grant to allow a user to rename a table?
> I have my stored procedure rename a table when it is done, but it fails
> and says the user does not have permission.
> Thanks
>|||You have an SP that renames a table in the MASTER database?
"Tarren" <noemailplease@.thanks.com> wrote in message
news:%23zYU59NXFHA.1468@.tk2msftngp13.phx.gbl...
> What permissions must I grant to allow a user to rename a table?
> I have my stored procedure rename a table when it is done, but it fails
and
> says the user does not have permission.
> Thanks
>|||I'm curious as to why you would want to rename a table in an SP.
David Portas
SQL Server MVP
--|||the SP is a procedure in my ETL process that loads from all of the incoming
tables into a master_staging table and then cleans the data with a number of
individual updates
then, after the several minute process completes, it swaps the current
master table with the master_staging table using three sp_rename statements
This lets me load the fresh data from the incoming tables every night and
provide 24x7 uptime on the master table (not having it be out of commission
for several minutes a day) since all of the inserting and updating never
take place in the live master table.
:)
"David Portas" <REMOVE_BEFORE_REPLYING_dportas@.acm.org> wrote in message
news:1116593359.212844.263680@.o13g2000cwo.googlegroups.com...
> I'm curious as to why you would want to rename a table in an SP.
> --
> David Portas
> SQL Server MVP
> --
>|||the procedure to rename an object in SQL Server 2000 is located in the
Master DB with all of the other SQL Server sp's
"JT" <someone@.microsoft.com> wrote in message
news:u9$SJnTXFHA.3140@.TK2MSFTNGP14.phx.gbl...
> You have an SP that renames a table in the MASTER database?
> "Tarren" <noemailplease@.thanks.com> wrote in message
> news:%23zYU59NXFHA.1468@.tk2msftngp13.phx.gbl...
> and
>|||If that is the case, then why not simply add a date field to your staging ta
bles
that stores the date they were populated and periodically delete rows based
on
this date?
Thomas
"Tarren" <noemailplease@.thanks.com> wrote in message
news:OOLBq1yXFHA.3712@.TK2MSFTNGP09.phx.gbl...
> the SP is a procedure in my ETL process that loads from all of the incomin
g
> tables into a master_staging table and then cleans the data with a number
of
> individual updates
> then, after the several minute process completes, it swaps the current mas
ter
> table with the master_staging table using three sp_rename statements
> This lets me load the fresh data from the incoming tables every night and
> provide 24x7 uptime on the master table (not having it be out of commissio
n
> for several minutes a day) since all of the inserting and updating never t
ake
> place in the live master table.
> :)
>
> "David Portas" <REMOVE_BEFORE_REPLYING_dportas@.acm.org> wrote in message
> news:1116593359.212844.263680@.o13g2000cwo.googlegroups.com...
>
I have my stored procedure rename a table when it is done, but it fails and
says the user does not have permission.
ThanksI figured it out
I had to add the user as a user in the MASTER db and then grant exec on
sp_rename to the user
Thanks
"Tarren" <noemailplease@.thanks.com> wrote in message
news:%23zYU59NXFHA.1468@.tk2msftngp13.phx.gbl...
> What permissions must I grant to allow a user to rename a table?
> I have my stored procedure rename a table when it is done, but it fails
> and says the user does not have permission.
> Thanks
>|||You have an SP that renames a table in the MASTER database?
"Tarren" <noemailplease@.thanks.com> wrote in message
news:%23zYU59NXFHA.1468@.tk2msftngp13.phx.gbl...
> What permissions must I grant to allow a user to rename a table?
> I have my stored procedure rename a table when it is done, but it fails
and
> says the user does not have permission.
> Thanks
>|||I'm curious as to why you would want to rename a table in an SP.
David Portas
SQL Server MVP
--|||the SP is a procedure in my ETL process that loads from all of the incoming
tables into a master_staging table and then cleans the data with a number of
individual updates
then, after the several minute process completes, it swaps the current
master table with the master_staging table using three sp_rename statements
This lets me load the fresh data from the incoming tables every night and
provide 24x7 uptime on the master table (not having it be out of commission
for several minutes a day) since all of the inserting and updating never
take place in the live master table.
:)
"David Portas" <REMOVE_BEFORE_REPLYING_dportas@.acm.org> wrote in message
news:1116593359.212844.263680@.o13g2000cwo.googlegroups.com...
> I'm curious as to why you would want to rename a table in an SP.
> --
> David Portas
> SQL Server MVP
> --
>|||the procedure to rename an object in SQL Server 2000 is located in the
Master DB with all of the other SQL Server sp's
"JT" <someone@.microsoft.com> wrote in message
news:u9$SJnTXFHA.3140@.TK2MSFTNGP14.phx.gbl...
> You have an SP that renames a table in the MASTER database?
> "Tarren" <noemailplease@.thanks.com> wrote in message
> news:%23zYU59NXFHA.1468@.tk2msftngp13.phx.gbl...
> and
>|||If that is the case, then why not simply add a date field to your staging ta
bles
that stores the date they were populated and periodically delete rows based
on
this date?
Thomas
"Tarren" <noemailplease@.thanks.com> wrote in message
news:OOLBq1yXFHA.3712@.TK2MSFTNGP09.phx.gbl...
> the SP is a procedure in my ETL process that loads from all of the incomin
g
> tables into a master_staging table and then cleans the data with a number
of
> individual updates
> then, after the several minute process completes, it swaps the current mas
ter
> table with the master_staging table using three sp_rename statements
> This lets me load the fresh data from the incoming tables every night and
> provide 24x7 uptime on the master table (not having it be out of commissio
n
> for several minutes a day) since all of the inserting and updating never t
ake
> place in the live master table.
> :)
>
> "David Portas" <REMOVE_BEFORE_REPLYING_dportas@.acm.org> wrote in message
> news:1116593359.212844.263680@.o13g2000cwo.googlegroups.com...
>
Permissions for Stored Procedures generated by VS 2005
I have a DataSet (Data Component in Beta 1) and I want to add Fill andGet methods by using a Stored Procedure that was created by VS 2005 (aspnet_Membership_GetAllUsers). I probably need to use Enterprise Manager to do so but I am not sure what permissions I need to set and how to set them.
Stored Proc permissions are DBO(database owner). Hope this helps.
Monday, March 12, 2012
Permissions for OleDb to an As400
I have a store procedure written in VB.NET to access an AS400 using System.Data.OleDb. I created the key for the procedure as a .pfx file and before adding the code to access the AS400, I tested it against a SQL Server database and it worked fine. When I added the code to access the AS400, I get the following error:
A .NET Framework error occurred during execution of user defined routine or aggregate 'ap_mapics_Data':
System.Security.SecurityException: Request for the permission of type 'System.Data.OleDb.OleDbPermission, System.Data, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' failed.
System.Security.SecurityException:
at System.Security.CodeAccessSecurityEngine.Check(Object demand, StackCrawlMark& stackMark, Boolean isPermSet)
at System.Security.PermissionSet.Demand()
at System.Data.Common.DbConnectionOptions.DemandPermission()
at System.Data.OleDb.OleDbConnection.PermissionDemand()
at System.Data.OleDb.OleDbConnectionFactory.PermissionDemand(DbConnection outerConnection)
at System.Data.ProviderBase.DbConnectionClosed.OpenConnection(DbConnection outerConnection, DbConnectionFactory connectionFactory)
at System.Data.OleDb.OleDbConnection.Open()
at ProImage_Procedures_Test.StoredProcedures.ap_mapics_Data()
OleDbPermission is only available to assemblies deployed with an UNSAFE CAS permission set grant. Given that your code worked against what is presumably another SQL Server database, I'm guessing that your assembly is deployed with an EXTERNAL_ACCESS grant. If you want more information about the permissions granted at each level, see http://bordecal.mvps.org/Nicole/SqlClrCas/SqlClrCasSpeculations.htm.permissions for new user to use stored procedure
Using SS2000 SP4. If I have a table and revoke select, insert, update and
delete to public on the table. Then create a new user and don't give them an
y
permissions to the table. If I create stored procedures to select from,
insert into, update and delete from the table do I only have to give execute
permissions on the stored procedure to the new user for the user to be able
to execute those stored procedures? Am I correct in saying that the new user
doesn't have to have any kind of permissions on the table itself?
Thanks,
--
Dan D.That's correct. Indeed, you didn't need to revoke or deny anything on the
underlying tables, since a user has no permissions on an object by default.
All you have to do is grant EXEC permission on the proc.
Tom
----
Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
SQL Server MVP
Toronto, ON Canada
.
"Dan D." <DanD@.discussions.microsoft.com> wrote in message
news:D2083411-5A89-4F04-B1A5-373403FE75EC@.microsoft.com...
Using SS2000 SP4. If I have a table and revoke select, insert, update and
delete to public on the table. Then create a new user and don't give them
any
permissions to the table. If I create stored procedures to select from,
insert into, update and delete from the table do I only have to give execute
permissions on the stored procedure to the new user for the user to be able
to execute those stored procedures? Am I correct in saying that the new user
doesn't have to have any kind of permissions on the table itself?
Thanks,
--
Dan D.|||Wouldn't the user have permissions on the table because they are in the
'public' role by default?
Also, is the same true with views? If the user has select permission to the
view they don't need select on the underlying table?
Thanks,
--
Dan D.
"Tom Moreau" wrote:
> That's correct. Indeed, you didn't need to revoke or deny anything on the
> underlying tables, since a user has no permissions on an object by default
.
> All you have to do is grant EXEC permission on the proc.
> --
> Tom
> ----
> Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
> SQL Server MVP
> Toronto, ON Canada
> ..
> "Dan D." <DanD@.discussions.microsoft.com> wrote in message
> news:D2083411-5A89-4F04-B1A5-373403FE75EC@.microsoft.com...
> Using SS2000 SP4. If I have a table and revoke select, insert, update and
> delete to public on the table. Then create a new user and don't give them
> any
> permissions to the table. If I create stored procedures to select from,
> insert into, update and delete from the table do I only have to give execu
te
> permissions on the stored procedure to the new user for the user to be abl
e
> to execute those stored procedures? Am I correct in saying that the new us
er
> doesn't have to have any kind of permissions on the table itself?
> Thanks,
> --
> Dan D.
>|||Let's say you create a table. By default, there are no permissions on the
table - even to the public role. Same goes for any other object.
You can grant permission on a view without granting permission on the
underlying tables. (This gets messed up if you're not the owner of the
underlying tables, though.)
Tom
----
Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
SQL Server MVP
Toronto, ON Canada
.
"Dan D." <DanD@.discussions.microsoft.com> wrote in message
news:EC40014C-0943-4CC3-9FDD-BFE610495BFD@.microsoft.com...
Wouldn't the user have permissions on the table because they are in the
'public' role by default?
Also, is the same true with views? If the user has select permission to the
view they don't need select on the underlying table?
Thanks,
--
Dan D.
"Tom Moreau" wrote:
> That's correct. Indeed, you didn't need to revoke or deny anything on the
> underlying tables, since a user has no permissions on an object by
> default.
> All you have to do is grant EXEC permission on the proc.
> --
> Tom
> ----
> Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
> SQL Server MVP
> Toronto, ON Canada
> ..
> "Dan D." <DanD@.discussions.microsoft.com> wrote in message
> news:D2083411-5A89-4F04-B1A5-373403FE75EC@.microsoft.com...
> Using SS2000 SP4. If I have a table and revoke select, insert, update and
> delete to public on the table. Then create a new user and don't give them
> any
> permissions to the table. If I create stored procedures to select from,
> insert into, update and delete from the table do I only have to give
> execute
> permissions on the stored procedure to the new user for the user to be
> able
> to execute those stored procedures? Am I correct in saying that the new
> user
> doesn't have to have any kind of permissions on the table itself?
> Thanks,
> --
> Dan D.
>|||I understand. Thanks.
--
Dan D.
"Tom Moreau" wrote:
> Let's say you create a table. By default, there are no permissions on the
> table - even to the public role. Same goes for any other object.
> You can grant permission on a view without granting permission on the
> underlying tables. (This gets messed up if you're not the owner of the
> underlying tables, though.)
> --
> Tom
> ----
> Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
> SQL Server MVP
> Toronto, ON Canada
> ..
> "Dan D." <DanD@.discussions.microsoft.com> wrote in message
> news:EC40014C-0943-4CC3-9FDD-BFE610495BFD@.microsoft.com...
> Wouldn't the user have permissions on the table because they are in the
> 'public' role by default?
> Also, is the same true with views? If the user has select permission to th
e
> view they don't need select on the underlying table?
> Thanks,
> --
> Dan D.
>
> "Tom Moreau" wrote:
>
>
delete to public on the table. Then create a new user and don't give them an
y
permissions to the table. If I create stored procedures to select from,
insert into, update and delete from the table do I only have to give execute
permissions on the stored procedure to the new user for the user to be able
to execute those stored procedures? Am I correct in saying that the new user
doesn't have to have any kind of permissions on the table itself?
Thanks,
--
Dan D.That's correct. Indeed, you didn't need to revoke or deny anything on the
underlying tables, since a user has no permissions on an object by default.
All you have to do is grant EXEC permission on the proc.
Tom
----
Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
SQL Server MVP
Toronto, ON Canada
.
"Dan D." <DanD@.discussions.microsoft.com> wrote in message
news:D2083411-5A89-4F04-B1A5-373403FE75EC@.microsoft.com...
Using SS2000 SP4. If I have a table and revoke select, insert, update and
delete to public on the table. Then create a new user and don't give them
any
permissions to the table. If I create stored procedures to select from,
insert into, update and delete from the table do I only have to give execute
permissions on the stored procedure to the new user for the user to be able
to execute those stored procedures? Am I correct in saying that the new user
doesn't have to have any kind of permissions on the table itself?
Thanks,
--
Dan D.|||Wouldn't the user have permissions on the table because they are in the
'public' role by default?
Also, is the same true with views? If the user has select permission to the
view they don't need select on the underlying table?
Thanks,
--
Dan D.
"Tom Moreau" wrote:
> That's correct. Indeed, you didn't need to revoke or deny anything on the
> underlying tables, since a user has no permissions on an object by default
.
> All you have to do is grant EXEC permission on the proc.
> --
> Tom
> ----
> Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
> SQL Server MVP
> Toronto, ON Canada
> ..
> "Dan D." <DanD@.discussions.microsoft.com> wrote in message
> news:D2083411-5A89-4F04-B1A5-373403FE75EC@.microsoft.com...
> Using SS2000 SP4. If I have a table and revoke select, insert, update and
> delete to public on the table. Then create a new user and don't give them
> any
> permissions to the table. If I create stored procedures to select from,
> insert into, update and delete from the table do I only have to give execu
te
> permissions on the stored procedure to the new user for the user to be abl
e
> to execute those stored procedures? Am I correct in saying that the new us
er
> doesn't have to have any kind of permissions on the table itself?
> Thanks,
> --
> Dan D.
>|||Let's say you create a table. By default, there are no permissions on the
table - even to the public role. Same goes for any other object.
You can grant permission on a view without granting permission on the
underlying tables. (This gets messed up if you're not the owner of the
underlying tables, though.)
Tom
----
Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
SQL Server MVP
Toronto, ON Canada
.
"Dan D." <DanD@.discussions.microsoft.com> wrote in message
news:EC40014C-0943-4CC3-9FDD-BFE610495BFD@.microsoft.com...
Wouldn't the user have permissions on the table because they are in the
'public' role by default?
Also, is the same true with views? If the user has select permission to the
view they don't need select on the underlying table?
Thanks,
--
Dan D.
"Tom Moreau" wrote:
> That's correct. Indeed, you didn't need to revoke or deny anything on the
> underlying tables, since a user has no permissions on an object by
> default.
> All you have to do is grant EXEC permission on the proc.
> --
> Tom
> ----
> Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
> SQL Server MVP
> Toronto, ON Canada
> ..
> "Dan D." <DanD@.discussions.microsoft.com> wrote in message
> news:D2083411-5A89-4F04-B1A5-373403FE75EC@.microsoft.com...
> Using SS2000 SP4. If I have a table and revoke select, insert, update and
> delete to public on the table. Then create a new user and don't give them
> any
> permissions to the table. If I create stored procedures to select from,
> insert into, update and delete from the table do I only have to give
> execute
> permissions on the stored procedure to the new user for the user to be
> able
> to execute those stored procedures? Am I correct in saying that the new
> user
> doesn't have to have any kind of permissions on the table itself?
> Thanks,
> --
> Dan D.
>|||I understand. Thanks.
--
Dan D.
"Tom Moreau" wrote:
> Let's say you create a table. By default, there are no permissions on the
> table - even to the public role. Same goes for any other object.
> You can grant permission on a view without granting permission on the
> underlying tables. (This gets messed up if you're not the owner of the
> underlying tables, though.)
> --
> Tom
> ----
> Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
> SQL Server MVP
> Toronto, ON Canada
> ..
> "Dan D." <DanD@.discussions.microsoft.com> wrote in message
> news:EC40014C-0943-4CC3-9FDD-BFE610495BFD@.microsoft.com...
> Wouldn't the user have permissions on the table because they are in the
> 'public' role by default?
> Also, is the same true with views? If the user has select permission to th
e
> view they don't need select on the underlying table?
> Thanks,
> --
> Dan D.
>
> "Tom Moreau" wrote:
>
>
Permissions and ODBC
There are 2 SQL databases involved and an MS Access program... also using
windows authentication...
The Ms Access program executes a stored procedure that resides in SQL
database#1, the stored procedure updates data in SQL dataabase#2..
Assume the user has rights to execute the stored procedure in database#1.
How can you best limit the rights of the user to database#2, but still allow
them to execute the stored procedure in database#1 that updates the data in
database#2 ?Permissions on indirectly referenced objects are not needed as long as the
objects have the same owner (i.e. owner maps to the same login). In the
case of dbo-owned objects in different databases, the databases need to have
the same owner so that the dbo user maps to the same login. You can change
database owners using sp_changedbowner, if needed. Also, cross-database
ownership chaining is a configurable option in SQL 2000 SP3 and needs to be
enabled in both databases. You can enable this using sp_dboption:
EXEC sp_dboption 'Database1', 'db chaining', true
EXEC sp_dboption 'Database2', 'db chaining', true
The main security consideration with cross-database chaining is that you
should enable the option only if you trust users with object CREATE
permissions in those databases. See the SQL 2003 SP3 Books Online for more
info.
--
Hope this helps.
Dan Guzman
SQL Server MVP
"rob" <rwc1960@.bellsouth.net> wrote in message
news:MYW0d.113845$0o5.105823@.bignews1.bellsouth.net...
> There are 2 SQL databases involved and an MS Access program... also using
> windows authentication...
> The Ms Access program executes a stored procedure that resides in SQL
> database#1, the stored procedure updates data in SQL dataabase#2..
> Assume the user has rights to execute the stored procedure in database#1.
> How can you best limit the rights of the user to database#2, but still
> allow
> them to execute the stored procedure in database#1 that updates the data
> in
> database#2 ?
>
>
>
windows authentication...
The Ms Access program executes a stored procedure that resides in SQL
database#1, the stored procedure updates data in SQL dataabase#2..
Assume the user has rights to execute the stored procedure in database#1.
How can you best limit the rights of the user to database#2, but still allow
them to execute the stored procedure in database#1 that updates the data in
database#2 ?Permissions on indirectly referenced objects are not needed as long as the
objects have the same owner (i.e. owner maps to the same login). In the
case of dbo-owned objects in different databases, the databases need to have
the same owner so that the dbo user maps to the same login. You can change
database owners using sp_changedbowner, if needed. Also, cross-database
ownership chaining is a configurable option in SQL 2000 SP3 and needs to be
enabled in both databases. You can enable this using sp_dboption:
EXEC sp_dboption 'Database1', 'db chaining', true
EXEC sp_dboption 'Database2', 'db chaining', true
The main security consideration with cross-database chaining is that you
should enable the option only if you trust users with object CREATE
permissions in those databases. See the SQL 2003 SP3 Books Online for more
info.
--
Hope this helps.
Dan Guzman
SQL Server MVP
"rob" <rwc1960@.bellsouth.net> wrote in message
news:MYW0d.113845$0o5.105823@.bignews1.bellsouth.net...
> There are 2 SQL databases involved and an MS Access program... also using
> windows authentication...
> The Ms Access program executes a stored procedure that resides in SQL
> database#1, the stored procedure updates data in SQL dataabase#2..
> Assume the user has rights to execute the stored procedure in database#1.
> How can you best limit the rights of the user to database#2, but still
> allow
> them to execute the stored procedure in database#1 that updates the data
> in
> database#2 ?
>
>
>
Permissions and ODBC
There are 2 SQL databases involved and an MS Access program... also using
windows authentication...
The Ms Access program executes a stored procedure that resides in SQL
database#1, the stored procedure updates data in SQL dataabase#2..
Assume the user has rights to execute the stored procedure in database#1,
how can you best limit the rights of the user to database#2, but still allow
them to execute the stored procedure in database#1 that updates the data in
database#2 ?
If you have SP3 installed (and you should have), make sure you
understand the rules for cross-database ownership chaining, as
explained in SQL Books Online. You can download the latest version
from http://www.microsoft.com/sql/techinf...000/books.asp.
In general, if you confine all data operations to stored procedures,
you only need to grant Execute permissions on the stored procedures
while revoking or denying select, update, insert and delete
permissions on the base tables/views to the public role so that the
permissions can't be inherited. Creating parameterized stored
procedures and staying away from dynamic SQL statements are two
techniques to reduce the attack surface of your application.
--Mary
On Sat, 11 Sep 2004 22:40:59 -0400, "rob" <rwc1960@.bellsouth.net>
wrote:
>There are 2 SQL databases involved and an MS Access program... also using
>windows authentication...
>The Ms Access program executes a stored procedure that resides in SQL
>database#1, the stored procedure updates data in SQL dataabase#2..
>Assume the user has rights to execute the stored procedure in database#1,
>how can you best limit the rights of the user to database#2, but still allow
>them to execute the stored procedure in database#1 that updates the data in
>database#2 ?
>
>
windows authentication...
The Ms Access program executes a stored procedure that resides in SQL
database#1, the stored procedure updates data in SQL dataabase#2..
Assume the user has rights to execute the stored procedure in database#1,
how can you best limit the rights of the user to database#2, but still allow
them to execute the stored procedure in database#1 that updates the data in
database#2 ?
If you have SP3 installed (and you should have), make sure you
understand the rules for cross-database ownership chaining, as
explained in SQL Books Online. You can download the latest version
from http://www.microsoft.com/sql/techinf...000/books.asp.
In general, if you confine all data operations to stored procedures,
you only need to grant Execute permissions on the stored procedures
while revoking or denying select, update, insert and delete
permissions on the base tables/views to the public role so that the
permissions can't be inherited. Creating parameterized stored
procedures and staying away from dynamic SQL statements are two
techniques to reduce the attack surface of your application.
--Mary
On Sat, 11 Sep 2004 22:40:59 -0400, "rob" <rwc1960@.bellsouth.net>
wrote:
>There are 2 SQL databases involved and an MS Access program... also using
>windows authentication...
>The Ms Access program executes a stored procedure that resides in SQL
>database#1, the stored procedure updates data in SQL dataabase#2..
>Assume the user has rights to execute the stored procedure in database#1,
>how can you best limit the rights of the user to database#2, but still allow
>them to execute the stored procedure in database#1 that updates the data in
>database#2 ?
>
>
Permissions and ODBC
There are 2 SQL databases involved and an MS Access program... also using
windows authentication...
The Ms Access program executes a stored procedure that resides in SQL
database#1, the stored procedure updates data in SQL dataabase#2..
Assume the user has rights to execute the stored procedure in database#1.
How can you best limit the rights of the user to database#2, but still allow
them to execute the stored procedure in database#1 that updates the data in
database#2 ?
Permissions on indirectly referenced objects are not needed as long as the
objects have the same owner (i.e. owner maps to the same login). In the
case of dbo-owned objects in different databases, the databases need to have
the same owner so that the dbo user maps to the same login. You can change
database owners using sp_changedbowner, if needed. Also, cross-database
ownership chaining is a configurable option in SQL 2000 SP3 and needs to be
enabled in both databases. You can enable this using sp_dboption:
EXEC sp_dboption 'Database1', 'db chaining', true
EXEC sp_dboption 'Database2', 'db chaining', true
The main security consideration with cross-database chaining is that you
should enable the option only if you trust users with object CREATE
permissions in those databases. See the SQL 2003 SP3 Books Online for more
info.
Hope this helps.
Dan Guzman
SQL Server MVP
"rob" <rwc1960@.bellsouth.net> wrote in message
news:MYW0d.113845$0o5.105823@.bignews1.bellsouth.ne t...
> There are 2 SQL databases involved and an MS Access program... also using
> windows authentication...
> The Ms Access program executes a stored procedure that resides in SQL
> database#1, the stored procedure updates data in SQL dataabase#2..
> Assume the user has rights to execute the stored procedure in database#1.
> How can you best limit the rights of the user to database#2, but still
> allow
> them to execute the stored procedure in database#1 that updates the data
> in
> database#2 ?
>
>
>
windows authentication...
The Ms Access program executes a stored procedure that resides in SQL
database#1, the stored procedure updates data in SQL dataabase#2..
Assume the user has rights to execute the stored procedure in database#1.
How can you best limit the rights of the user to database#2, but still allow
them to execute the stored procedure in database#1 that updates the data in
database#2 ?
Permissions on indirectly referenced objects are not needed as long as the
objects have the same owner (i.e. owner maps to the same login). In the
case of dbo-owned objects in different databases, the databases need to have
the same owner so that the dbo user maps to the same login. You can change
database owners using sp_changedbowner, if needed. Also, cross-database
ownership chaining is a configurable option in SQL 2000 SP3 and needs to be
enabled in both databases. You can enable this using sp_dboption:
EXEC sp_dboption 'Database1', 'db chaining', true
EXEC sp_dboption 'Database2', 'db chaining', true
The main security consideration with cross-database chaining is that you
should enable the option only if you trust users with object CREATE
permissions in those databases. See the SQL 2003 SP3 Books Online for more
info.
Hope this helps.
Dan Guzman
SQL Server MVP
"rob" <rwc1960@.bellsouth.net> wrote in message
news:MYW0d.113845$0o5.105823@.bignews1.bellsouth.ne t...
> There are 2 SQL databases involved and an MS Access program... also using
> windows authentication...
> The Ms Access program executes a stored procedure that resides in SQL
> database#1, the stored procedure updates data in SQL dataabase#2..
> Assume the user has rights to execute the stored procedure in database#1.
> How can you best limit the rights of the user to database#2, but still
> allow
> them to execute the stored procedure in database#1 that updates the data
> in
> database#2 ?
>
>
>
Permissions
Does anyone know where the actual code for a stored procedure is stored at? Is it in a system table?your_database.syscomments - ctext field
Originally posted by justastef
Does anyone know where the actual code for a stored procedure is stored at? Is it in a system table?|||Looking in the syscolumns table, I noticed that all of my procedures only have the first part and the last part located in it if they are long. The middle is missing... is this due to the column being only 8000 characters long at a time so its missing a chunk... If this is the case, how can I extract the entire contents of the code of a stored procedure (not through a tool just through t-sql)... is there a command to extract this information?
I also noticed that I named the subject Permissions when I should have typed procedures... lol where is my head today.|||You're right. For each 8000 characters SQL inserts one row in syscomments table, so if you want to extract the text, you'll need to use a cursor and put the text somewhere in a flat file for instance.
I'm not aware of any T-SQL command to extract that info automatically.
Originally posted by justastef
Looking in the syscolumns table, I noticed that all of my procedures only have the first part and the last part located in it if they are long. The middle is missing... is this due to the column being only 8000 characters long at a time so its missing a chunk... If this is the case, how can I extract the entire contents of the code of a stored procedure (not through a tool just through t-sql)... is there a command to extract this information?
I also noticed that I named the subject Permissions when I should have typed procedures... lol where is my head today.
Originally posted by justastef
Does anyone know where the actual code for a stored procedure is stored at? Is it in a system table?|||Looking in the syscolumns table, I noticed that all of my procedures only have the first part and the last part located in it if they are long. The middle is missing... is this due to the column being only 8000 characters long at a time so its missing a chunk... If this is the case, how can I extract the entire contents of the code of a stored procedure (not through a tool just through t-sql)... is there a command to extract this information?
I also noticed that I named the subject Permissions when I should have typed procedures... lol where is my head today.|||You're right. For each 8000 characters SQL inserts one row in syscomments table, so if you want to extract the text, you'll need to use a cursor and put the text somewhere in a flat file for instance.
I'm not aware of any T-SQL command to extract that info automatically.
Originally posted by justastef
Looking in the syscolumns table, I noticed that all of my procedures only have the first part and the last part located in it if they are long. The middle is missing... is this due to the column being only 8000 characters long at a time so its missing a chunk... If this is the case, how can I extract the entire contents of the code of a stored procedure (not through a tool just through t-sql)... is there a command to extract this information?
I also noticed that I named the subject Permissions when I should have typed procedures... lol where is my head today.
Friday, March 9, 2012
permissions
Hi All,
how I can setup a role, so that they can only create, drop stored procedure,
views and functions. and can't create triggers, tables or modify schema.
Tim
grant create procedure, create view, create function to <login>
----
Need SQL Server Examples check out my website at
http://www.geocities.com/sqlserverexamples
"t" <t@.t.t> wrote in message news:ehIWCmpaEHA.4048@.TK2MSFTNGP10.phx.gbl...
> Hi All,
> how I can setup a role, so that they can only create, drop stored
procedure,
> views and functions. and can't create triggers, tables or modify schema.
>
> Tim
>
>
how I can setup a role, so that they can only create, drop stored procedure,
views and functions. and can't create triggers, tables or modify schema.
Tim
grant create procedure, create view, create function to <login>
----
Need SQL Server Examples check out my website at
http://www.geocities.com/sqlserverexamples
"t" <t@.t.t> wrote in message news:ehIWCmpaEHA.4048@.TK2MSFTNGP10.phx.gbl...
> Hi All,
> how I can setup a role, so that they can only create, drop stored
procedure,
> views and functions. and can't create triggers, tables or modify schema.
>
> Tim
>
>
permissions
Hi All,
how I can setup a role, so that they can only create, drop stored procedure,
views and functions. and can't create triggers, tables or modify schema.
Tim
Hi,
You can only assign CREATE PROC, CREATE FUNCTION, CREATE VIEW to a
USER/ROLE. The DROP
permissons for any of this objects is not grantable.
Thanks
Hari
MCDBA
"t" <t@.t.t> wrote in message news:eXYPwlpaEHA.384@.TK2MSFTNGP10.phx.gbl...
> Hi All,
> how I can setup a role, so that they can only create, drop stored
procedure,
> views and functions. and can't create triggers, tables or modify schema.
>
> Tim
>
>
how I can setup a role, so that they can only create, drop stored procedure,
views and functions. and can't create triggers, tables or modify schema.
Tim
Hi,
You can only assign CREATE PROC, CREATE FUNCTION, CREATE VIEW to a
USER/ROLE. The DROP
permissons for any of this objects is not grantable.
Thanks
Hari
MCDBA
"t" <t@.t.t> wrote in message news:eXYPwlpaEHA.384@.TK2MSFTNGP10.phx.gbl...
> Hi All,
> how I can setup a role, so that they can only create, drop stored
procedure,
> views and functions. and can't create triggers, tables or modify schema.
>
> Tim
>
>
permissions
Hi All,
how I can setup a role, so that they can only create, drop stored procedure,
views and functions. and can't create triggers, tables or modify schema.
Timgrant create procedure, create view, create function to <login>
----
----
--
Need SQL Server Examples check out my website at
http://www.geocities.com/sqlserverexamples
"t" <t@.t.t> wrote in message news:ehIWCmpaEHA.4048@.TK2MSFTNGP10.phx.gbl...
> Hi All,
> how I can setup a role, so that they can only create, drop stored
procedure,
> views and functions. and can't create triggers, tables or modify schema.
>
> Tim
>
>
how I can setup a role, so that they can only create, drop stored procedure,
views and functions. and can't create triggers, tables or modify schema.
Timgrant create procedure, create view, create function to <login>
----
----
--
Need SQL Server Examples check out my website at
http://www.geocities.com/sqlserverexamples
"t" <t@.t.t> wrote in message news:ehIWCmpaEHA.4048@.TK2MSFTNGP10.phx.gbl...
> Hi All,
> how I can setup a role, so that they can only create, drop stored
procedure,
> views and functions. and can't create triggers, tables or modify schema.
>
> Tim
>
>
permissions
Hi All,
how I can setup a role, so that they can only create, drop stored procedure,
views and functions. and can't create triggers, tables or modify schema.
Timgrant create procedure, create view, create function to <login>
----
----
--
Need SQL Server Examples check out my website at
http://www.geocities.com/sqlserverexamples
"t" <t@.t.t> wrote in message news:ehIWCmpaEHA.4048@.TK2MSFTNGP10.phx.gbl...
> Hi All,
> how I can setup a role, so that they can only create, drop stored
procedure,
> views and functions. and can't create triggers, tables or modify schema.
>
> Tim
>
>
how I can setup a role, so that they can only create, drop stored procedure,
views and functions. and can't create triggers, tables or modify schema.
Timgrant create procedure, create view, create function to <login>
----
----
--
Need SQL Server Examples check out my website at
http://www.geocities.com/sqlserverexamples
"t" <t@.t.t> wrote in message news:ehIWCmpaEHA.4048@.TK2MSFTNGP10.phx.gbl...
> Hi All,
> how I can setup a role, so that they can only create, drop stored
procedure,
> views and functions. and can't create triggers, tables or modify schema.
>
> Tim
>
>
Subscribe to:
Posts (Atom)