Hi,

After a day's worth of debugging, I've come to the conclusion that this is likely a FB bug. If so, let me know where to post it, and I'll stick it in its proper place to one day be fixed. Here's the issue:

Initially, we had a function called GetOccurenceDate. Note that Occurrence is misspelt. The function declaration was as follows:

DECLARE EXTERNAL FUNCTION GET_OCCURRENCE_DATE
Date, Integer, Integer
RETURNS Date BY VALUE
ENTRY_POINT 'GetOccurenceDate'
MODULE_NAME 'DmxUDF.dll';

So one would think that fixing this is a no-brainer and just add the miss "r". But this causes this function to essentially go into some weird limbo-land.

when I change it, so it reads:
ENTRY_POINT 'GetOccurrenceDate'
and with the appropriate changes to the DLL of course, the new GetOccurrenceDate function in the DLL is never called. A break point and various OutputDebug confirm this. But if GetOccurrenceDate is removed from the DLL entirely, FB complains with a BLR error as you would expect.

FWIW, I test our function by calling it as follows:

SELECT GET_OCCURRENCE_DATE(Cast('31.12.2010' as Date), 1, 3)
FROM RDB$DATABASE

If the function is actually working, this will produce a date of 2 Feb 2011. If it fails, it returns a date back int he 1800s, usually around 1858 but not always.

What is so strange, is that it seems to think the function is valid, but it doesn't call it, which explains the dates back from the wild wild west!

My guess is that this problem has something to do with BLR not being properly recompiled. The very strange thing is - if I rebuild the DB from our initial install script - i can still make it fail.

So I've decided that this typo is a "feature" and reverted back the code, so the Entry Point refer to GetOccurenceDate rather then GetOccurrenceDate and all works fine again.

Now, which FB God would like to know of this bug?

cheers,
-randall sell





[Non-text portions of this message have been removed]