Adriano,

> > I think we are all aware of the issue re.
> > "We generally see users complaining about old procedure and triggers
> > versions running even in SS. We point them that this is documented in
> > IB6 docs."
> >
> > As you correctly point out it has been documented for a log time.
> > At the moment reading this thread I feel that you are using
> > "a sledgehammer to crack a nut" - if the phrase doesn't make sense I
> > can explain it.
> >
> I don't consider documented laziness of designers/programmers as features...

At no point did I suggest it was a feature... just that the engine has worked this
way for a long time, and I don't think now is the time to change it.

> > And I would suggest that your valuable time would be better spent working on other
> > issues in the engine.
> >
> If you're talking as project member, yes, there is things more urgent
> that I should work for V2.5. I'm aware and I'm working.
>
> If you're talking as FF president, your suggestion is not accepted.
> Please consider this "wast of time" (in your opinion) as "just for fun"
> (inside the double of necessary hours I worked in July).

I was talking as a project member and admin. If I was talking as the FF
President in this list - it would not make any sense - since the FF does not
get involved in development issues.

> > Alex's comment:
> > "Please take into an account that this is VERY SERIOUS change in firebird
> > behaviour - since interbase days metadata modification was possible in
> > parallel with use of that objects. I'm sure that it will create a wave of
> > problems for our users not smaller than ones related with changes like
> > SQL-standard "NOT IN" or inability to use BLOBs in "SELECT DISTINCT". I will
> > be very happy to see a solution of MT-safe, clear, simple to program, etc.
> > metadata cache. But I do not like when it breaks logic and features which
> > existed for years."
> >
> > Is something I wholeheartedly agree with.
> I will be very happy to see suggestions to:
> - make easier to do multi-threaded SS
> - works ok in CS
> - is consistent (i.e., we know exactly how things works)
> - allow we to add each feature in X time, instead of 1.5X or 2X
>
> Let me say that we're just discussing things. And my somewhat incomplete
> RFE was just to see community/project members reaction without loose too
> much time for nothing. And I'm glad that Alex jumped on it to offer
> technical suggestions and objections.

Like you I have been incredibly busy and I only noticed this thread today.
Hence the comments.

> I see the metadata caches as one of the big issue we currently have. Or
> nobody does the MT engine yet because it's not wanted?

It is an issue, and I believe it should be addressed as part of V3.0, but
Alex's comment re. "I will be very happy to see a solution of MT-safe, clear,
simple to program, etc. metadata cache. But I do not like when it breaks logic and features which
existed for years." is critical and the current RFE bothers me in particular.
So lets continue to discuss this.

Paul

Paul Beach
Tel (France): +33 (0) 2 47 58 30 43
Mob (France): +33 (0) 6 79 24 32 32