Don't think I'd have to worry too much about either of those limitations. Certainly transaction handling shouldn't be much of a problem - it's very rare for two people to be editing the data at the same time and I could code to prevent it without upsetting anyone. Only primitive search capabilities are needed and given the small size of the tables and the possibility of using .NET XML classes and/or Linq to XML I could make that work.

The biggest snag I can see is that if the user adds or deletes a column from an existing 'table' then I'd probably,in effect, have to recreate the entire XML for the table?

Thanks for the suggestion,
Viv

>Hi Viv,
>
>In the past I have done a similar design but I stored the tables as xml in text columns. This has limitations for transaction processing and search capabilities, but works well if all you need to do is store and display the data.
>>Hi,
>>
>>About to start re-write an existing VFP app using .NET and also moving the backend from a VFP to SQL Database.
>>
>>The application allows users, in a limited way, to design their own tables. In practice the type of fields are chosen from a pre-defined list. (e.g 10 character string, 50 character string, int, currency and some more complex datatypes that are stored in memo fields).
>>
>>There may be several such tables but usually each will only contain 6-10 fields and 100-500 records per table.
>>The user also needs the ability to later add and/or delete fields from existing populated tables
>>
>>In VFP we physically created each table as part of the database using randomly generated table and field names and used the DBC to track the 'user friendly' names of the tables and fields (including the datatype for the complex fields).
>>
>>I could implement the same type of thing in SQL (using additional tables to store the 'metadata' currently embedded in the DBC).
>>I've played with a couple of other options but I'd be interested to see if anyone can come up with a good alternative other than the above.....
>>
>>Note: Although I've put SQL 2000 as the version this would need to be supportable in SQL Express. Also, if there's some functionality in later versions that would make for a better solution I guess we could specify that version.....
>>
>>TIA,
>>Viv