Hi,

> > is a *free*
> > version of IBExpert ("personal edition") ready for download. It is

limited

> > to a certain degree (e.g. the StoredProc debugger from the full version

is

> > missing), but after a first glance it seems it has all the functions one
> > needs for administrating both IB *and* FB databases.
>
> I'm not associated with any tool maker currently. However, I have my

doubts

> about QuickDesk and IBExpert. Both of them seem to modify mercilessly the
> system tables directly. I've handled several cases over the last two years
> that may be attributed to this behavior in both tools. Last example: go to
> read bpi.bugdiscussion where an index was rendered unusable and hence,
> results were unmeaningful when that index was used for sorting. You cannot
> change a field's data type if such field is the PK without dropping the
> contraint that in turn drops the index (and Craig Stuntz did the normal
> steps, then declared the user's problem cannot be reproduced). I couldn't
> understand how the damage happened until the person told me he didn't use
> DDL but IBExpert. Go figure. The PK field was changed nastily from int to
> int64 and the underlying index went crazy for obvious reasons. While I

have

> nothing against Alexander K. (former QuickDesk programmer and now IBExpert
> programmer) and also have exchanged some emails with him in the past
> regarding metadata extration, I think people deserve to know some dangers

of

> excessive, untamed power they get. Under normal circumstances, DDL stops
> several suspicious operations. However, if you modify system tables
> directly, you can write almost anything to them and the engine tries to
> behave accordingly. The engine doesn't check the correlation among system
> tables (only a few cases are validated), hence incomplete changes cause
> major havoc. This validation and completion is the task of DYN, invoked

from

> DDL. Bypass DDL and you assume the responsability.
>
> The bottom line is that one should be very careful with "innovative

metadata

> abilities" that any tool may sport. Remember the engine itself has

troubles

> with some metadata changes. Also, how does direct metadata manipulation

work

> against IB6.5? This remember me the "innovative approach" that Symantec

took

> to defragment NTFS partitions. If you want to corrupt your MFT, just use
> Norton's Defragmenter under normal operations... sooner or later you're
> going to regret your decision.
>
> I hope IBWorkbench is more traditional in its approach, but I better let
> Martijn to confirm.

Claudio, you hit the nail on the head. This is exactly the reason why I use
standard DDL - in InterBase Workbench, there's only one place where I
use a system table manipulation directly and that's for the field NOT NULL
flag. When a constraint exists in the RDB$RELATION_CONSTRAINTS
table, it is dropped too (for changing from not nullable to nullable). This
particular system table manipulation was carefully researched (both on
ib-support and firebird-devel) before even trying it.

And yes, I had questions about this, saying 'I can do this in IBExpert, why
not in yours' - explaining usually helps.

O, and to be honest, I also update RDB$DESCRIPTION in several tables,
but only untill there is a COMMENT statement ;-)


Thanks,

Martijn Tonies
Upscene Productions

InterBase Workbench - The Developer Tool for InterBase
http://www.interbaseworkbench.com

"Experience is what you get when you didn't get what you wanted"