Umstellung Paradox -> interbase. SNR handhabung

[Sven Janssen]

Hallo,

wir stellen unsere Software von Paradox auf Interbase um. Dazu habe ich mit IBPump die Datenstruktueren übernommen und diese modifiziert. Wir haben bei einigen Dateien eine SNR benutzt die sie sich automatisch hochzählt.
IBPump hat für diese Felder einen Trigger und ein Generator erstellt.
Nur wie füge ich nun einen Datensatz hinzu? Ich erhalte die Meldung das dieses Feld nicht leer sein darf. Aber wie fülle ich es? Wie muss die InsertSQL Anweisung des TIBDatasets aussehen?
Oder gibt es eine bessere Alternative für diesen Fall?

Gruß Sven

[mkinzler]

Das Feld darf nich Teil des Inserts sein

Bsp.

TabA:
ID
Name
Vorname

SQL-Code:

Insert into TabA( Name, Vorname) values ( 'Hans', 'Müller');

[Sven Janssen]

Hatte ich mir auch gedacht. Gibt aber die gleiche Fehlermeldung.
"Das Welt xyz muß einen Wert haben."

[mkinzler]

Zitat:

Wie muss die InsertSQL Anweisung des TIBDatasets aussehen?

Wie sieht diese jetzt aus?

Vielleicht wäre es hier besser einen normalen Query zu nehmen.

[hoika]

Hallo,

willkommen im Club der Pdx-IB-Umsteller. ;)

Lösung :

Erstelle für jede Tabelle eine Stored Procedure mit folgendem Inhalt

SQL-Code:

CREATE PROCEDURE BILL_COSTCENTER_NEWID 
RETURNS (
    NEWID INTEGER)
AS
begin 
  newid=gen_id(Gen_Bill_CostCenter,1); 
end

Gen_Bill_CostCenter ist ein Generator.

Diese Stored Procedure ruft du VOR jedem Insert auf.
Der Generator stellt sicher, dass du immer einen neuen Werte bekommst
(quasi AUTOINC in Interbase).

Der Aufruf erfolgt etwa wie folgt (das Bsp geht davon aus, dass alle Generatoren
wie ihre Tabelle selber heissen)

Delphi-Quellcode:

{
  Name:
    Table_GetNewId__DB
  Zweck:
    neue Id über stored proc erzeugen
  Parameter:
    theDataBaseName - database name
    theTableName    - Tabellenname
  Return-Parameter:
    theNewId    - die neue Id
    theErrorStr - Fehlermeldung
  Return:
    False bei einem Fehler
  Hinweis:
}
function Table_GetNewId__DB(const theDataBaseName, theTableName: String;
  var theNewId: Longint; var theErrorStr: String): Boolean;
var
  SP: TStoredProc;
begin
  Result:= False;

  theNewId:= -1;
  theErrorStr:= '';

  try
    SP:= TStoredProc.Create(NIL);
    try
      SP.DataBaseName:= theDataBaseName;
      SP.StoredProcName:= UpperCase(theTableName)+'_NEWID';
      SP.ExecProc;

      theNewId:= StrToInt(SP.Params[0].AsString);

      Result:= True;
    finally
      SP.Free;
    end;
  except
    on E: Exception do
    begin
      theErrorStr:= E.message;
     {$IFDEF DEBUG}
      MBDebug(sFormName+'Table_GetNewId__DB'+#13#10+theTableName+E.message);
     {$ENDIF}
    end;
  end;
end;  { Table_GetNewId__DB }

Heiko
PS:
Den Trigger würde ich komplett rauslöschen.

[Sven Janssen]

Liest sich gut, liest sich aber nach viel schreibarbeit :-)
btw. mit TIBSQL funktioniert das ganze. Mit TIBDataSet nicht.
Ich schau mir das dennoch mal genauer mit der StoredProc an.

Sven

[hoika]

Hallo,

