Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase

Session Context Information Expand / Collapse
Author
Message
Posted Wednesday, January 16, 2008 11:58 PM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC 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
Posted Thursday, January 17, 2008 4:51 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Yesterday @ 2:32 PM
Points: 6,128, Visits: 8,393
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
Posted Thursday, January 17, 2008 6:24 AM
SSChasing Mays

SSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing 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
Posted Thursday, January 17, 2008 9:24 AM
Hall of Fame

Hall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of Fame

Group: General Forum Members
Last Login: Wednesday, November 26, 2014 9:53 AM
Points: 3,475, Visits: 584
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
Posted Friday, January 18, 2008 7:05 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-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 »

Add to briefcase

Permissions Expand / Collapse