permissions problems creating a linked server

I am trying to create a linked server in the management studio and am getting an error

"A required operation could not be completed. You must be a member of the sysadmin role to perform this operation"

I have tried giving the user rights via

GRANT ALTER ANY LINKED SERVER TO [DOM\user]

as well as adding them to the setupadmin group. No luck.

I can add the linked server via sp_addlinkedserver as the user.

Any ideas?After searching some more I came across this.

http://msdn2.microsoft.com/en-us/library/aa560998.aspx

Which states you must be a member of the sysadmin role to create a linked server to do this via the management tools. Any idea why?

When I script the GUI all of the SP's it calls are available to logins with the setupadmin role or who have been granted access to alter any linked server.

Permissions needed to Create Assembly

Hi,
I am having difficulties in creating an assembly in a user database.
I am using an SQL login that is a db_owner of a database. The assembly has
PERMISSION_SET = EXTERNAL_ACCESS.
The first attempt gave these 2 messages:-
Error 1: Msg 6585, Level 16, State 1, Line 2
Could not impersonate the client during assembly file operation.
Error 2: Msg 300, Level 14, State 1, Line 2
EXTERNAL ACCESS ASSEMBLY permission denied on object 'server', database
'master'.
I then gave External Access Assemblies permission. This took away the 2nd
message but not the
Error 1: Msg 6585, Level 16, State 1, Line 2
Does the SQL Login have to be a sysadmin to do this?
Thanks
Chris
Hello Chris,
In a word, yes. You also need the right rights to read the DLL from the source
location (eg, a DACL for the account that windows is running under IIRC).
If you didn't ALTER DATABASE with SET TRUSTWORTHY on, you'll need to do the
"Safety Dance" too. See [0] for more information on that.
[0]: http://www.sqljunkies.com/WebLog/kte...ssemblies.aspx
Thank you,
Kent Tegels
DevelopMentor
http://staff.develop.com/ktegels/
|||Kent,
I forgot to mention that I did alter the user db to set TRUSTWORTHY ON. I
still get the 1st message
Msg 6585, Level 16, State 1, Line 2
Could not impersonate the client during assembly file operation.
BOL talks a lot about the Windows Account. Does this message mean Windows
permissions to the actual DLL?
Chris
"Kent Tegels" <ktegels@.develop.com> wrote in message
news:b87ad74140e08c80fe968b1a9f0@.news.microsoft.co m...
> Hello Chris,
> In a word, yes. You also need the right rights to read the DLL from the
> source location (eg, a DACL for the account that windows is running under
> IIRC).
> If you didn't ALTER DATABASE with SET TRUSTWORTHY on, you'll need to do
> the "Safety Dance" too. See [0] for more information on that.
> [0]:
> http://www.sqljunkies.com/WebLog/kte...ssemblies.aspx
> Thank you,
> Kent Tegels
> DevelopMentor
> http://staff.develop.com/ktegels/
>
|||Hello Chris,

> Msg 6585, Level 16, State 1, Line 2
> Could not impersonate the client during assembly file operation.
> BOL talks a lot about the Windows Account. Does this message mean
> Windows permissions to the actual DLL?
Yes, that's what that means.
Thank you,
Kent Tegels
DevelopMentor
http://staff.develop.com/ktegels/
|||Kent,
I have the DLL on my workstation. Do I need to have the DLL on the server
and have the authority on the server?
Thanks
Chris
"Kent Tegels" <ktegels@.develop.com> wrote in message
news:b87ad74142918c80ff76b247aa0@.news.microsoft.co m...
> Hello Chris,
>
> Yes, that's what that means.
> Thank you,
> Kent Tegels
> DevelopMentor
> http://staff.develop.com/ktegels/
>
|||Hello Chris,

> I have the DLL on my workstation. Do I need to have the DLL on the
> server and have the authority on the server?
Well, what you need to have is a way for you to read that file from your
client from the server. I'm guessing at the moment that there's probably
a firewall between you and the server, right? Or can you simply not logon
that Windows Server on which the SQL Server instance is running?
Is there a particular reason you're not using Visual Studio to deploy here?
The reason that I ask is that it issues the create assembly command with
a binary serialization of the assembly, so there's no reason to "read the
file" from your machine. You can see it doing this with SQL profiler.
If nothing else, deploy the assembly to a local SQL Server, then use management
studio to script the assembly out to .SQL file. You could then run that file
on the remote server since the script will have the assembly inline as a
byte stream.
Thank you,
Kent Tegels
DevelopMentor
http://staff.develop.com/ktegels/

