Hallo zusammen,
ich habe bei einem Kunden auf einer 64 bit maschine ein
firebird 2.1 für 32 bit laufen.

Sind dazu irgendwelche Kombatibilitätsprobleme bekannt?

Ich habe zb. folgendes Phänomen:
in einem Logfile in welches die ID per Trigger geschrieben wird fehlen zwischen
ID 207881 und 207885
die 3 IDs
Statt dessen stehen bei der unsortierten Ausgabe an dieser Stelle die IDS 208459, 208460 und 208461
Bei der Sortierung nach ID besteht obige Lücke, die 208xxx sind logischerweise an der richtigen Stelle.

hat jemand ne Idee oder Erklärung?

Vielleicht ein zeitliches oder Multitask Phänomen. Ein Task/Insert wird gestartet bekommt die nächste freie ID kurz darauf startet ein zweites Insert bekommt die folgende ID und ist aber eher fertig (weniger aufwendiges insert vielleicht) mit dem Insert. Steht daraufhin trotz größerer Nummer vor dem anderen Eintrag.

Aber sind nur Vermutungen.

Zitat von hitzi:

Vielleicht ein zeitliches oder Multitask Phänomen. Ein Task/Insert wird gestartet bekommt die nächste freie ID kurz darauf startet ein zweites Insert bekommt die folgende ID und ist aber eher fertig (weniger aufwendiges insert vielleicht) mit dem Insert. Steht daraufhin trotz größerer Nummer vor dem anderen Eintrag.

Aber sind nur Vermutungen.

kann ich mir so aber nicht vorstellen, da die "falschen" ids ja fast 600 Sätze weiter sind.
Das Datum dieser 3 "falschen" Sätze liegt übrigens auch einen halben Tag später.

Zitat:

Ich habe zb. folgendes Phänomen:
in einem Logfile in welches die ID per Trigger geschrieben wird fehlen zwischen
ID 207881 und 207885
die 3 IDs
Statt dessen stehen bei der unsortierten Ausgabe an dieser Stelle die IDS 208459, 208460 und 208461
Bei der Sortierung nach ID besteht obige Lücke, die 208xxx sind logischerweise an der richtigen Stelle.

Das musst Du näher erklären.
Was steht im Trigger?
Woher kommt die ID?
In welcher Art und Weise wird das Log beschrieben?

Gruß Borwin

folgender Trigger ( before însert)

markieren

Code:

AS
begin
  /* Trigger text */

  IF (NEW.USELOG_ID IS NULL) THEN
     NEW.USELOG_ID = GEN_ID(GEN_USELOG_ID,1);

end

die Logtabelle dient zum Loggíng verschiedener Aktivitäten und wird wie folgt geschrieben.

markieren

Code:

    FQuery1.SQL.clear;
     FQuery1.SQL.add('select ');
     FQuery1.SQL.add('*');
     FQuery1.SQL.add('from USELOG where ');
     FQuery1.SQL.add('USELOG_ID = :USELOG_ID');
     FQuery1.ParamByName('USELOG_ID').AsInteger := FUSELOG_ID;
     FQuery1.open; // liefert eine leere datenmenge
     FQuery1.append; // neuen Datensatz anhängen
     {wird vom DB-Trigger erledigt }
  // FQuery1['USELOG_ID']:= USELOG_ID;

     FQuery1['ARBEITSPLATZID']:= FARBEITSPLATZID;
     FQuery1['PROGRAMMNAME']:= FPROGRAMMNAME ;
     FQuery1['BENUTZER']:= FBENUTZER ;
     FQuery1['LOGWERT1']:= FLOGWERT1;
     FQuery1['LOGWERT2']:= FLOGWERT2;
     FQuery1['LOGWERT3']:= FLOGWERT3;
     FQuery1['INORDNUNG']:= FINORDNUNG;
     FQuery1['AENDERTIME']:= FAENDERTIME;
     FQuery1['AENDERER']:= FAENDERER ;
     FQuery1.post;

der Fehler ist bisher nur auf diesem einen System aufgetreten.
Auf allen 32-bit-Maschinen kann ich den Fehler nicht reproduzieren.

Hi,

um was für Trigger handelt es sich denn? Nur bei Connect/Disconnect Trigger gibts ne spezielle Transaction, der ganze Rest läuft innerhalb der Transaction, aus der sie raus gestartet wurden.
ALso 2 User: Einer trägt ein, speichert aber nicht - IDs sind belegt, 2. User trägt weiter ein und nach 4h hat User 1 seine Kaffeepause beendet und speichert dann...

Grüße

in dem Fall ist nur ein einziger User zum gleichen Zeitpunkt an der Arbeit.

Ergänzung:

in jedem Falle wird nach dem Schreiben des Logeintrag ein commit ausgeführt.

Hi Karl-Heinz

gut, dann nochmal: Um was für einen Trigger handelt es sich - denn auch mit einem User lässt sich das Verhalten nachspielen je nachdem wie die SOftware aufgebaut ist. z.B: die Software zweimal starten. Das Eingabefenster zweimal öffnen,.... usw.

der Trigger wurde beim Anlegen der Tabelle per Script im Ibexpert folgendermassen angelegt.

markieren

Code:

CREATE OR ALTER TRIGGER USELOG_BI0 FOR USELOG
ACTIVE BEFORE INSERT POSITION 0
AS
begin
  /* Trigger text */

  IF (NEW.USELOG_ID IS NULL) THEN
     NEW.USELOG_ID = GEN_ID(GEN_USELOG_ID,1);

end
^


SET TERM ; ^

ob es sich dabei um connect /disconnect-Trigger handelt kann ich nicht sagen.

Bei dem Trigger handelt es sich um keinen ON CONNECT / DISCONNECT Trigger, sondern wie aus dem Trigger-Body zu sehen ist, ein BEFORE INSERT Trigger für die Tabelle USELOG.

Da der Primärschlüsselwert durch einen Generator vergeben wird, können natürlich Lücken entstehen, wenn eine Insert-Operation durch ein Rollback zurückgesetzt wird. Nichts Ungewöhnliches.