Another option to solve the immediate problem is to restore to a new installation and copy paste the lost content back to the original site. This assumes its just a few specific pieces of content that were lost. Its not an easy solution but in an emergency it can be done and conceivably you could charge your customer to do it.

Best,

Joe

Some of the challenges to solve at least for my long term vision of a tool like this will be:

• how to keep it maintained as things are constantly being added/changed as the project evolves
• how to make it flexible according to what features are installed, ie mojoportal core, mojoPortal.Features, WebStore, etc
• how to make it easy to make new features that are also exportable

The stragey I have in mind is to use built in .NET ability to save DataTable/DataSets as xml with schema. The import side would pass in the DataTables or DataSet re-constituted from xml to each layer where db specific implementation would process it into the db.

I think I will need to keep some reference schema xml files generated on MS SQL in order to import to MS SQL from other dbs because the schema is different accross dbs due to difference in data types like MS SQL has a native Guid aka uniqueidentifer data type while the others we use char(36). So if the data was exported from another db as char(36) the importer would have to be smart enough to treat that as Guid.

Of course you don't have to think of all of that for your own solution.

Best,

Joe

The provider model is useful for supporting different kinds of objects that support an interface and determining which kind to load at runtime. We don't need it for the database layer because which database to use is an install time decision not a runtime decision and I don't want the overhead of runtime checks for which provider to use for every data access method.

We use a static service facade pattern, using static methods guarantees the methods are threadsafe.

The solution of backing up data by creating insert sql statements can work if you are only concerned about backing up and restoring against 1 single database platform. The statements that would work for MS SQL will not work accross dbs. It makes sens for your goals but for my goals I need a common format to export/import from.

I don't use DataSets myself but in this case they offer a good convenience because they are easy to make, they have the schema in their meta data and they already provide an ability to export to xml. So I'm just saying for my goal it seems this would offer value. If I were only concerned about MS SQL I would not find it attractive because it would be easier to work directly with MS sql tools.

Best,

Joe