Securables for Application Role in Management Studio do not stick

Securables for Application and Database Roles do not show after they have
been setup.
I do the following:

1.. Select an Application Role from Database -> Security -> Roles -
Application Roles and select Properties from the context menu
2.. Select Securables page
3.. Select Add on the Securables panel
4.. Select a couple of objects to add
5.. Check some Explicit permissions for each securable object added
6.. Click on OK
7.. No errors are reported
8.. I repeat steps 1 and 2 above to view the securables that i have added
9.. Both panles are displayed empty
What am doing wrong?

Regards,

Joginder Nahil
www.starprint2000.com

Here is information from the About dialog box of Management studio:

Microsoft SQL Server Management Studio      9.00.1399.00
Microsoft Analysis Services Client Tools      2005.090.1399.00
Microsoft Data Access Components (MDAC)      2000.085.1117.00
(xpsp_sp2_rtm.040803-2158)
Microsoft MSXML      2.6 3.0 4.0 5.0 6.0
Microsoft Internet Explorer      6.0.2900.2180
Microsoft .NET Framework      2.0.50727.42
Operating System      5.1.2600

Joginder Nahil (joginder.nahil@uk.fujitsu.com)  writes:
> Securables for Application and Database Roles do not show after they have
> been setup.
> I do the following:
>
>   1.. Select an Application Role from Database -> Security -> Roles -
> Application Roles and select Properties from the context menu
>   2.. Select Securables page
>   3.. Select Add on the Securables panel
>   4.. Select a couple of objects to add
>   5.. Check some Explicit permissions for each securable object added
>   6.. Click on OK
>   7.. No errors are reported
>   8.. I repeat steps 1 and 2 above to view the securables that i have > ad
ded
>   9.. Both panles are displayed empty
> What am doing wrong?

It seems that your error is simply your expectations. You will first
have to find the objects you want to see permissions for. At least, that app
ears to be the essence of the resolution of these two bug reports:

http://lab.msdn.microsoft.com/produ...af-8e6e4eda1c48
http://lab.msdn.microsoft.com/produ...7c-2cb6eec4a343

Please don't ask me to defend this behaviour.

--
Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se

Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pr...oads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodin...ions/books.mspx

Hi Erland,

Thanks for pointing me to the bugs and a speedy response.

In my book they are definite bugs. I somehow find it hard it accept that the
behaviour is 'as designed'. I have shown this behaviour to a number of SQL
Server expert users who all thought that the behaviour is unacceptable and
should be treated as bugs. I have not got the energy to fight the case.

Regards,
Joginder Nahil
www.starprint2000.com


"Erland Sommarskog" <esquel@sommarskog.se> wrote in message
 news:Xns977EF009D59F
BYazorman@127.0.0.1...
> Joginder Nahil (joginder.nahil@uk.fujitsu.com) writes: 
>
> It seems that your error is simply your expectations. You will first
> have to find the objects you want to see permissions for. At least, that
> appears to be the essence of the resolution of these two bug reports:
>
> http://lab.msdn.microsoft.com/produ...af-8e6e4eda1c48
> http://lab.msdn.microsoft.com/produ...7c-2cb6eec4a343
>
> Please don't ask me to defend this behaviour.
>
> --
> Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se
>
> Books Online for SQL Server 2005 at
> http://www.microsoft.com/technet/pr...oads/books.mspx
> Books Online for SQL Server 2000 at
> http://www.microsoft.com/sql/prodin...ions/books.mspx

Joginder Nahil (joginder.nahil@uk.fujitsu.com)  writes:
> Thanks for pointing me to the bugs and a speedy response.
>
> In my book they are definite bugs. I somehow find it hard it accept that
> the behaviour is 'as designed'. I have shown this behaviour to a number
> of SQL Server expert users who all thought that the behaviour is
> unacceptable and should be treated as bugs. I have not got the energy to
> fight the case.

Well, if it's intended to work this way, it complies with the specification,
and it is not bug.

But it's still a very poor GUI design. If now, for some reason, it's not a
good idea to read all the permissions for a principal at once, you should
at least be given a hint to find out. The obvious reaction when you see
the dialog is "good, this guy is not permitted to anything, I can sleep
tight".

--
Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se

Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pr...oads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodin...ions/books.mspx