Problem with setting variable values in a loop

In a stored procedure that I'm fixing, there is a problem with assigning variable values inside a loop. The proc is using dynamic SQL and if statements to build all these statements, but I'm having to add a new variable value to it that is throwing it out of whack.

This is the current structure:

SET @.MktNbr = 10

WHILE @.MktNbr < 90

BEGIN

DECLARE @.sqlstmt varchar(1000)

SET @.Market = '0' + CONVERT(char(2),@.MktNbr)

SET @.sqlstmt = ' SELECT (columns)
INTO dbo.table' + @.Market + '
FROM #table
WHERE marketcode = ''' + @.Market + '''
IF @.MktNbr = 50
BEGIN
SET @.MktNbr = 51
END
ELSE
IF @.MktNbr = 51
BEGIN
SET @.MktNbr = 52
END
ELSE
IF @.MktNbr = 52
BEGIN
SET @.MktNbr = 55
END
ELSE
IF @.MktNbr = 55
BEGIN
SET @.MktNbr = 60
END
ELSE
BEGIN
SET @.MktNbr = @.MktNbr + 10
END
EXEC (@.sqlstmt)

END

I'm probably having a blonde moment, but I'm trying to replace the if statements with this:

SET @.MktNbr =
CASE
WHEN @.MktNbr = 10 THEN 20
WHEN @.MktNbr = 20 THEN 30
WHEN @.MktNbr = 30 THEN 40
WHEN @.MktNbr = 40 THEN 50
WHEN @.MktNbr = 50 THEN 51
WHEN @.MktNbr = 51 THEN 52
WHEN @.MktNbr = 52 THEN 55
WHEN @.MktNbr = 55 THEN 60
WHEN @.MktNbr = 60 THEN 70
WHEN @.MktNbr = 70 THEN 80
WHEN @.MktNbr = 80 THEN 81
ELSE @.MktNbr END

Clearly it's wrong because the proc bombs every time with a duplicate table error.

It has been suggested to me that I should hold these market values in an external table. This sounds reasonable but I'm ashamed to admit that I don't know how I'd implement that. Can someone maybe give me a nudge in the right direction?That works fine for me:

DECLARE @.MktNbr int

SET @.MktNbr = 30

SET @.MktNbr =
CASE
WHEN @.MktNbr = 10 THEN 20
WHEN @.MktNbr = 20 THEN 30
WHEN @.MktNbr = 30 THEN 40
WHEN @.MktNbr = 40 THEN 50
WHEN @.MktNbr = 50 THEN 51
WHEN @.MktNbr = 51 THEN 52
WHEN @.MktNbr = 52 THEN 55
WHEN @.MktNbr = 55 THEN 60
WHEN @.MktNbr = 60 THEN 70
WHEN @.MktNbr = 70 THEN 80
WHEN @.MktNbr = 80 THEN 81
ELSE @.MktNbr END

PRINT @.MktNbr|||First...dynamic sql...ugh

Second, why are you setting @.market BEFORE you set @.mrktnmbr?

third, non logged creation of a table will fail the second time you need to do the insert

Can you explain, in business terms, what you are trying to accomplish, or what's been asked of you?|||Clearly it's wrong because the proc bombs every time with a duplicate table error.

Clearly

You can only execute it once per table creation.

Also, again, the assignmnet is out of whack

You will always be trying to create the same table, over and over, because the tablename is not being included in your "logic"|||Clearly it's wrong because the proc bombs every time with a duplicate table error.
My guess is that it fails on dbo.table081, right?

When @.MktNbr reaches 81, your case statement assigns it the new value of 81. The loop will try to make table081 again and fails.
You should set it to 90, so the loop will end.|||The answer is:
@.MktNbr never exceeds 81.|||the biggest wtf here is why are there so many market tables? why not just one?|||But as Brett (and now Rudy... Man I'm slow resonding to this thread) as highlighted above - the code is not good!
Even if you have a fix this is not the way for you to be doing this - explain what you're trying to achieve and hopefully we can prod you towards a better solution :)|||First...dynamic sql...ugh

Second, why are you setting @.market BEFORE you set @.mrktnmbr?

third, non logged creation of a table will fail the second time you need to do the insert

Can you explain, in business terms, what you are trying to accomplish, or what's been asked of you?

Fair points...allow me to address them in turn.

First: yes, dynamic SQL can be yucky but this is not something I developed, I am only making a modification to it. ;)