Permissions needed to Create Assembly

Hi,
I am having difficulties in creating an assembly in a user database.
I am using an SQL login that is a db_owner of a database. The assembly has
PERMISSION_SET = EXTERNAL_ACCESS.
The first attempt gave these 2 messages:-
Error 1: Msg 6585, Level 16, State 1, Line 2
Could not impersonate the client during assembly file operation.
Error 2: Msg 300, Level 14, State 1, Line 2
EXTERNAL ACCESS ASSEMBLY permission denied on object 'server', database
'master'.
I then gave External Access Assemblies permission. This took away the 2nd
message but not the
Error 1: Msg 6585, Level 16, State 1, Line 2
Does the SQL Login have to be a sysadmin to do this?
Thanks
ChrisHello Chris,
In a word, yes. You also need the right rights to read the DLL from the sour
ce
location (eg, a DACL for the account that windows is running under IIRC).
If you didn't ALTER DATABASE with SET TRUSTWORTHY on, you'll need to do the
"Safety Dance" too. See [0] for more information on that.
[0]: http://www.sqljunkies.com/WebLog/kt...es
.aspx
Thank you,
Kent Tegels
DevelopMentor
http://staff.develop.com/ktegels/|||Kent,
I forgot to mention that I did alter the user db to set TRUSTWORTHY ON. I
still get the 1st message
Msg 6585, Level 16, State 1, Line 2
Could not impersonate the client during assembly file operation.
BOL talks a lot about the Windows Account. Does this message mean Windows
permissions to the actual DLL?
Chris
"Kent Tegels" <ktegels@.develop.com> wrote in message
news:b87ad74140e08c80fe968b1a9f0@.news.microsoft.com...
> Hello Chris,
> In a word, yes. You also need the right rights to read the DLL from the
> source location (eg, a DACL for the account that windows is running under
> IIRC).
> If you didn't ALTER DATABASE with SET TRUSTWORTHY on, you'll need to do
> the "Safety Dance" too. See [0] for more information on that.
> [0]:
> http://www.sqljunkies.com/WebLog/kt...op.com/ktegels/
>|||Hello Chris,

> Msg 6585, Level 16, State 1, Line 2
> Could not impersonate the client during assembly file operation.
> BOL talks a lot about the Windows Account. Does this message mean
> Windows permissions to the actual DLL?
Yes, that's what that means.
Thank you,
Kent Tegels
DevelopMentor
http://staff.develop.com/ktegels/|||Kent,
I have the DLL on my workstation. Do I need to have the DLL on the server
and have the authority on the server?
Thanks
Chris
"Kent Tegels" <ktegels@.develop.com> wrote in message
news:b87ad74142918c80ff76b247aa0@.news.microsoft.com...
> Hello Chris,
>
> Yes, that's what that means.
> Thank you,
> Kent Tegels
> DevelopMentor
> http://staff.develop.com/ktegels/
>|||Hello Chris,

> I have the DLL on my workstation. Do I need to have the DLL on the
> server and have the authority on the server?
Well, what you need to have is a way for you to read that file from your
client from the server. I'm guessing at the moment that there's probably
a firewall between you and the server, right? Or can you simply not logon
that Windows Server on which the SQL Server instance is running?
Is there a particular reason you're not using Visual Studio to deploy here?
The reason that I ask is that it issues the create assembly command with
a binary serialization of the assembly, so there's no reason to "read the
file" from your machine. You can see it doing this with SQL profiler.
If nothing else, deploy the assembly to a local SQL Server, then use managem
ent
studio to script the assembly out to .SQL file. You could then run that file
on the remote server since the script will have the assembly inline as a
byte stream.
Thank you,
Kent Tegels
DevelopMentor
http://staff.develop.com/ktegels/

Permissions needed to Create Assembly

