Roman Rokytskyy wrote:

>I was an idea that Firebird/Vulcan returns a value for the set of
>already known features. One of the feature JayBird needs is the NULL
>sorting order - in Firebird 1.5 they are sorted at the end, in FB 2.0
>and Vulcan they are sorted high (end with ASC and start with DESC).
>So, if Firebird and its clones return me a sorting order flag, I
>should not care about the Firebird version and the problem is solved.
>Also there is a call in JDBC to return list of reserved words.
>
>However this assumes that the set of the features is finite and all
>versions implement that API call. Neither is true. I would still have
>to check the Firebird version for FB 1.0 and FB 1.5 and return correct
>values there even the call does not exist. Also, if we add some new
>feature to FB 3.0 or later, JayBird should be updated with a
>workaround for all pre-FB 3.0 versions to return correct value or
>throw an error.
>

Ask for the capability vector. If you get "item not understood", the
feature isn't there.

>
>As I wrote before, I think that the best solution is to check the
>server and/or ODS version. If JayBird decides it knows what to do with
>it, it works, if not - it throws an error. It is even possible to have
>JayBird to load different "plugins" for different server/ODS versions
>the same way Vulcan works with ODS providers.
>

The ODS has nothing to do with the issue at hand. The ODS only talks
about the format of the database pages. The ODS can change (and will)
change without any impact on Jaybird, but Jaybird won't have a clue
about what the new version means.

The capabilities mechanism is intended to give you exactly what you need
to make an intelligent decision: Does this database attachment support a
feature I need or can use if present? The database system can say
"yes", "no", or "I haven't a clue what you're talking about" (which
should be taken as "no").