Subject | Re: Grave problem with UDFs and DATEs |
---|---|
Author | Lele Gaifax |
Post date | 2002-02-06T14:21:27Z |
On Wed, 06 Feb 2002 10:24:45 +0100, Helen Borrie wrote:
are still dialect 1. The fact that the old dll works great is of course
related to that. All the UDFs used to get a "DATE" parameter, that
explain the PISC_QUAD type used in the Pascal code, parsed by
isc_decode_date().
I'm going to inline the isc_decode_date in the meantime... :-/
bye, lele.
> At 02:11 PM 06-02-02 +0100, Lele Gaifax wrote:Yes, I do know the matter. But I'm NOT changing dialect on my DBs!! They
>>Hi all,
>>
>>I have a tiny library of UDFs I wrote years ago, and it's still working
>>ok. I was even surprised when I discovered that the very same binary dll
>>was compatible with IB5, IB6 and FB1.
>>
>>But a few days ago, needing two more UDFs, I discovered that I'm not
>>anymore able to produce a working dll! No matter how I compile the
>>thing, the subset of functions related to DATEs fails miserably and
>>cause the server to crash!!
>
> Lele,
> Unfortunately, you are going to have to write new versions of your date
> UDFs if you are going to use them with Dialect 3 databases. The date
> types are all new for Dialect 3. For details, read the Migration Guide
> PDF document that is with the beta docs. You will now be parsing the
> old DATE type as TIMESTAMP; and DATE becomes a date-only (no time
> part). Your new UDFs of course will not work with Dialect 1 databases
> nor pre-6 versions of IB.
>
are still dialect 1. The fact that the old dll works great is of course
related to that. All the UDFs used to get a "DATE" parameter, that
explain the PISC_QUAD type used in the Pascal code, parsed by
isc_decode_date().
I'm going to inline the isc_decode_date in the meantime... :-/
bye, lele.