M
MattStickney
Guest
The real-world problem here is that without the ability to change field POSITION, schema changes can't be reverted from SQL. If you delete a column from the middle of a table and re-add it, it's position will be different. That causes the CRC for the table to differ and prevents any pre-compiled code from running, even though the schema is otherwise identical. Without the ability to modify field position from SQL, that effectively prevents SQL from being used for e.g. Rails-style schema migrations[0], which is a shame, since SQL is quite a bit better than df files for that purpose. The SQL documentation lists an unsupported PRO_RPOS attribute for doing just that; other options are acceptable, but actually implementing that attribute for CREATE TABLE and ALTER TABLE is probably the cleanest approach. A second option might be to allow SQL connections to edit the _Field VST (or at least the _Field-rpos column of it), although that's a pretty hacky change to make. [0] It's possible to work around the problem by recording desired field positions in a table and later running an ABL script to enforce them, but that's pretty kludgy.
Continue reading...
Continue reading...