Schreibarbeit beim SP-Erzeugen, oder um das umzustellen ?
Den Aufwand hast du eh.
Dann kommt noch das Ersetzen aller TTable in TQuery hinzu,
das Ersetzen von SetRange (vor allem das CancelRange)
(Frage mich beim nächsten Performance-Problem mal wieder ;) )

Ich würde auf jeden Fall auch ein paar Testdaten anlegen,
um nicht nach der Umstellung Fehler zu haben.
Ausserdem solltest du Dialect 3 statt der 1 benutzen,
dann kannst du deine DATE und TIME weiterverwenden
(Dialect 1 hat ja nur DATE ).

Aber das Endergebnis:
- index out of date weg
- blob error weg

-> zufriendene Kunden


Heiko

[Jürgen Thomas]

Zitat:

Zitat von Sven Janssen

IBPump hat für diese Felder einen Trigger und ein Generator erstellt.

Dieser Trigger müsste praktisch identisch aussehen wie folgender Vorschlag:

Zitat:

Zitat von hoika

Lösung : Erstelle für jede Tabelle eine Stored Procedure mit folgendem Inhalt:

SQL-Code:

CREATE PROCEDURE BILL_COSTCENTER_NEWID 
RETURNS (
    NEWID INTEGER)
AS
begin 
  newid=gen_id(Gen_Bill_CostCenter,1); 
end

Gen_Bill_CostCenter ist ein Generator.

Heiko
PS: Den Trigger würde ich komplett rauslöschen.

Nein, der Trigger ist genau die IB-interne Lösung für eine Stored Procedure, die automatisch ausgeführt wird (und nicht erst vom Delphi-Programm aus aktiviert werden muss):

SQL-Code:

CREATE TRIGGER BILL_COSTCENTER_Before_Insert_0 FOR BILL_COSTCENTER
ACTIVE BEFORE INSERT POSITION 0
AS BEGIN
  IF ( New.ID IS NULL)
  THEN New.ID = GEN_ID( Gen_Bill_CostCenter, 1);
END

Also schau Dir einmal an, was IBPump gemacht hat, und übernimm bzw. überarbeite diese Vorschläge. Jürgen

[Sven Janssen]

Zitat:

Zitat von hoika

Hallo,

Schreibarbeit beim SP-Erzeugen, oder um das umzustellen ?
Den Aufwand hast du eh.
Dann kommt noch das Ersetzen aller TTable in TQuery hinzu,
das Ersetzen von SetRange (vor allem das CancelRange)
(Frage mich beim nächsten Performance-Problem mal wieder ;) )

Wir schreiben alles neu.
Wir hatten schoneinmal damit begonnen und versucht das irgendwie umzuschreiben, aber das war alles Käse. Zwischenzeitlich hatten wir so viele Aufträge das wir nicht weitermachen konnten. Aber die Zeit drängt und daher habe ich nun wieder angefangen. Die kleinen Apps haben wir gelassen ( von der ersten Umstellung), die großen Programme werden umgeschrieben. Sind auch ein paar tausend Zeilen.

Zitat:

Zitat von hoika

Ich würde auf jeden Fall auch ein paar Testdaten anlegen,
um nicht nach der Umstellung Fehler zu haben.
Ausserdem solltest du Dialect 3 statt der 1 benutzen,
dann kannst du deine DATE und TIME weiterverwenden
(Dialect 1 hat ja nur DATE ).

Wir haben schon ein Konvertierungsprogramm geschrieben. War mir wichtig direkt mit den großen fetten DBs unserer Kunden zu testen und nicht mit 10-20 Datensätze.

Zitat:

Zitat von hoika

Aber das Endergebnis:
- index out of date weg
- blob error weg

Das uns mehr performance und fernverbindungen sind uns sehr wichtig.

[hoika]

Hallo Sven,

mit Tests meinte ich nicht nur Performance-Tests,
sondern vor allem Korrektheit-Tests.
Nicht dass bei der Umstellung neue Fehler eingebaut werden.


Heiko