Hi,
I am having difficulties in creating an assembly in a user database.
I am using an SQL login that is a db_owner of a database. The assembly has
PERMISSION_SET = EXTERNAL_ACCESS.
The first attempt gave these 2 messages:-
Error 1: Msg 6585, Level 16, State 1, Line 2
Could not impersonate the client during assembly file operation.
Error 2: Msg 300, Level 14, State 1, Line 2
EXTERNAL ACCESS ASSEMBLY permission denied on object 'server', database
'master'.
I then gave External Access Assemblies permission. This took away the 2nd
message but not the
Error 1: Msg 6585, Level 16, State 1, Line 2
Does the SQL Login have to be a sysadmin to do this?
Thanks
Chris
Hello Chris,
In a word, yes. You also need the right rights to read the DLL from the source
location (eg, a DACL for the account that windows is running under IIRC).
If you didn't ALTER DATABASE with SET TRUSTWORTHY on, you'll need to do the
"Safety Dance" too. See [0] for more information on that.
[0]: http://www.sqljunkies.com/WebLog/kte...ssemblies.aspx
Thank you,
Kent Tegels
DevelopMentor
http://staff.develop.com/ktegels/
|||Kent,
I forgot to mention that I did alter the user db to set TRUSTWORTHY ON. I
still get the 1st message
Msg 6585, Level 16, State 1, Line 2
Could not impersonate the client during assembly file operation.
BOL talks a lot about the Windows Account. Does this message mean Windows
permissions to the actual DLL?
Chris
"Kent Tegels" <ktegels@.develop.com> wrote in message
news:b87ad74140e08c80fe968b1a9f0@.news.microsoft.co m...
> Hello Chris,
> In a word, yes. You also need the right rights to read the DLL from the
> source location (eg, a DACL for the account that windows is running under
> IIRC).
> If you didn't ALTER DATABASE with SET TRUSTWORTHY on, you'll need to do
> the "Safety Dance" too. See [0] for more information on that.
> [0]:
> http://www.sqljunkies.com/WebLog/kte...ssemblies.aspx
> Thank you,
> Kent Tegels
> DevelopMentor
> http://staff.develop.com/ktegels/
>
|||Hello Chris,

> Msg 6585, Level 16, State 1, Line 2
> Could not impersonate the client during assembly file operation.
> BOL talks a lot about the Windows Account. Does this message mean
> Windows permissions to the actual DLL?
Yes, that's what that means.
Thank you,
Kent Tegels
DevelopMentor
http://staff.develop.com/ktegels/
|||Kent,
I have the DLL on my workstation. Do I need to have the DLL on the server
and have the authority on the server?
Thanks
Chris
"Kent Tegels" <ktegels@.develop.com> wrote in message
news:b87ad74142918c80ff76b247aa0@.news.microsoft.co m...
> Hello Chris,
>
> Yes, that's what that means.
> Thank you,
> Kent Tegels
> DevelopMentor
> http://staff.develop.com/ktegels/
>
|||Hello Chris,

> I have the DLL on my workstation. Do I need to have the DLL on the
> server and have the authority on the server?
Well, what you need to have is a way for you to read that file from your
client from the server. I'm guessing at the moment that there's probably
a firewall between you and the server, right? Or can you simply not logon
that Windows Server on which the SQL Server instance is running?
Is there a particular reason you're not using Visual Studio to deploy here?
The reason that I ask is that it issues the create assembly command with
a binary serialization of the assembly, so there's no reason to "read the
file" from your machine. You can see it doing this with SQL profiler.
If nothing else, deploy the assembly to a local SQL Server, then use management
studio to script the assembly out to .SQL file. You could then run that file
on the remote server since the script will have the assembly inline as a
byte stream.
Thank you,
Kent Tegels
DevelopMentor
http://staff.develop.com/ktegels/

Permissions needed to Create Assembly

