I commented out exclusive connection check for my application to
enable FK creation at multi connection. I feel it is not proper.
There would be any reason behind this constraint.
Ann w. Harrison said that notification is the issue in classic
server. Is it means that there won't be any issue in super server?.
But Ann W . Harrison said he is not sure of this?

So I tried to analyze the code. It seems you have this check to
create index (from your source code comment I learnt). I read
"IDX_create_index" method of "idx.cpp" which gets invoked in index
creation.

But I was unable to understand firebirds flow and reason you have
this constraint.

From your design document I learnt that Firebird locks meta data
table while updating meta data. And the application table also gets
locked while modifying meta data. So multi connection meta data update
may not be an issue. More than locking FK creation involves many other
steps in its process. Is there is any other constraint which needs
exclusive connection for FK creation. Kindly update me

Please do let me know what is the reason (design) for not supporting
foreign key creation even in super server in multi connection scenario.

S.Karthick

--- In Firebird-Architect@yahoogroups.com, "kartinku" <kartinku@y...>
wrote:

>
>
> Dear Members ,
>
> We had several mail transfer regarding multi connection meta data
> update earlier. I feel this as a needed feature in firebird for my
> application. This may be needed for others also. Ann W. Harrison said
> there are some notification problem in multi connection mode in
> classic server. So it would be better if you support this in super
> server alone. So please do let me know whether you will support this
> feature in future or not.
>
> S.Karthick
> --- In Firebird-Architect@yahoogroups.com, "Ann W. Harrison"
> <aharrison@i...> wrote:
> At 08:37 AM 9/28/2004, karthick srini wrote:
>
> >So do I modify the code such that exclusive connection
> >check is made only in classic server by including
> >preprocessor like below.
>
> I can't and wouldn't make the decision for the group.
> Your solution bothers me for several reasons -
>
> For one adding conditional code based on the build-type
> seems like a regression - where does this fit with embedded?
>
> For a second I'm not completely sure that creating of
> foreign keys in multi-user mode will be handled correctly in
> SuperServer, only that it won't in Classic
>
> And for a third, I'm not happy with this as an addition
> to the very close to frozen V2.0.
>
>
> Regards,
>
>
> Ann
> --- End forwarded message ---