liviuslivius skriver:
>> I know this is not what many people want to hear, but it's probably high
>> time to consider IB and FB to be two unrelated databases, and never
>> expect them to be compatible in any way. With that mindset and those
>> expectations, you will probably find your life easier. They've diverged.
>> Get over it and get on with it? :-)
> Hi Kjell,
>
> i know that but i suppose that in field description FB and IB are still 
> compatible
>
> i talking about this declarations in sqlda_pub.h
>
> #define SQL_TEXT                           452
> #define SQL_VARYING                        448
> #define SQL_SHORT                          500
> #define SQL_LONG                           496
> #define SQL_FLOAT                          482
> #define SQL_DOUBLE                         480
> #define SQL_D_FLOAT                        530
> #define SQL_TIMESTAMP                      510
> #define SQL_BLOB                           520
> #define SQL_ARRAY                          540
> #define SQL_QUAD                           550
> #define SQL_TYPE_TIME                      560
> #define SQL_TYPE_DATE                      570
> #define SQL_INT64                          580
> #define SQL_BOOLEAN                      32764
> #define SQL_NULL                         32766
>
>
> i suppose that changing integer value from 32764 to the same value as is in 
> Interbase will cause that FB and IB will be compatible for Boolean
> but may by i am wrong - i know only a little about internals

I probably know even less than you about the internals, but I think it's 
time to stop assuming that IB and FB will and should be kept compatible. 
In the long run it not feasible, nor desirable. These are two separate 
products and must be allowed to find their individual paths forward 
without the impediments of compatibility constraints, neither enforced 
nor community expected.

If FB chooses the same value as IB for SQL_BOOLEAN it might be expected 
to imply that these types are 100% compatible, which I assume will not 
be guaranteed, so while it might work now it's also a potential time bomb.

I do understand why it's beneficial in various contexts to have them 
compatible, but there are other ways to achieve database agnosticism 
that are probably a much better deal in the long run, e.g. "middleware" 
like ODBC, FireDac, etc.

Regards,
Kjell

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


------------------------------------------------------------------------------
DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps
OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
Free app hosting. Or install the open source package on any LAMP server.
Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk
Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel

Reply via email to