Robin Giltner
1) Serialization works if the version of the containing DLL or the structure of the object does not change, so you wouldn't be able to export a bo, upgrade to the newest SF version and then import... the serialization would throw an exception.
2) Use the bo.CurrentDataTable.WriteXml() method to export. Make sure to include the schema in the XML; doesn't take much more space, and allows the schema (structure) to be changed between writing and reading (the option to export with the schema is an overload on the method). Then when you want to import the records, don't use the ReadXml() method directly on the bo.CurrentDataTable. Instead, create a temp data table (with just Dim dt As New DataTable()) and read the data into that. Then, use the CopyDataFrom method on the business object to copy the data into the table. The CopyDataFrom method will only bring in columns that belong to the business object and if a column doesn't exist in the source table, it will just be empty in the business object. The only thing it doesn't handle is renamed columns (it's not clarvoiant ), so if you rename a column, you'll have to copy the data into the bo on your own.
I would recommend the second method because it's a little more change-friendly.
We are working on implementing a method to export and import records in the database. And were wondering if simply Saving a Serialized business object with the records to export would be feasible. The main question we have about this, is say someone exports some records, and wants to pass them to another user. During this time, or anytime after really, the data structure for these records changes, would our serialized business object containing the records to be imported be pretty much useless at this point? Is there any way around this using Serialized Business object, or should we stick with exporting as XML with the version information etc.
Thanks,