Firebird Server wurde unerwartet beendet.

[tsteinmaurer]

Wenn es rein um die neuen Tracing-Fähigkeitne geht und wenn du dem Englischen mächtig bist, dann kannst du dir meinen Artikel reinziehen: http://www.ibphoenix.com/main.nfs?a=...ce_steinmaurer

Sonst hätt ich auch noch eine deutsche Fassung aus dem Entwickler Magazin.


lg,
Thomas

[MarcoWarm]

Zitat:

Zitat von tsteinmaurer (Beitrag 1055295)

Sonst hätt ich auch noch eine deutsche Fassung aus dem Entwickler Magazin.

Danke ... Englisch ist kein Problem :-)

Gruß
Marco

[MarcoWarm]

Zitat:

Zitat von tsteinmaurer (Beitrag 1055210)

den Einsatz eines Debug-Builds vorschlagen.

Nur die Frage, welcher Art die CrashDumps sein müssen. Ich hab (mangels DrWatson wie hier vorgeschlagen) das neue "Standardformat" WER (Windows Error Reporting) als Crash-Report bekommen. Ich hab nun keine Ahnung, ob das dem Dev-Team was nützt. Der Report enthält allerdings ein 150Mb Heapdump.

[tsteinmaurer]

Hallo,

hab dir eine persönliche Nachricht geschickt, dass wir das vielleicht Offline von dieser Liste abhandeln.

lg,
Thomas

[IBExpert]

Bei der FreeadhocUDF kann ich dir (leider) im 2009 Stand einige Bugs nennen, die den
Server kommentarlos zum Absturz bringen. Die sind auch schon gemeldet, aber trotzdem
nicht behoben. Das betraf in erster Linie die Stringverarbeitung, z.B. F_STRCOPY
Der Autor von der Freeadhocudf Lib hat mir im April 2009 bestätigt, den Fehler
gefunden zu haben und in der nächsten Version den beheben zu wollen. Blöderweise
gab es seit dem noch keine neue Version. Wenn du also irgendwo F_STRCOPY benutzt,
ersetze das durch F_MID, geht nahezu identisch, hat den Fehler aber nicht.

Ich verzichte überall wo es geht auf UDFs und da wo ich nicht wirklich drumherum komm,
mit Delphi nutze ich die eingebauten oder schreib ich die selber. Bei 32 Bit Windows war das
kein Problem, neuerdings aber lieber mit Lazarus, weil auch 64 Bit und andere Plattformen
verfügbar. Dazu zeige ich übrigens auch eine Session auf www.firebird-conference.com
in Bremen.

Ich würde übrigens das restart interval auf 0 sekunden setzen, warum soll der Dienst
60 Sekunden warten? und worauf? Je nach Aufbau eurer Software könnte man auf diesem
Wege auch über connection Probleme mit einem Autoreconnect transparent weiterarbeiten,
aber sobald datasets im Spiel sind wird das schwierig.

Kleine Korrektur: Es gab doch in 2009 noch eine neue Version, keine Ahnung ob da der
Fehler behoben war, weil ich seit April 2009 freiwillig die Freeadhoc nicht mehr
benutzt habe

[MarcoWarm]

Zitat:

Zitat von IBExpert (Beitrag 1055447)

Bei der FreeadhocUDF kann ich dir (leider) im 2009 Stand einige Bugs nennen, die den
Server kommentarlos zum Absturz bringen.

Na bravo. Also F_STRCOPY nutzen wir nicht. Aber verschiedene andere Funktionen schon. da müsste ich jetzt mal alle (z.Zt. 956) Stored Procs durchschaun. Plus die verschiedenen Anwendungen. Das dauert ne Weile. Und den Verzicht zu predigen .... grml .... das wird dann wohl die schwerste Überzeugungsarbeit.
IBExpert hatte dochmal versprochen eigene UDFs rauszubringen ;-) Ist das noch auf der "roadmap"?

Zitat:

Zitat von IBExpert (Beitrag 1055447)

Ich würde übrigens das restart interval auf 0 sekunden setzen, warum soll der Dienst
60 Sekunden warten? und worauf? Je nach Aufbau eurer Software könnte man auf diesem
Wege auch über connection Probleme mit einem Autoreconnect transparent weiterarbeiten,
aber sobald datasets im Spiel sind wird das schwierig.