Second: See first point...I didn't write that, somebody else did. Somebody who no longer works here. :angel:

Third: I've had some ideas of things I'm going to try there so I'll get back to you on that. :)|||Second: See first point...I didn't write that, somebody else did. Somebody who no longer works here. :angel:

There's a reason for that|||Let me ask, do the tables get dropped before you hit this code?

How much data are we talking about?

Why not just hard code the 10 statements and not use dynamic sql?

Or, why not use 1 table and add a column for market code?

Really, all of this makes very little sense

So where did the person go? Burger King?|||There's a reason for that

Yep, there is. Thing is, the bossman doesn't want me to re-write the proc since it works...it's just slow. Right now the priority is just to make that amendment.

If you think that's good, there's some other ones that'd probably turn your hair white.|||Let me ask, do the tables get dropped before you hit this code?

How much data are we talking about?

Why not just hard code the 10 statements and not use dynamic sql?

Or, why not use 1 table and add a column for market code?

Really, all of this makes very little sense

So where did the person go? Burger King?

Don't fret, the person who suggested that I needed to set the variable to 90 was right; it works now. :cool:

Some of the procs do have hard-coded statements. Some of the developers here prefer the dynamic sql because they feel it's easier to maintain. I'm new here so I'm not in a position to tell them their code sucks, particularly since I'm the least experienced of the group. And yes, the tables get dropped; that's the first thing that happens in the proc. Right now we're not doing any design changes.|||that'd probably turn your hair white.

too late, the margarita's took care of that

And btw, what's "Too slow"

Instead of moving the data, why not just create views that are the name of the tables you are creating?

Oh, and if the smucks think your a jr. dba/developer, just keep coming here.

We'll smoke'em|||too late, the margarita's took care of that

And btw, what's "Too slow"

Instead of moving the data, why not just create views that are the name of the tables you are creating?

Oh, and if the smucks think your a jr. dba/developer, just keep coming here.

We'll smoke'em

This particular proc takes over an hour to execute.

Right now I'm testing one that has been executing for over four hours. It's obscene. :Ssql

Problem with setting up IIS - You are not authorized to view this page

I am trying to set up IIS on our server (Windows 2003 with SQL Server 2000) and when I try to run a query in a browser I keep getting the following messsage:-
You are not authorized to view this page
I have followed the tutorial (XMLStartup.doc) which was placed in C:\Program Files\Microsoft SQL Server\80\Tools\DevTools\Samples\xml\XMLStartup on installation, but still get the above message when I get to the point of querying the database.
Is there something I am doing wrong or is there some security measure I have not taken into account yet that is preventing me from runing queries?
any help appreciated - Thanks
The problem is probably not in SQL Server but in NTFS and IIS permissions. The IUSR_<server name> user or your local account user (if you are surfing from the server) must have NTFS permissions to read the page you are trying to access, both in IIS and NTFS. Check the NTFS security first and disable "simple file sharing" in WinExplorer if it's by any chance turned on and set the propper permissions on the files you are trying to access.

Problem with Setting a variable in SQL String

Hi,

I am having problems setting the value of a variable in a SQL String
that I have to create dynamically in my procedure. The code that I
currently have is as follows:

set @.sqlStatement='Set @.compare_string=' + '(Select ' +
@.group_column_list_mod + ' from ' + @.Tbl_Name + '_Sorted' + ' where
Identity_Column=' + ltrim(rtrim(str(@.loop_counter))) + ')'

exec(@.sqlStatement)

The error message that I get is as follows:

Must declare the variable '@.compare_string'.

Here @.compare_string has already been declared in the procedure and I
don't have a problem using the variable anywhere else but this SQL
Statement (when called using the EXEC function).

I am not sure why SQL Server can't see the variable declared when used
in a string in conjunction with EXEC. Is this a syntax issue? Any help
on this issue would be greatly appreciated!

Thanks in advance.You need a parms string and an exec string, like this:

SET @.Parms = `@.compare_string`

set @.sqlStatement='Set @.compare_string=' + '(Select ' +
@.group_column_list_mod + ' from ' + @.Tbl_Name + '_Sorted' + ' where
Identity_Column=' + ltrim(rtrim(str(@.loop_counter))) + ')'

EXECUTE sp_executesql @.sqlStatement, @.Parms, @.compare_string

SET @.Error = COALESCE ( NULLIF ( @.Error, 0 ), @.@.ERROR )

