Session Context Information

SQLServerCentral is supported by Red Gate Software Ltd.

Popular Topics

Home

Members

Calendar

Who's On

Home » Article Discussions » Article Discussions by Author » Discuss content posted by Reza Nassabeh » Session Context Information

Session Context Information

Rate Topic

Display Mode

Topic Options

Author

Message

r_nassabeh

Posted Wednesday, January 16, 2008 11:58 PM

SSC Rookie

Group: General Forum Members
Last Login: Sunday, January 27, 2008 5:14 PM
Points: 31, Visits: 7

Comments posted to this topic are about the item Session Context Information

Post #444154

Hugo Kornelis

Posted Thursday, January 17, 2008 4:51 AM

SSCertifiable

Group: General Forum Members
Last Login: Today @ 4:24 AM
Points: 5,232, Visits: 7,022

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).

Hugo Kornelis, SQL Server MVP
Visit my SQL Server blog: http://sqlblog.com/blogs/hugo_kornelis

Post #444226

Robert Lomax

Posted Thursday, January 17, 2008 6:24 AM

SSChasing Mays

Group: General Forum Members
Last Login: Sunday, August 16, 2009 5:37 PM
Points: 614, Visits: 14

Anyone care to post a "best practice" example use of this feature?

Post #444274

Yelena Varshal

Posted Thursday, January 17, 2008 9:24 AM

Hall of Fame

Group: General Forum Members
Last Login: Monday, July 30, 2012 10:42 AM
Points: 3,434, Visits: 519

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 Varshal

Post #444394

gdelgado

Posted Friday, January 18, 2008 7:05 AM

SSC-Enthusiastic

Group: General Forum Members
Last Login: Tuesday, February 17, 2009 12:42 PM
Points: 161, Visits: 129

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?

Post #444839

« Prev Topic | Next Topic »

Permissions