Two parter; *Part 1;*
One thing I would suggest, if you're looking to add and delete columns dynamically is not to worry about the order of the columns in the database, but, have a second table hanging around that remembers the specified order the user wants to see the columns in. Doing your update and insert calls make no difference so long you specify the fields on either call (Or in oter words, don't do [ insert into MyTable values (1,2,3) ]. Be aware on tables that get large. Adding or deleting fields can get expensive when the databases physical pages need to be updated, especially if the field you're adding affects, or has indexes modified. *Part 2;* More along with your application style, but a complete database schema overhaul, think of a contact form that allows for multiple methods of communication. Multiple email addresses, multiple phone or fax numbers, can all be associated to one contact. Typically you'd have a table sitting aside with the contact type (email, phone, fax, maybe in the future Telepresence ID?), and another table containing the actual data. You could adopt this method to what you're describing. To add or delete fields to your UI (Telpresence info doesn't exist in any common contact manager I know of), all you'd have to do is add or delete rows to a table, and your application written to adapt to random(?) changes to the field changes, regardless of additions or deletions. All you'd need is one table that would hold the fields unique identifier, a field title, the order in which it is displayed on the UI, and possibly a default value field. Another table contains a unique identifier, a FK field pointing to the UID of the above table, and the raw data. Your software would then make whatever required SELECT call to obtain the required information and either store that data in a new temp table, or, store the data in memory either via a stringlist or class, then render the data to your UI using just this new data. BY FAR *not *the most efficient method, but, weighing the cost of multi-gigabyte sized tables changing frequently at the users whim, versus a few more queries to the database to mangle data in memory, it'd be up to you as the developer to decide which is the best method.
