Dear Jim Starkey ,

Even I do accept that fix is not complete. What I did is not a
fix just a work around for my application? Is there is any better way
to solve the problem. Even I am eager to contribute towards fixing
this problem. Is there is any document which explains the code
flow/behaviour that will help me in understanding FB better.

Thanks for your response ,
S.Karthick

--- In Firebird-Architect@yahoogroups.com, Jim Starkey <jas@n...> wrote:
>
>
> kartinku wrote:
>
> >
> >Dear Ann W. Harison and Members ,
> >
> >Thanks for your rsponse.
> >
> >
> >
> >
> >>Because the index is being created on the referencing table and
> >>does not protect the referenced table.
> >>
> >>
> >
> > Is it means that there will not be any problem in case of super
> >server. I hope that super server (SS) shares the same meta data , so
> >referenced table will get protected.
> >
> > Since My application requires SS firebird server. Do I go ahead with
> >my changes for super server (I have commented out the exclusive
> >connection check only for super server. you can seee my changes in
> >dfw.epp. It is uploaded in FB-Architect ->files. You can find my
> >changes with in comment <multi connection meta data handling>).
> >
> >
> >
> Pardon me if I am being blunt, but if it doesn't work in classic, the
> change isn't acceptable. We may abandon classic at some point, but we
> certainly haven't yet, and this doesn't warrant doing so. We cannot
> tolerate different behaviors between classic and superserver. The
> Vulcan engine combines superserver, classic, and embedded, so
> conditional compilation is not a possibility.
>
>
> [Non-text portions of this message have been removed]