> exec(@.sqlStatement)
> The error message that I get is as follows:
> Must declare the variable '@.compare_string'.
> Here @.compare_string has already been declared in the procedure and I
> don't have a problem using the variable anywhere else but this SQL
> Statement (when called using the EXEC function).
> I am not sure why SQL Server can't see the variable declared when used
> in a string in conjunction with EXEC. Is this a syntax issue? Any help
> on this issue would be greatly appreciated!
> Thanks in advance.|||Thanks for your reply. The sp_executesql procedure still doesn't give
the desired results. I am posting the updated piece of code and sample
output from the Query Analyzer.

------
set @.parameter_String=N'@.compare_string nvarchar(4000)'

set @.sqlStatement='Set @.compare_string=(Select ' +
@.group_column_list_mod + ' from ' + @.Tbl_Name + '_Sorted' + ' where
Identity_Column=' + ltrim(rtrim(str(@.loop_counter))) + ')'

Print @.sqlStatement
EXECUTE sp_executesql @.sqlStatement,@.parameter_String,@.compare_string

Print @.compare_String
------

When I print the value of @.compare_String in the end its a NULL.
However, if I run the same query without the set @.compare_string
clause, it does work perfectly and returns the values of two columns
concatenated together. Any clues as to where I might be going wrong?

Thanks,

"Robin Tucker" <idontwanttobespammedanymore@.reallyidont.com> wrote in message news:<bs9mbk$jt0$1$8300dec7@.news.demon.co.uk>...
> You need a parms string and an exec string, like this:
> SET @.Parms = `@.compare_string`
> set @.sqlStatement='Set @.compare_string=' + '(Select ' +
> @.group_column_list_mod + ' from ' + @.Tbl_Name + '_Sorted' + ' where
> Identity_Column=' + ltrim(rtrim(str(@.loop_counter))) + ')'
> EXECUTE sp_executesql @.sqlStatement, @.Parms, @.compare_string
> SET @.Error = COALESCE ( NULLIF ( @.Error, 0 ), @.@.ERROR )
> > exec(@.sqlStatement)
> > The error message that I get is as follows:
> > Must declare the variable '@.compare_string'.
> > Here @.compare_string has already been declared in the procedure and I
> > don't have a problem using the variable anywhere else but this SQL
> > Statement (when called using the EXEC function).
> > I am not sure why SQL Server can't see the variable declared when used
> > in a string in conjunction with EXEC. Is this a syntax issue? Any help
> > on this issue would be greatly appreciated!
> > Thanks in advance.|||[posted and mailed, please reply in news]

Aamer Nazir (aamernazir_01@.hotmail.com) writes:
> I am having problems setting the value of a variable in a SQL String
> that I have to create dynamically in my procedure. The code that I
> currently have is as follows:
>
> set @.sqlStatement='Set @.compare_string=' + '(Select ' +
> @.group_column_list_mod + ' from ' + @.Tbl_Name + '_Sorted' + ' where
> Identity_Column=' + ltrim(rtrim(str(@.loop_counter))) + ')'
> exec(@.sqlStatement)
> The error message that I get is as follows:
> Must declare the variable '@.compare_string'.
> Here @.compare_string has already been declared in the procedure and I
> don't have a problem using the variable anywhere else but this SQL
> Statement (when called using the EXEC function).

The EXEC() statement is another scope which is not part of your procedure.
Thus, @.compare_string is not defined in that example.

For better examples than the one posted, see
http://support.microsoft.com/?id=262499 and
http://www.sommarskog.se/dynamic_sql.html#sp_executesql.

--
Erland Sommarskog, SQL Server MVP, sommar@.algonet.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techin.../2000/books.asp|||Yes, that won't work. Sorry, I just focused on the parameter part.

You can just do this:

select @.compare_string = mytable.myfield FROM mytable where Identity_Column
= myvalue

or, in your specific case:

'Select @.compare_string=' + @.group_column_list_mod + ' from ' + @.Tbl_Name +
'_Sorted' + ' where Identity_Column=' + ltrim(rtrim(str @.loop_counter))'

At least this is the syntax you should use in this case. Otherwise, you are
effectively trying to bind @.compare_string to a recordset result, which
doesn't work.

Make sure you add in the error checking afterwards!! :)

