>On 21 Jul 2005 at 11:34, Jim Starkey wrote:
>
> >Firebird apparently has no mechanism to report what features and
> >levels are supported by the database engine. There is a version
> >identification string, which is at best a poor substitute, requiring
> >both a problematic parse and a knowledge of what features are
> >associated with which versions.
> >
> >I suggest we consider a more civilized approach. The obvious
> >mechanism is a database info item as that mechanism already exists and
> >was designed for extensibility.

At 09:15 AM 22/07/2005 +0400, Dmitry Sibiryakov wrote:

> I think this idea is not good enough. To obtain a database info you
>must be connected to a database first. Personally, I'd like to be
>able to get engine capabilities before connecting or creating
>database.
> Simple example: I have an application which supports IB5 as well as
>FB2. When I need to create a database I must know what dialect I
>should (can) use. I don't want to use dialect 1 everywhere because it
>may be prohibited in FBn and can't use dialect 3 everywhere because I
>get "feature not supported" from IB5.

Agreed - Jim, do you have some wires crossed here? Your suggestion was
aimed at a mechanism to report the attributes of the database engine, i.e.,
presumably a service call of some sort; but then you proceed to suggest
that it could be a *database* info structure. Why would you write the
engine capabilities into databases? Isn't it the ODS level that matters
when considering what a database can support?

Helen