Hi,
I am having difficulties in creating an assembly in a user database.
I am using an SQL login that is a db_owner of a database. The assembly has
PERMISSION_SET = EXTERNAL_ACCESS.
The first attempt gave these 2 messages:-
Error 1: Msg 6585, Level 16, State 1, Line 2
Could not impersonate the client during assembly file operation.
Error 2: Msg 300, Level 14, State 1, Line 2
EXTERNAL ACCESS ASSEMBLY permission denied on object 'server', database
'master'.
I then gave External Access Assemblies permission. This took away the 2nd
message but not the
Error 1: Msg 6585, Level 16, State 1, Line 2
Does the SQL Login have to be a sysadmin to do this?
Thanks
ChrisHello Chris,
In a word, yes. You also need the right rights to read the DLL from the source
location (eg, a DACL for the account that windows is running under IIRC).
If you didn't ALTER DATABASE with SET TRUSTWORTHY on, you'll need to do the
"Safety Dance" too. See [0] for more information on that.
[0]: http://www.sqljunkies.com/WebLog/ktegels/articles/SigningSQLCLRAssemblies.aspx
Thank you,
Kent Tegels
DevelopMentor
http://staff.develop.com/ktegels/|||Kent,
I forgot to mention that I did alter the user db to set TRUSTWORTHY ON. I
still get the 1st message
Msg 6585, Level 16, State 1, Line 2
Could not impersonate the client during assembly file operation.
BOL talks a lot about the Windows Account. Does this message mean Windows
permissions to the actual DLL?
Chris
"Kent Tegels" <ktegels@.develop.com> wrote in message
news:b87ad74140e08c80fe968b1a9f0@.news.microsoft.com...
> Hello Chris,
> In a word, yes. You also need the right rights to read the DLL from the
> source location (eg, a DACL for the account that windows is running under
> IIRC).
> If you didn't ALTER DATABASE with SET TRUSTWORTHY on, you'll need to do
> the "Safety Dance" too. See [0] for more information on that.
> [0]:
> http://www.sqljunkies.com/WebLog/ktegels/articles/SigningSQLCLRAssemblies.aspx
> Thank you,
> Kent Tegels
> DevelopMentor
> http://staff.develop.com/ktegels/
>

Permissions granted from Domain credentials

I am working with Visual Studio.net and creating a front end for a SQL datab
ase. Now with the access front end, it uses the domain credentials of the l
ogged in user to determine what permissions they have for editing records in
the SQL (2000) database.
I need the same to be done with the web front end I am creating now. I have
gone into the WEB.CONFIG file and put in my credentials there, identity i
mpersonate="true" userName="domain\johndoe" password="password"
Now this is ok if...I didn't change my password regularly and I wanted every
one to have full access...but obviously I don't. Is there some syntax that
I need there so that it will use the credentials of the logged in user? Or a
m I in the wrong file and s
hould be making changes elsewhere? I am new to this but I am learning. In
the OleDB connection for the datagrid on the page, I have added the line...
Trusted Connection=SSPI. What am I missing? I am using OleDb connection a
nd OleDb Command. Like I s
aid...with my credential in the web.config, it works fine. But that is only
good for now. I need the security set so when I get to creating a page tha
t only administrators have access to I can get those to work correctly.
Thanks All!!I am assuming that with the Trusted Connection = SSPI the connection is
failing. If so, what error message do you get when it fails?
Rand
This posting is provided "as is" with no warranties and confers no rights.|||You need to allow Kerberos Authentication to occur. The middle machine
must be trusted for Security Delegation. Also , the SQL Server service
account needs to have the Service Principal Name set.
Thanks,
Kevin McDonnell
Microsoft Corporation
This posting is provided AS IS with no warranties, and confers no rights.

Permissions for tables and Sprocs