"Aamer Nazir" <aamernazir_01@.hotmail.com> wrote in message
news:60b6d0a1.0312231058.14540a2c@.posting.google.c om...
> Thanks for your reply. The sp_executesql procedure still doesn't give
> the desired results. I am posting the updated piece of code and sample
> output from the Query Analyzer.
>
> ------
> set @.parameter_String=N'@.compare_string nvarchar(4000)'
> set @.sqlStatement='Set @.compare_string=(Select ' +
> @.group_column_list_mod + ' from ' + @.Tbl_Name + '_Sorted' + ' where
> Identity_Column=' + ltrim(rtrim(str(@.loop_counter))) + ')'
> Print @.sqlStatement
> EXECUTE sp_executesql @.sqlStatement,@.parameter_String,@.compare_string
> Print @.compare_String
> ------
> When I print the value of @.compare_String in the end its a NULL.
> However, if I run the same query without the set @.compare_string
> clause, it does work perfectly and returns the values of two columns
> concatenated together. Any clues as to where I might be going wrong?
> Thanks,
>
> "Robin Tucker" <idontwanttobespammedanymore@.reallyidont.com> wrote in
message news:<bs9mbk$jt0$1$8300dec7@.news.demon.co.uk>...
> > You need a parms string and an exec string, like this:
> > SET @.Parms = `@.compare_string`
> > set @.sqlStatement='Set @.compare_string=' + '(Select ' +
> > @.group_column_list_mod + ' from ' + @.Tbl_Name + '_Sorted' + ' where
> > Identity_Column=' + ltrim(rtrim(str(@.loop_counter))) + ')'
> > EXECUTE sp_executesql @.sqlStatement, @.Parms, @.compare_string
> > SET @.Error = COALESCE ( NULLIF ( @.Error, 0 ), @.@.ERROR )
> > > > exec(@.sqlStatement)
> > > > The error message that I get is as follows:
> > > > Must declare the variable '@.compare_string'.
> > > > Here @.compare_string has already been declared in the procedure and I
> > > don't have a problem using the variable anywhere else but this SQL
> > > Statement (when called using the EXEC function).
> > > > I am not sure why SQL Server can't see the variable declared when used
> > > in a string in conjunction with EXEC. Is this a syntax issue? Any help
> > > on this issue would be greatly appreciated!
> > > > Thanks in advance.|||Thanks for pointing me to the right direction. The code works
perfectly fine now. The problem was with the syntax that Erland
Sommarskog mentioned in his posting. You have to specify the parameter
type (input or output) in the parameter specification string (the
second argument to sp_executesql).

Best Regards,

"Robin Tucker" <idontwanttobespammedanymore@.reallyidont.com> wrote in message news:<bsboku$o7p$1$8300dec7@.news.demon.co.uk>...
> Yes, that won't work. Sorry, I just focused on the parameter part.
> You can just do this:
> select @.compare_string = mytable.myfield FROM mytable where Identity_Column
> = myvalue
> or, in your specific case:
> 'Select @.compare_string=' + @.group_column_list_mod + ' from ' + @.Tbl_Name +
> '_Sorted' + ' where Identity_Column=' + ltrim(rtrim(str @.loop_counter))'
> At least this is the syntax you should use in this case. Otherwise, you are
> effectively trying to bind @.compare_string to a recordset result, which
> doesn't work.
> Make sure you add in the error checking afterwards!! :)
> "Aamer Nazir" <aamernazir_01@.hotmail.com> wrote in message
> news:60b6d0a1.0312231058.14540a2c@.posting.google.c om...
> > Thanks for your reply. The sp_executesql procedure still doesn't give
> > the desired results. I am posting the updated piece of code and sample
> > output from the Query Analyzer.
> > ------
> > set @.parameter_String=N'@.compare_string nvarchar(4000)'
> > set @.sqlStatement='Set @.compare_string=(Select ' +
> > @.group_column_list_mod + ' from ' + @.Tbl_Name + '_Sorted' + ' where
> > Identity_Column=' + ltrim(rtrim(str(@.loop_counter))) + ')'
> > Print @.sqlStatement
> > EXECUTE sp_executesql @.sqlStatement,@.parameter_String,@.compare_string
> > Print @.compare_String
> > ------
> > When I print the value of @.compare_String in the end its a NULL.
> > However, if I run the same query without the set @.compare_string
> > clause, it does work perfectly and returns the values of two columns
> > concatenated together. Any clues as to where I might be going wrong?
> > Thanks,
> > "Robin Tucker" <idontwanttobespammedanymore@.reallyidont.com> wrote in
> message news:<bs9mbk$jt0$1$8300dec7@.news.demon.co.uk>...
> > > You need a parms string and an exec string, like this:
> > > > SET @.Parms = `@.compare_string`
> > > > set @.sqlStatement='Set @.compare_string=' + '(Select ' +
> > > @.group_column_list_mod + ' from ' + @.Tbl_Name + '_Sorted' + ' where
> > > Identity_Column=' + ltrim(rtrim(str(@.loop_counter))) + ')'
> > > > EXECUTE sp_executesql @.sqlStatement, @.Parms, @.compare_string
> > > > SET @.Error = COALESCE ( NULLIF ( @.Error, 0 ), @.@.ERROR )
> > > > > > > exec(@.sqlStatement)
> > > > > > The error message that I get is as follows:
> > > > > > Must declare the variable '@.compare_string'.
> > > > > > Here @.compare_string has already been declared in the procedure and I
> > > > don't have a problem using the variable anywhere else but this SQL
> > > > Statement (when called using the EXEC function).
> > > > > > I am not sure why SQL Server can't see the variable declared when used
> > > > in a string in conjunction with EXEC. Is this a syntax issue? Any help
> > > > on this issue would be greatly appreciated!
> > > > > > Thanks in advance.

