Vlad Khorsun wrote:

> > 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.

The bad thing is that a lot of people out there DO NOT KNOW THAT THEY
HAVE THIS PROBLEM because it is VERY FAR from obvious. Milan fixed
FlameRobin after I made them aware of it and I only noticed it when
pasting data from FR's grid into Excel. I expect a lot of other
applications suffer from this problem without knowing it, and that's a
ticking time bomb.

> We can't extend XSQLVAR
> without API change and introduce of BIG headache for component writers.

If you start passing N in XSQLVAR.sqlscale:

1. No existing code will break.

2. New code *can* use the info if desired.

3. The documentation of the XSQLVAR.sclscale field will bring the
problem to writer's attention, so they can choose either to use the
passed N or, to be backwards compatible, use Milan's solution.

I can't see *any* downside to this.

> There
> is well known and easy to implement workaround - use it.

Yes, if 1) the writer is aware that it's required, which most probably
are not because it's unintuitive, and 2) the workaround can be found.
Also 3) it requires and extre round-trip and query execution just to be
able to read the first query's results properly.

> 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 ?

This argument sounds odd to me. If you apply that argument to all
changes, we would have no progress with anything. If something needs to
be fixed and there is a fix that won't break existing code, then what's
the problem? Component writer don't HAVE to use the feature. But
eventually none of the component writer's customers (or at least very
few) will use older FB versions than 3, so they can drop support for
them, and use only the new feature. That's progress.

> 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.

Yes, that would be nice. In what version? 10? 20? I hope I will still be
alive to see it happen.

Sorry! I assume you are a hard working individual and trying to do your
best with limited time, and overall I think you are all doing an
*excellent* job with Firebird!

Kjell
--
--------------------------------------
Kjell Rilbe
DataDIA AB
E-post: kjell@...
Telefon: 08-761 06 55
Mobil: 0733-44 24 64