Wow... why SQL 2000? It's probably nearing end of support. There are some great things in 2005 and 2008 that you can take advantage of such as and XML data type that can be used for your complex fields. You also don't have the name limitations in SQL Server that you do with VFP, so friendly names are easier to handle.


>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