Problem with sending email

This is the first time I am setting up an operator so that I can get job
notifications to my email. When I create an operator any type in my address
and click test. It gives me the following error:
Problem occoured while attempting to resolve the address 'my email address'.
Mapi error code number -2147221233
Thanks
The first thing would be to check to ensure that SQL Mail has been setup
correctly as typically the MAPI errors occur as a result of an incorrect
configuration. The KB Article
http://support.microsoft.com/default...b;en-us;263556 describes how
to Configure SQL Mail and the KB article
http://support.microsoft.com/kb/315886/EN-US/ details Common SQL Mail
Problems.
- Peter Ward
WARDY IT Solutions
"Amit" wrote:

> This is the first time I am setting up an operator so that I can get job
> notifications to my email. When I create an operator any type in my address
> and click test. It gives me the following error:
> Problem occoured while attempting to resolve the address 'my email address'.
> Mapi error code number -2147221233
> Thanks

Problem with sending email

This is the first time I am setting up an operator so that I can get job
notifications to my email. When I create an operator any type in my address
and click test. It gives me the following error:
Problem occoured while attempting to resolve the address 'my email address'.
Mapi error code number -2147221233
ThanksThe first thing would be to check to ensure that SQL Mail has been setup
correctly as typically the MAPI errors occur as a result of an incorrect
configuration. The KB Article
http://support.microsoft.com/defaul...kb;en-us;263556 describes how
to Configure SQL Mail and the KB article
http://support.microsoft.com/kb/315886/EN-US/ details Common SQL Mail
Problems.
- Peter Ward
WARDY IT Solutions
"Amit" wrote:

> This is the first time I am setting up an operator so that I can get job
> notifications to my email. When I create an operator any type in my addres
s
> and click test. It gives me the following error:
> Problem occoured while attempting to resolve the address 'my email address
'.
> Mapi error code number -2147221233
> Thanks

Problem with sending email

This is the first time I am setting up an operator so that I can get job
notifications to my email. When I create an operator any type in my address
and click test. It gives me the following error:
Problem occoured while attempting to resolve the address 'my email address'.
Mapi error code number -2147221233
ThanksThe first thing would be to check to ensure that SQL Mail has been setup
correctly as typically the MAPI errors occur as a result of an incorrect
configuration. The KB Article
http://support.microsoft.com/default.aspx?scid=kb;en-us;263556 describes how
to Configure SQL Mail and the KB article
http://support.microsoft.com/kb/315886/EN-US/ details Common SQL Mail
Problems.
- Peter Ward
WARDY IT Solutions
"Amit" wrote:
> This is the first time I am setting up an operator so that I can get job
> notifications to my email. When I create an operator any type in my address
> and click test. It gives me the following error:
> Problem occoured while attempting to resolve the address 'my email address'.
> Mapi error code number -2147221233
> Thanks

Problem with role permissions

