Ok, I wasn't sure. I just hadn't seen anyone recommned using that way, and was wondering if you guys were doing it your way because you had seen something in your experience which made it the better choice.

Thanks,

Morgan

>>I come from a web background, and what of the first things when developing Web apps that can scale, is to reduce
>
>Same here - about half the stuff I've worked on has been web-based. You tend to get obsessive about performance. However, I've gotten more pragmatic about performance over the last few years, since I've found that the .05/second saved really didn't make a hill of beans difference. Most of the sites I work on will >never< have enough traffic to justify worrying about it. If they do, you can buy faster hardware. Cheap. I now prefer cleaner designs and consistency over pure performance.
>
>I'll be honest, though, a lot of my designs have come from doing web stuff inside of Web Connect and VFP (and a small amount of ASP). Until ASP.NET, even ASP developers wouldn't suggest storing that much data in a session. WebConnect doesn't have a built-in way of persisting entire objects into the session (although there are some pretty easy ways of doing that). So I guess I've got a bit of a bias because of my other development environments.
>
>>You could always store the DataTable in the session, and if you use SQLServer state store, you can doing all of
>
>Sure, but you'd still need to distill that data into a physical table at some point if you want to do things like query all transactions currently in process. I've found having this information, in a database as a nice denormalized table makes it easy to query, report on, etc. If I've got to do it for some things, I'd prefer to be consistent and do it for everything.
>
>>I mean, how you have done it doesn't seem bad at all, it just seems like re-inventing the wheel, I was just
>
>Like I said, at the time I started doing it, this particular wheel wasn't available yet. I do think that for maximum scalability, you >have< to store sessions in SQL server. It's "built-in" to ASP.NET, so the only reason to not use it is if you don't want to deal with the performance hit of it. At some point, to scale to multiple machines (server farms), you'll need to, though.