>>
>>That's an interesting idea, though all code is already written and tested. Tables are part of DBC. So, can you elaborate more on your suggestion? (Seems like a tremendeous change in the existing algorithm :()
>>>
>
>Can you give me an example of the types of table alterations that are allowed? Are people allowed to change the name of a field? Or is it generally adding/deleting a field and changing the widths of fields?

We have two tables. One is called DataDict and contains fields definitions for all our State DBC. E.g it has the following structure:

Field_Name Field_Type ... Table1 Table2 Table3...

In Table1 it stores field order of this field in a table1, so it could be 0 or some number.

We also have IndxDict table, which has table+tag fields, so it contains each table name with their tags and expressions.

Not to mention, that we have ValCalls table, which holds table name + Field + MethodCall.

My program checks structure of our existing tables (each table in a DBC) against those tables. In case of discrepancies found, it perfoms the necessary operation (Field could be deleted, it's type could be changed, it's validation rule could be changed, etc.). The program is extremely complicated, there were several people adding their pieces in it before I finally made all enhancements, etc.

So, here are problems. Running ALTER TABLE command may require disk space usage. I need to understand exactly, what disk would be used and what kind of check for a free space I need to run before attempting to run this command. I already implemented some check, but it seems to be incorrect...