Rick, thanks so much for the suggestions. Kevin said that mmDataSet was not marked as Serializable and that it has been corrected for the next release of MM.NET.

However, you make some good points on the scalibility with SQLServer. Bob Archer referred me to a webcast from Microsoft (http://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032250622&Culture=en-US). The presenter makes the case for always using InProc sessions and using a load balancer that enable "sticky sessions". Though the sessions will not be completely evenly distributed, the speed benefits evidently far outweigh the slight inbalance in a web farm scenario.

So, I'll shy away from SQLServer for maintaining state. The answer to the initial problem has led to an intense education and a different course of action (unexpected at that) <g>.

Regards,
Carl.


>Hi Carl,
>
>I've done this and it works just fine, but for what it's worth this is not the greatest of ideas especially if you're talking about scalability with many users. Serializing a DataSet into SQL Server to save yourself a roud trip from SQL Server may not buy you much at all in terms of performance unless the query generating the data took a long time to run.
>
>Anyway, I wonder if you've subclassed the DataSet? If you do make sure you mark it as Serializable because this attribute does not flow down to subclasses. Further if you added any non-serializable properties make sure you mark them as not serializable (I think it's [XmlIgnore]).
>
>This may also be true of strongly typed datasets... in which case you might want to try get a reference to the REAL DataSet object underneath it and just serialize that.
>
>Another thing to consider is to use the ASP.Net State Service which is considerably more performant than going to SQL Server as it's optimized to storing state data.
>
>Regards,
>
>+++ Rick ---