Yeah, you normally do, but you are adding yet another request for every page, I mean depending how your system is setup, and where you are doing the database request on even 404 pages, or pages that don't do it.

I come from a web background, and what of the first things when developing Web apps that can scale, is to reduce the number of database calls per page request. I mea, yeah you aren't opening up the connection, but you are still hitting the database. I mean, if you use a SQL Server to store session state anyway you will be hitting the database, but I was just curious why all the reduncancy with creating your own table etc.

You could always store the DataTable in the session, and if you use SQLServer state store, you can doing all of the things you talk about from "complete" transactions, and sharing sessions, and even storing them.

I mean, how you have done it doesn't seem bad at all, it just seems like re-inventing the wheel, I was just curious because no one in the thread really talked about using SQL Server to store session state. I think that would be the "ideal" way, but I haven't used it extensively for storing session information just a little bit.

I have used PHP sessions, and I created the same solution you did w/ MySQL and PHP, before PHP 4 came out, and supported sessions and storing the session information in a database. It didn't really make much of a difference on sites until you start getting a lot of traffic, and then it really makes significance difference. I "hope" and think that will be the same w/ storing session information in SQL server, but I'm not sure yet.

Morgan

>You'll normally hit the database on every request anyway (for the data-entry type of website). I'm also assuming you're going to hold the connection to the website open, so you're not incurring the performance hit of opening the connection each time.
>
>A few reasons I use a table instead of a session:
>
>- It makes data-binding easy
>- It makes data validation via business objects easy - I don't have to move anything from the session to the business object beyond a simple requery.
>- You don't have to worry about persisting data out of the session for later use. For example, if I was selling insurance and someone started filling out a request form, then never finished submitting it, I'd want to know why (since we just lost a sale). With that data sitting around in the session, you don't have an easy way to do this.
>- It works well for passing "complete" transactions off to some sort of queue (eg. for long running requests, batch updates, etc). The data is already sitting there, waiting to be used.
>- You can do neat things like share this "session" information across users. Ex. A user is filling in a state form and runs into a field they don't know how to answer. They click on a "Operator" link which lets a CSR view this same exact screen, and it's data (and interact with the data). You don't need to do anything funky with moving things between sessions.
>
>I'm not saying that this is the ideal solution for all situations. But, for larger data-entry screens I've found it works great and is pretty flexible.