>> Do you consider "too complex and not very intuitive" for data access
>> layer
>> to query system tables for fileds CHECK constraints, DEFAULT values, etc ?
>
> This has nothing to do with fetching data. Having to query the
> system tables in order to properly process the data as provided
> by the client side API, does that sound "OK" to you?

I never said it is OK. But i see nothing BAD so far. We can't extend XSQLVAR
without API change and introduce of BIG headache for component writers. There
is well known and easy to implement workaround - use it.

Imagine we start to use sqlscale for N. It will be supported *only* by fbclient v3
and fbserver v3 (or higher). I.e. it will not work if client or server have version less
than 3. Imagine fb3 will be released at 01.01.2010. When you plan to migrate to fb3
and use this feature ? Do you think component writers will be glad to implement
additional check for versions of both client and server to decide if sqlscale contains N ?

I prefer to make one big change to API in some version of FB than introduce a lot
of little hacks in every release. The only exception is when there is no workaround.

Regards,
Vlad