Hi Dorin

>Yes, you can. If you have columns with similar characteristics or check constraints, you can create a domain and use it for columns definitions in all tables where you need it.

I guess I won't ahve much use for checks as I will be using CodeBook as a framework and the Business Objects in it should be the one doing the checks, but one never knows when anything starts getting useful suddenly.

>Suppose that you have a domain defined as NUMERIC(12,3) used in many tables, some of them with millions of records. If you change the domain to NUMERIC(15,3), this doesn't mean a long running task that implies changes in all tables. Instead, the engine is smart enough to do conversions only when a record with changed column definition is visited/changed in a read/write operation.

Oh, wow! I had this terrible happening in VFP where a similar change was required from 12,2 to 12,4 and all hell broke loose I had to lookup each and every table for similar fields and had to change them all table (weep) by table (weeping). That was the reason I have started using doubles in my tables (it's nto my HDD space and anyway it is cheap now), just set the picture in the preference box and the classes will adapt accordingly.

I guess, with domians VFP has nothing to worry about? for VFP it will still be a numeric type.

Thanks a lot, this I would not have learnt easily and in the short terms future.

While I am writing this to you can I ask a direct question to you regarding FireBird (it is a sort of repeated, more like revisited)

- I have a fbd created on my development machine. (for eg. contains mAccounts the master table)
- I distribute this new fdb to the clients machine as an .SQL file created in Marathon which is then made into a fdb.
- On the clients machine my support staff creates a table aAccounts (this is a flexible table logic I am implementing) which contains client specific fields regarding the master table
- I update the application with / without updates to the fdb
- I redistribute the app and fbd as an .SQL to the clients machine.
- Support staff uses Database Comparer to compare the clients fbd with the new .SQL
- The resulting update.sql contains the drop table command for aAccounts

Though this can be manually overridden by removing the line from result.sql, I am not confortable with the chance that the support staff makes a mistake.

Is there an opensouce/freeware no limitation utility to do the same maybe generate a result script without intervension from command line. The script then can be studied using a small command line utility to strip the drop table a... commands. Another utility then applies the changes from this updates script onto the clients fdb.

Please advise.