Hi everyone,
We are creating a new application in .net and i would like to deny
access of the tables to users, but allow them to perform routines by
stored procedures. I am using Sql2005, and was wondering if anyone had
some knowlegde about this and point me in the right direction? Has
anyone set this up before?
ThanksThis is standard practice. As long as you don't use dynamic SQL in the proce
dures and the procedure
and table has the same owner, then the user only need permissions to the pro
cedures. See
http://www.sommarskog.se/grantperm.html for some elaboration.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Nemisis" <darrens2005@.hotmail.com> wrote in message
news:1166175982.773661.294100@.73g2000cwn.googlegroups.com...
> Hi everyone,
> We are creating a new application in .net and i would like to deny
> access of the tables to users, but allow them to perform routines by
> stored procedures. I am using Sql2005, and was wondering if anyone had
> some knowlegde about this and point me in the right direction? Has
> anyone set this up before?
> Thanks
>|||Tibor Karaszi wrote:
> This is standard practice. As long as you don't use dynamic SQL in the pro
cedures and the procedure
> and table has the same owner, then the user only need permissions to the p
rocedures. See
> http://www.sommarskog.se/grantperm.html for some elaboration.
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://www.solidqualitylearning.com/
>
Tibor,
Thanks for the quick reply, and i will look at the link you sent. One
problem though, we do use dynamic Sql within some of the sprocs, using
the execute_sql sproc?
Can you explain why this makes a difference?|||> Can you explain why this makes a difference?
that is just the way it is. SQL Server doesn't know what string you are abou
t to execute, so it
cannot allow the user of the proc to "execute just anything" without permiss
ion checking. I.e., a
conscious design decision. See the article, Erland mentions tow ways in 2005
to handle this
(signature and certificate or EXECUTE AS).
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Nemisis" <darrens2005@.hotmail.com> wrote in message
news:1166180348.976164.146510@.16g2000cwy.googlegroups.com...
> Tibor Karaszi wrote:
> Tibor,
> Thanks for the quick reply, and i will look at the link you sent. One
> problem though, we do use dynamic Sql within some of the sprocs, using
> the execute_sql sproc?
> Can you explain why this makes a difference?
>|||Tibor,
I have read a couple articles now and feel that Execute As seems to be
the easiest option for the moment, and talks about setting up another
user to execute the code as. With this in mind, some articles say
about assigning this new user to a Role in the database, and th Role is
actually what is assigned the permissions. Do you agree with this?
Also, when they say role, do they mean a database role, or application
role? I am not sure i am understanding the differences between the
two, or why one should be used rather then the other.
Thanks again for all your help so far|||Database roles are containers for database users and other roles. Roles are
commonly used for security because you can grant permissions to the role
once and then control security for individual users using role membership.
Application roles are different beasts. An app role is a database security
context that can be activated in application code using sp_setapprole. Once
activated, it remains in effect until the connection is closed or
sp_unsetapprole is activated. App roles provide a means to elevate
permissions while a user is using an application and prevent direct ad-hoc
database access.
Regarding procedure permissions, like Tibor suggested, normal ownership
chaining works well except when you execute SQL dynamically or need to run
statements that require more permissions. In those cases, you can specify
an alternate security context using certificates or EXECUTE AS. You can
peruse Erland's article for details.
Hope this helps.
Dan Guzman
SQL Server MVP
"Nemisis" <darrens2005@.hotmail.com> wrote in message
news:1166184171.866934.154250@.80g2000cwy.googlegroups.com...
> Tibor,
> I have read a couple articles now and feel that Execute As seems to be
> the easiest option for the moment, and talks about setting up another
> user to execute the code as. With this in mind, some articles say
> about assigning this new user to a Role in the database, and th Role is
> actually what is assigned the permissions. Do you agree with this?
> Also, when they say role, do they mean a database role, or application
> role? I am not sure i am understanding the differences between the
> two, or why one should be used rather then the other.
> Thanks again for all your help so far
>

Permissions for tables and Sprocs