We are experiencing a problems setting permissions on roles on SQL Server
2000. Our SQL server is holding several databases (60+) and on some of them
(not all), when we change permissions on tables for a role (Public for
example), they do not seam to be saved.We tried through Enterprise Manager
and SQL Query Analyser with the same result. We change the permission,
click on OK, go out of EM and when we go back in, the permissions are back
the way they were before we changed them What is puzzling us is that it
works fine on some databases and not on other. We do not know of any
database options that would prevent changing the permissions, is there one?
Anyone as any taught about this?
MS SQL Server 2000 (sp3a)
Windows 2000 (sp4)
C.R.See Books onLine:
Resolving Permission Conflicts
mk:@.MSITStore:C:\Program%20Files\Microso
ft%20SQL%20Server\80
The public role is a special database role to which every database user
belongs. The public role:
Captures all default permissions for users in a database.
Cannot have users, groups, or roles assigned to it because they belong to
the role by default.
Is contained in every database, including master, msdb, tempdb, model, and
all user databases.
Cannot be dropped
To protect against unauthorized data access, minimize the permissions
granted to the public role. Instead, grant permissions to other database
roles and to user accounts associated with logins.
Thanks,
Kevin McDonnell
Microsoft Corporation
This posting is provided AS IS with no warranties, and confers no rights.|||Kevin,
You mis-understood my email. I mentioned the Public role as an EXAMPLE. We
are not trying to drop the public role, or any other role. We are trying to
set the premissions for the role(s). It is happening for ANY role we
created and the public role. We are trying to revoke all rights to the role
public and grant access to some other role(s). The changed permissions are
not saved by the server, weither we use EM or Query Analyzer to do this.
C.R.
"Kevin McDonnell [MSFT]" <kevmc@.online.microsoft.com> wrote in message
news:WrNRXxCwDHA.1868@.cpmsftngxa07.phx.gbl...

quote:

---

> See Books onLine:
> Resolving Permission Conflicts
> mk:@.MSITStore:C:\Program%20Files\Microso
ft%20SQL%20Server\80
> The public role is a special database role to which every database user
> belongs. The public role:
> Captures all default permissions for users in a database.
> Cannot have users, groups, or roles assigned to it because they belong to
> the role by default.
> Is contained in every database, including master, msdb, tempdb, model, and
> all user databases.
> Cannot be dropped
> To protect against unauthorized data access, minimize the permissions
> granted to the public role. Instead, grant permissions to other database
> roles and to user accounts associated with logins.
>
> Thanks,
> Kevin McDonnell
> Microsoft Corporation
> This posting is provided AS IS with no warranties, and confers no rights.
>
>

---

|||from previous thread
" We are trying to set the premissions for the role(s). It is happening
for ANY role we
created and the public role. We are trying to revoke all rights to the
role public and grant access to some other role(s). The changed
permissions are not saved by the server, weither we use EM or Query
Analyzer to do this."
I would run profiler to capture this. Create a sample database, list out
the tsql commands and trace it using Profiler.
As Richard mentioned, if you have a repro of this, open up a case with us
and provide us the details.
Thanks,
Kevin McDonnell
Microsoft Corporation
This posting is provided AS IS with no warranties, and confers no rights.|||We encounter the same problem like C.R. (with SQL200 sp3)
"We change the permission, click on OK, go out of EM and when we go back =
in, the
permissions are back the way they were before we changed them"
Danny
"C.R." a =E9crit :

quote:

---

> We are experiencing a problems setting permissions on roles on SQL Serv=

---

er

quote:

---

> 2000. Our SQL server is holding several databases (60+) and on some of=

---

them

quote:

---

> (not all), when we change permissions on tables for a role (Public for
> example), they do not seam to be saved.We tried through Enterprise Mana=

---

ger

quote:

---

> and SQL Query Analyser with the same result. We change the permission,=

---

quote:

---

> click on OK, go out of EM and when we go back in, the permissions are b=

---

ack

quote:

---

> the way they were before we changed them What is puzzling us is that i=

---

t

quote:

---

> works fine on some databases and not on other. We do not know of any
> database options that would prevent changing the permissions, is there =

---

one?

quote:

---

> Anyone as any taught about this?
> MS SQL Server 2000 (sp3a)
> Windows 2000 (sp4)
> --
> C.R.

---

|||I made a mistake
with SQL200 sp3a
Danny
Danny Presse a =E9crit :

quote:

---

> We encounter the same problem like C.R. (with SQL200 sp3)
> "We change the permission, click on OK, go out of EM and when we go bac=

---

k in, the[QUOTE]
> permissions are back the way they were before we changed them"
> Danny
> "C.R." a =E9crit :
>
rver[QUOTE]
of them[QUOTE]
r[QUOTE]
nager[QUOTE]
n,[QUOTE]
back[QUOTE]
it[QUOTE]
[QUOTE]
e one?[QUOTE]