>>Is there a program that does this already? If not, do you have any ideas on how to go about writing such a thing? The pack command I think I can handle. :) But I have no idea how to modify the structure programatically.
>>
>>Thanks,
>
>
>One way I have done this in the past is to create cursor temp (field1 c(?)....)
>cursor needs to look like you want the new structure.
>select temp
>append from currentdbf
>index on field1 tag field1 additive
>rename or del old dbf
>copy temp to oldbfname
>
>HTH
>Jeff

That way you cripple your DBC - overwriting the table by copying the cursor contents over it will create a table with no DBC info in its header, so the DBC will be stranded with the remaining info on the OldDbfName table, which now doesn't contain backlink info, and it will nag you with unpleasant messages next time you try to use the OldDbfName table.

I've written an utility for distributing new DBCs with possibly different structures of the tables, but had to code around a lot to be able to keep the data from the previous tables - just issuing Alter Table commands simply didn't cut it, because it had to function even if the tables didn't exist (new install) and if they did (upgrade - then it should keep the data), or already had the columns I wanted to add (reinstall - also, keep the data). I've had to invent temporary DBCs for each table created, submit old tables to internal DBC name renaming etc.

Besides, even if Michelle succeeds in issuing Alter Table commands from any kind of GUI invented on-the-fly (it may take various forms, indeed), there's another issue - where will these fields be filled with data from. The only way I find it possible is using browse or default-to-all-fields-possible grids, with default controls in cells, and reporting on quick reports or some third party tool (like CR or FF). The point is that if we let the user invent columns in tables, the app will be pretty much unaware of it, so we have discussed only the visible tip of an iceberg so far