> I used domains for most of fields in my DB. Then an issue appeared:
> There was domain NAME_DM VARCHAR(30) and a lot of fields based on
> this domain in DB. Then my customer wanted to extend one field size
> from 30 to 40 chars. So to accomplish the consistency between domain
> definition and the real fields size I changed the domain definition
> and then _all_ fields definition. (Changing the domain definition
> does not really affect the existing field size).

> If I did not use domains in such case, I could change only the one
> requested field. Was there any better solution?

I agree that IB/FB do not make such changes easy to achieve. Even
with the new v6 ALTER capabilities.

In the situation you describe I suspect the preferred solution may
have been to add a new field with the expanded size (possibly based on
different domain), move the data across and then drop the old field.

My solution to this problem probably reflects the fact that all my
production databases are relatively small (less than 2Gb). I rebuild
the database.

That is; In the past I have always kept my SQL scripts etc upto date
in their own database and when such a change occurs I have a utility
that reconstructs the database using those scripts and transfers the
data. Now I have a more generic tool (the DBak project you may have
seen mentioned) which makes this process reasonably simple.

This may be overkill for the your particular situation - although that
partly depends on how may constraints, views, triggers and procedures
you have that access this field (all of which must be dropped before
changing and then recreated again). Because my databases tend to have
a great many triggers and procedures I find structural changes easist
to achieve by rebuild.

--
Geoff Worboys - TeamIBO
Telesis Computing