Here is a suggestion and what we do.  Create a custom class that has all of the properties that you want.  Then create a table that has a item type (integer / enum) and a data (VarBinary) field.  The reason you would create an item type field is so you can create as many different classes as you want.  Once you have the class created, you can serialize to the table to save the state, then when you bring it back out it is already a class with the properties that you need.  It makes coding much easier and this is a great place to use serialization to save off states.

I was originally thinking about storing some object properties, like the splitter distance on the ThemedSplitContainer , but I could probably get away with storing each property value that I need in a varchar field. I didn't know if I could store the object itself and then recall the stored object properties when required.

It really depends on how you plan to store the registry data.  How are you retrieving it and how do you plan to restore it?  More than likely a VarChar field may be all you need if you pull out the text registry entry.  This would be the same code that you see when you export a registry entry to a .REG file.

I need to be able to store registry type data in the database instead of the registry (Form location/size, user preferences, etc...) so I need to be able to store all types of data in one field in a table. I assume I use variant datatype for this in the toolkit. (Let me know if I should be using something else).

When I map my business object, the field I created as variant has been changed to System.xml.XmlReader.  Is this correct?

Is this the best way to handle storing this type of data.

Thanks

Tim