Firebird 2.51 und UDF's

[Jörg Buhren]

Hallo zusammen

nachdem ich mehrere Jahre problemlos FB 1.5 eingesetzt habe, muss ich mich wegen der 64Bit Server nun auch mal mit einer neueren FB Version auseinandersetzten. Soweit so gut, aber bei den UDF's hab ich mich wohl festgebissen. Die UDFs haben sich im Laufe der Zeit angesammelt und laufen unter FB 1.5 problemlos.
Bei 2.51 zerlegt es den FB Server , sobald eine UDF einen String zurückliefert, bei den anderen UDF's sehe ich bisher keine Problem.
Hier ein Beispiel, bei dem auch das neue NULL-Feature keine Rolle spielen sollte

Die C Funktion:
char * EXPORT bs_dt2str(long *_dt)
{
char *dt_ptr;
int j,
m,
t;
long hlf;
long dt = *_dt;

dt_ptr = (char *) ib_util_malloc(20);

j = (int) (dt / 10000);
hlf = (ULONG) j * 10000;

dt -= hlf;
m = (int) (dt / 100);
t = (int) (dt % 100);

sprintf(dt_ptr, "%02d.%02d.%d", t, m, j);

return dt_ptr;
}

Und hier die SQL-Deklaration:
DECLARE EXTERNAL FUNCTION dt2str
INTEGER
RETURNS CSTRING(20) FREE_IT
ENTRY_POINT 'bs_dt2str' MODULE_NAME 'bisudf';


Vom Inhalt her soll sie nur ein internes Datumsformat JJJJMMTT nach TT.MM. JJJJ wandeln und als String zurückgeben, was sie unter 1.5 auch schon seit Jahren macht. Rufe ich die Funktion mit

select dt2str(20140825) from rdb$Database

auf, stürzt der fbServer ab und in der LOG steht nur:
VM_XP (Client) Sun Aug 24 23:23:01 2014
"C:\Prog\firebird\Firebird_2_5\bin\fbserver.ex e": terminated abnormally (4294967295)

Ich hab die neuste mitgelieferte IB_Util_MS lib verwendet, aber die Verwendung von malloc oder ib_util_malloc
bringt keinen Unterschied.

Hat da jemand eine Idee, woran es noch liegen könnte. oder was noch zu beachten ist ?

Oder kann FB 2.5 keine CStzrings mehr und die Rückgabe muss als varchar erfolgen ? Gelesen hab ich davon allerdings nichts.

[defo]

Hallo,

ich hab keine Ahnung von C, aber hast Du Dir schon mal überlegt, wie weit Du mit Standardfunktionen kommst?
Euer "internes" Datumsformat sieht so aus, als ob es unproblematisch mit Konvertierung erledigt werden könnte.

[Jörg Buhren]

Hallo,

ich hab keine Ahnung von C, aber hast Du Dir schon mal überlegt, wie weit Du mit Standardfunktionen kommst?
Euer "internes" Datumsformat sieht so aus, als ob es unproblematisch mit Konvertierung erledigt werden könnte.

danke für deine Antwort. Aber um mal kurz OT zu gehen:
zum einen ist es kein ursächliches C-Problem, das C-Modlülchen läuft so unverändert seit ca 2005
zum zweiten ist das TDateTime Format die Hölle, wenn du im internationalen Raum zu tun hast, bei MS Datenbanken wird jedem geraten, immer sein eigenes Datumsformat zu benutzen, und das aus gutem Grunde ... aber darüber können wir sicherlich woanders diskutieren
zum dritten gehts hier gar nicht um Datumsfelder, das war nur ein Beispiel, bei dem die UDF nachvollziehbar den Server abschießt, eine SubStr-Funktion oder eine Verknüpfung 2er Strings oder ein Umwandeln eines Strings in Gross/Klein bringt die gleichen Probleme

[defo]

mal kurz OT:
zum einen ist es kein ursächliches C-Problem, das C-Modlülchen läuft so unverändert seit ca 2005
zum zweiten ist das TDateTime Format die Hölle, wenn du im internationalen Raum zu tun hast, bei MS Datenbanken wird jedem geraten, immer sein eigenes Datumsformat zu benutzen, und das aus gutem Grunde ... aber darüber können wir sicherlich woanders diskutieren
..
das war nur ein Beispiel, ..eine SubStr-Funktion oder eine Verknüpfung 2er Strings oder ein Umwandeln eines Strings in Gross/Klein bringt die gleichen Probleme

Ok, zum eigentlichen Problem kann ich dann nichts beitragen.
Zu dem Exkurs TDatetime würde ich mal pauschal sagen, das Problem kann ich nachvollziehen, die Schlussfolgerung halte ich für total verkehrt. Aber das dann halt wohl an anderer Stelle.