January 16, 2008 at 11:58 pm
Comments posted to this topic are about the item Session Context Information
January 17, 2008 at 4:51 am
As an FYI, allow me to add that, even though the question speicfically mentions SQL Server 2000, the maximum size for context session information is actually the same in SQL Server 2000, SQL Server 2005, and SQL Server 2008 (November CTP).
January 17, 2008 at 6:24 am
Anyone care to post a "best practice" example use of this feature?
January 17, 2008 at 9:24 am
I check that it is the same. Then why did I have to login to my 2000 server to use its BOL to check what it was in 2000?
Well, it is good to login to the server anyway to check that eveything is OK there.
Regards,Yelena Varsha
January 18, 2008 at 7:05 am
The best practice is my question too, but ive thought about this question a long time ago. I believe the answer is to store user header information. Say you wanted to call several stored procedures but they all require a secret user guid only known at the db level for security sake, then the first procedure would load this secret key into that context, then whichever secure stored procedure you would like to call would have that key ready in memory to work with for that same connection. Today’s world they want you to keep connections open as short as possible, like for a single stored procedure call, then close. This secret key they would tell you to pass up to the program logic and let the program pass the key back to these secure procedures through parameters. But to me if the program logic touches this key, it would lose its extra secure magic. Following me on this?
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply