Dienstag, 15. April 2014

AvERP 2014.04

Verlautbarung von SYNERPY am 15.04.14:

"Heute wird im Laufe des Tages AvERP 2014.04 im Downloadbereich unserer Webseite online gehen.
Im August ist wieder das neue Release geplant. Darin werden dann aktuelle Entwicklungen, wie zum Beispiel die Kasse für den Fachhandel mit Filialunterstützung und Datenbankreplikation enthalten sein.
Vom 8.-10.10.2014 sind wir wieder auf der IT & Business in Stuttgart und werden dort das neue Release präsentieren.

AvERP-Notizen:
AvERP ist grundsätzlich fit für SEPA. IBAN und BIC werden nach der allgemein gültigen Regel generiert. Leider gibt es einige Banken, die eigene (sehr unterschiedliche) Wege gehen. Diese Ausnahmen müssen grundsätzlich manuell abgeändert werden. Wir versuchen jedoch bei den wichtigsten Banken noch eine programmierbare Regel zu finden. Deutsche Bank, Dresdner Bank und Commerzbank beispielsweise sind solche Ausnahmen, die aber bereits mit einer eigenen Regel integriert werden konnten.
Wir haben einen öffentlichen Demozugang für WebAvERP angelegt. Die Zugangsdaten werden beim Aufruf bereits vorgeben. Sehen Sie es aber bitte immer noch als öffentliche Beta-Version, nicht als Release."

Mittwoch, 2. April 2014

Errcode: -902 : Panik !!! internal Firebird consistency check

Zum Umgang mit einer korrupten Firebird-Datenbank

Errcode: -902 (KEINE???) PANIK
Unable to complete network reguest

internal Firebird consistency check (can't continue after bugcheck)
DANN ist wirklich PANIK angesagt!

 

Folgendes Szenario:
Beim Verlassen von AvERP erscheint;

Meldung von der AvERP-Datenbank
Errcode: -902

Error Message:
internal Firebird consistency check (can't continue after bugcheck)
Component: TIB_Query (q_V_BFIRMA)
SQL.Text: SELECT * FROM V_BFIRMA

Bei nächsten Startversuch:

Meldung von der AvERP-Datenbank
Errcode: -902

Error Message:
Unable to complete network reguest to host "localhost"
Failed to establish a connection.
Component: TIBCConnection


Ähnliche Effekte beim GUI-"Experten" 

Anmerkung:
Errcode -902 kommt grundsätzlich, wenn die Datenbankverbindung zwischen AvERP-Client (dem AvERP-EXE-Programm) und dem Firebird-Server unterbrochen worde. Ursache kann eine harmlose Unterbrechung der Netzwerk-Verbindung sein. Erst wenn ein Beenden der defekten Session mit Neustart der AvERP-exe nicht fruchtet - dann ist
PANIK angesagt!

Im Panik-FALL:

Hilft  nur noch Firebird Guardian / Server über die Verwaltung des glücklicherweise(local)  Hosts zu stoppen und erneut zu starten.

Nun mutig per GUI "Database Validation" aufgerufen, arbeite ja glücklich mit einer lokalen Kopie einer produktiven Datenbank.

Nächster Schock:
Connection error.
bad parameters on attach or create databse.
secondary server attachments connot validate databases.



Kurze Internet-Recherche zeigt:

gfix möchte gerne die Datenbank für sich haben.

Es dürfen keine anderen attachments / DB-Verbindungen aktiv sein!


Weder als AvERP,  JobSERVER noch mit dem GUI-Experten, wo man ja gerne nachsieht, ob man überhaupt noch an die Datenbank herankommt.

Danach zeigt gfix Database Validation full das ganze Drama:




Lösung: Backup und Restore

Doch gleich droht die nächste Panik:
Das Backup bricht ab, wenn die Garbage Collection durchgeführt wird.



 Auch das kann gelöst werden, wenn man weiß worauf es ankommt :)

Die Garbage-Collection ist sinnvoll um die gerade gesicherte Datenbank aufzuräumen. Da ich aber plane die korrupte Datenbank über ein RESTORE des gerade zu machenden BACKUPs zu ersetzen, ist die per Default beim Backup aktivierte Garbage-Collection einfach überflüssig!

Wieder stürzt hier der Firebird-Server ab! Und auch der GUI-Experte schmeißt so viele
internal Firebird consistency check (can't continue after bugcheck), das nur der WIN-Taskmanager Abhilfe schaffen kann!

Mit der Strategie BACKUP 
-G inhibit garbage collection
-IG ignore checksum errors
-L ignor transactions in limbo

war ich auf dem produktiven Server erfolgreich.

Beim nachvollziehen auf einem lokalen WIN7 Firebird nicht!!!

Erst nach einer Validierung mit MEND-Option lief auch anschließend das BACKUP durch.

Vor Validation mit gfix -MEND sein jedoch gewarnt!

Freundlich wird zwar versprochen:
        -mend           prepare corrupt database for backup
Allerdings weiß man nicht, welche Daten dem -mend zum Opfer fallen.

Besser ist es ein automatisches BackUp zu verwenden, so daß sich ein definierter Datenverlust auf die in der Zeitspanne zwischen letzten erfolgreichem BACKUP und Entdeckung des Problems beschränkt. 

Warum war die Firebird-Datenbank korrupt?

Spekulation: Auf den Datenbank-Server fand ich 10 AvERP-JOBSERVER vor, die alle mit LOCK im Job BBVO Disposition Bestellvorschläge stehen geblieben waren. Sollten diese das Chaos angerichtet haben??

Etwas stütz diese Hypothese die ca. 800.000 Total Dup Einträge zum Index BARTLH_BBVO_DATETIME