Any hierarchical functionatility in Management Studio in 2005

I am thinking, if there is the functionality that can hierachically group the tables, views, and stored procedures into different sections within each database, it will be much clearer and logical for maintain the database objects.

For example, to create containers in the console tree of Management Studio or Enterprise Manager, or even apply the namespace/subnamespace features to the tables/views/stored procedures of each database.

A clearer explanation:

Inside each database, all the tables, stored procedure and views are at the same level, if new folders/containers can be created to segmen all these database objects into different groups, it will be much more clear.

An even advanced feature is to apply namespace concept to the database objects, so that it will truly hierachical besides the appearnce in the console tree.

|||

This probably isn't exactly what you're looking for, but ...

You can use SCHEMAs to put tables, procedures, types, etc. into separate namespaces.

From SSMS, you can

Create a new schema from the "Database/Security/Schemas" node in Object Explorer|||

This functionality does not currently exist. You can submit this suggestion through https://connect.microsoft.com/SQLServer.

Cheers,

Dan

any *simple* external activation examples available?

BOL only seems to say that you can do it w/o really showing how, and the ExternalActivator sample at gotdotnet.com contains so much functionality I'm not sure what's required just for the external activation. Are there any docs or samples out there that focus on how to do it w/o obscuring the matter with a bunch of other functionality? (I prefer docs to project samples, b/c the samples tend to have hacks like hardcoded paths and connection strings so that they rarely work correctly right out of the box.)

TIA

The sample tries to do it correctly. That is, it must gaurantee that it will try to launch the process even under memory pressure and process failure. If it didn't, there is the danger of orphaning messages in the application queue. In order to provide this gaurantee, it must implement basic recovery logging. That adds to the complexity.