Hi everyone,
We are creating a new application in .net and i would like to deny
access of the tables to users, but allow them to perform routines by
stored procedures. I am using Sql2005, and was wondering if anyone had
some knowlegde about this and point me in the right direction? Has
anyone set this up before?
ThanksThis is standard practice. As long as you don't use dynamic SQL in the procedures and the procedure
and table has the same owner, then the user only need permissions to the procedures. See
http://www.sommarskog.se/grantperm.html for some elaboration.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Nemisis" <darrens2005@.hotmail.com> wrote in message
news:1166175982.773661.294100@.73g2000cwn.googlegroups.com...
> Hi everyone,
> We are creating a new application in .net and i would like to deny
> access of the tables to users, but allow them to perform routines by
> stored procedures. I am using Sql2005, and was wondering if anyone had
> some knowlegde about this and point me in the right direction? Has
> anyone set this up before?
> Thanks
>|||Tibor Karaszi wrote:
> This is standard practice. As long as you don't use dynamic SQL in the procedures and the procedure
> and table has the same owner, then the user only need permissions to the procedures. See
> http://www.sommarskog.se/grantperm.html for some elaboration.
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://www.solidqualitylearning.com/
>
Tibor,
Thanks for the quick reply, and i will look at the link you sent. One
problem though, we do use dynamic Sql within some of the sprocs, using
the execute_sql sproc?
Can you explain why this makes a difference?|||> Can you explain why this makes a difference?
that is just the way it is. SQL Server doesn't know what string you are about to execute, so it
cannot allow the user of the proc to "execute just anything" without permission checking. I.e., a
conscious design decision. See the article, Erland mentions tow ways in 2005 to handle this
(signature and certificate or EXECUTE AS).
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Nemisis" <darrens2005@.hotmail.com> wrote in message
news:1166180348.976164.146510@.16g2000cwy.googlegroups.com...
> Tibor Karaszi wrote:
>> This is standard practice. As long as you don't use dynamic SQL in the procedures and the
>> procedure
>> and table has the same owner, then the user only need permissions to the procedures. See
>> http://www.sommarskog.se/grantperm.html for some elaboration.
>> --
>> Tibor Karaszi, SQL Server MVP
>> http://www.karaszi.com/sqlserver/default.asp
>> http://www.solidqualitylearning.com/
> Tibor,
> Thanks for the quick reply, and i will look at the link you sent. One
> problem though, we do use dynamic Sql within some of the sprocs, using
> the execute_sql sproc?
> Can you explain why this makes a difference?
>|||Tibor,
I have read a couple articles now and feel that Execute As seems to be
the easiest option for the moment, and talks about setting up another
user to execute the code as. With this in mind, some articles say
about assigning this new user to a Role in the database, and th Role is
actually what is assigned the permissions. Do you agree with this?
Also, when they say role, do they mean a database role, or application
role? I am not sure i am understanding the differences between the
two, or why one should be used rather then the other.
Thanks again for all your help so far|||Database roles are containers for database users and other roles. Roles are
commonly used for security because you can grant permissions to the role
once and then control security for individual users using role membership.
Application roles are different beasts. An app role is a database security
context that can be activated in application code using sp_setapprole. Once
activated, it remains in effect until the connection is closed or
sp_unsetapprole is activated. App roles provide a means to elevate
permissions while a user is using an application and prevent direct ad-hoc
database access.
Regarding procedure permissions, like Tibor suggested, normal ownership
chaining works well except when you execute SQL dynamically or need to run
statements that require more permissions. In those cases, you can specify
an alternate security context using certificates or EXECUTE AS. You can
peruse Erland's article for details.
--
Hope this helps.
Dan Guzman
SQL Server MVP
"Nemisis" <darrens2005@.hotmail.com> wrote in message
news:1166184171.866934.154250@.80g2000cwy.googlegroups.com...
> Tibor,
> I have read a couple articles now and feel that Execute As seems to be
> the easiest option for the moment, and talks about setting up another
> user to execute the code as. With this in mind, some articles say
> about assigning this new user to a Role in the database, and th Role is
> actually what is assigned the permissions. Do you agree with this?
> Also, when they say role, do they mean a database role, or application
> role? I am not sure i am understanding the differences between the
> two, or why one should be used rather then the other.
> Thanks again for all your help so far
>

Permissions for creating views

In database permissions I have granted a user rights to create a view. When she tries to save the view (even save as) it automatically wants to save it to the dbo schema and says she does not have rights to save to the dbo schema.

Two questions:

1) Can I set it up to where she can save a view to a schema which she is the owner?

2) If not, then what permissions must be set to allow her to create / save views but not be able to create, etc. other objects such as tables and stored procedures?

From the description it seems like this is a question regarding tools (most likely Management studio).

I have moved the question to the appropriate forum, but if you have additional questions regarding the permissions please let us know.

Thanks,

-Raul Garcia

SDE/T

SQL Server Engine

|||Moved to Security|||

You will need to grant alter on the schema and create view on the database to the user who wants to create views.

T-SQL:

grant create view to user1

grant alter on schema:bo to user1

go

HTH,

-Steven Gott

SDE/T

SQL Server