>I have a feeling a lot of your design decisions were made around the limitation of VFP that you couldn't add/remove fields without exclusive access to the table. In SQL Server that limitation is removed and that should simplify some of your rewrite decisions.

It didn't really affect the design although, of course, we had to ensure exclusive access - and you're right that SQL will remove that restriction.

>I'm assuming in your app you used generic char fields and then in your metadata tracked what type of data was actually being stored (numeric, date, etc.). In SQL server, because you can add fields on the fly, the fields types can actually match the data that is being stored.

True to a point but some of the 'data types' stored in memo fields were actually complex information required to, for example, specify a table (in the HTML sense of the word - i.e. number of rows, number of columns plus the content for each cell) so we still needed to specify the type of content because the native datatype didn't convey that information.

TBH, although I could follow the same design in SQL I'm thinking of more 'drastic' solutions - for example using one table to hold *all* the information with each record holding the content of one 'cell' with fields to identify the 'table', row and column to which it belonged. Most of the time the application only retrieves one row at a time so a SPROC to pull together a specific row should be possible.
But it gets messy in that when a user adds a row I'd have to create records for each column of that row and when they added a column I''d have to create an entry for each existing row.

Probably not a great solution - but I'm looking for any similar alternative 'blue sky' approaches......

Regards,
Viv