Das mit dem restart werden wir wohl ändern. Datasets verwenden wir in der Regel nicht.
Danke erstmal für die neuen Anregungen. Ich werde mir mal die prozeduren, skripte und ibeblocks vornehmen... zumindest hab ich dann den Rest des Monats keine anderen Pflichten *lach*

Gruß
Marco

[IBExpert]

Zitat:

Zitat von MarcoWarm (Beitrag 1055486)

Na bravo. Also F_STRCOPY nutzen wir nicht. Aber verschiedene andere Funktionen schon. da müsste ich jetzt mal alle (z.Zt. 956) Stored Procs durchschaun. Plus die verschiedenen Anwendungen. Das dauert ne Weile. Und den Verzicht zu predigen .... grml .... das wird dann wohl die schwerste Überzeugungsarbeit.
IBExpert hatte dochmal versprochen eigene UDFs rauszubringen ;-) Ist das noch auf der "roadmap"?

Ich hoffe das wir auf der Firebird Konferenz eine erste Version schon mal publishen können, die wird dann auf Lazarus basieren. Aufgrund der sehr vielen eingebauten Funktionen in Firebird >=2.X brauch man viele Sachen aber gar nicht mehr aus einer UDF. Welche Prozeduren du benutzt siehst du wahlweise im Dependencies Viewer in IBExpert, oder mit dem sql unten am ende dieser nachricht.

Die UDFs dann in den Stored Procs zu ersetzen ist aber vergleichsweise simpel mit ibexpert. Einfach mit tools-extract metadata die prozeduren extrahieren, Das script enthält dann alle Prozeduren mit CREATE OR ALTER im Header. Auf dieser Script Datei kannst du dann ggf im Script executive per Suchen-Ersetzen einfach alle "F_...(" durch "xxx(" ersetzen, sofern
die jeweilige F_... Funktion ein eingebautes Äquivalent hat, ist aber bei vielen Funktionen gegeben. Danach dkannst du das Script einfach im Script executive laufen lassen, weil ja nicht gedropt werden muss. Alle Prozeduren werden dann mit alter wieder eingespielt und ersetzen die alten Versionen.


hier zum Beispiel die Abhängigkeiten für F_ABS

SQL-Code:

select
distinct
D1.RDB$DEPENDENT_NAME,
D1.RDB$DEPENDED_ON_NAME
from RDB$DEPENDENCIES D1
left join rdb$relations r1 on ((D1.RDB$DEPENDENT_NAME = r1.rdb$relation_name) and (not (r1.Rdb$View_Blr is null)))
where (D1.RDB$DEPENDED_ON_TYPE = 15)
and (D1.RDB$DEPENDENT_TYPE <> 3)
and (D1.RDB$DEPENDED_ON_NAME = 'F_ABS')
union
select
distinct
f2.rdb$relation_name,
D2.RDB$DEPENDED_ON_NAME
from rdb$dependencies d2, rdb$relation_fields f2
left join rdb$relations r2 on ((f2.rdb$relation_name = r2.rdb$relation_name) and (not (r2.Rdb$View_Blr is null)))
where (d2.rdb$dependent_type = 3) and
(d2.rdb$dependent_name = f2.rdb$field_source)
and (d2.rdb$depended_on_name = 'F_ABS')
order by 1, 2

[MarcoWarm]

Zitat:

Zitat von IBExpert (Beitrag 1055647)

Aufgrund der sehr vielen eingebauten Funktionen in Firebird >=2.X brauch man viele Sachen aber gar nicht mehr aus einer UDF.

Leider müssen wir organisationsbedingt (=das liegt nicht in meiner Hand) noch einen Interbase 2007 Server in der Replikation mitschleppen.

OT - ich weiß das ist absolut nicht nötig und die Umstellung auf FB (falls überhaupt erforderlich) dauert auch weniger als ne Woche ... aber was ich da schon geredet habe *kopfschüttel*

Das bedeutet natürlich auch, daß wir sämtliche Metadaten replizieren, damit wir die Stored Procs nicht doppelt pflegen müssen - damit sind dann auch Features wie CHAR_LENGTH() passe. Ich denke jetzt hab ich ein Argument den IB endlich abzuschalten *freu*, vielen Dank :thumb:.

Werden die IBExpert UDFs dann quelloffen sein?

Gruß
Marco

[IBExpert]

Zitat:

Zitat von MarcoWarm (Beitrag 1055684)

Werden die IBExpert UDFs dann quelloffen sein?

jo, das ist so vorgesehen