MSSQL Replikation

[jobo]

Ich habe nie verstanden, warum man diese Technik nutzt (oder sogar warum es sie gibt).
"Gib mir mal die letzte ID -von wem ist mir egal .. "
Es gibt auch glaub ich niemand, der das empfiehlt.

Es gibt m.E. in allen nennenswerten DB Engines eine RETURNING Clause oder Vergleichbares.
Bei MS SQL ist es OUTPUT.spaltenname [into @Variable].
Man bekommt also definierte Werte zurück oder schreibt sie in Variablen (innerhalb T-SQL).

Konkretes Beispiel

Delphi-Quellcode:

>select @@version;
>
>(No column name)
>--------------------------
>Microsoft SQL Server 2014 (SP3-CU-GDR) (KB4535288) - 12.0.6372.1 (X64) 
>
>create table person (
  person_id int identity(1,1),
  last_name varchar(255) NOT NULL,
  first_name varchar(255),
  age int);
>
>insert into person (first_name, last_name ) values('test 1','test'),('test 2','test'),('test 3','test');
>
>
>select * from person;
>
>person_id | last_name | first_name | age
>---------------------------------------------------
 1         | test      | test 1     | null     
 2         | test      | test 2     | null
 3         | test      | test 3     | null
>
>insert  person ( first_name, last_name) 
 OUTPUT INSERTED.person_id
 values('test 1','test');
>
>person_id | 
>------------
 4         |
>
>insert  person ( first_name, last_name) 
 OUTPUT INSERTED.person_id, INSERTED.first_name, INSERTED.last_name
 values('test 1','test');
>
>person_id | first_name | last_name 
>-----------------------------------
 5         | test 1     | test

Den Praxiseinsatz kenne ich nicht, da ich MS SQL nicht nutze. Nur von anderen Anbietern.
Im SP Bereich ist es sehr komfortabel einsetzbar.

Im (Delphi) Client muss man sich dran gewöhnen, ein Insert auf seine Rückgabewerte zu behandeln und ist glücklich.

Also vielleicht lohnt sich ein Test bei Dir oder dann der Umbau wenigstens der kritischen Stellen.

[haentschman]

Moin...

@jobo: ...mein geliebtes "returning" auch im MSSQL.

...ich habe mal was probiert (was funktioniert):

Variante 1:

1. Insert Statement absetzen (ExecSQL)
2. Query: 'select IDENT_CURRENT(Bla) as LastID' absetzen
3. LastID := Query.FieldByName(LastID).AsInteger

Variante 2:

1. "Script" mit Query.Open
2.

Code:

declare @LastID table (LastID int)

insert into Bla 
  (Blubb) 
OUTPUT INSERTED.ID into @LastID 
  values 
  (99)

select LastID from @LastID

3. LastID := Query.FieldByName('LastID').AsInteger (gleiche Query )

PS: nur OUTPUT INSERTED.ID läuft in einen Fehler:

Zitat:

Für die Bla-Zieltabelle der DML-Anweisung dürfen keine Trigger aktiviert sein, wenn die Anweisung eine OUTPUT-Klausel ohne INTO-Klausel enthält

Die Replikation legt aber reichlich Trigger an.


Welche Variante würdet ihr bevorzugen?

Imho ist die sicherste die Variante 2. Bedeutet aber auch, das alle insert Statements anpaßt werden müssen. (23 aktuell)

Danke...

[jobo]

Wenn es solche Einschränkungen bei OUTPUT gibt, würde ich es erstmal mir einer Replikationstabelle als Test ausprobieren, bevor ich alles umbaue.
Sieht irgendwie nach der Frage des kleineren Übels aus.

[haentschman]

Moin...

Zitat:

bevor ich alles umbaue.

...bei mir war das zügig erledigt. Ich habe mich für Variante 2 entschieden.

[Werbung ON]
Vieleicht hat mir geholfen daß ich die SQL in Dateien/Ressourcen gespeichert habe. Damit gab es "quasi" keinen Umbau am Quelltext. Siehe Bild...

Quelltext Old:

Delphi-Quellcode:

function TDatabaseBase.GetLastId: Integer;
begin
  Result := FConnection.GetLastAutoGenValue('');
end;
...
function TDatabase.Write(User: TSEAMUser): Integer;
var
  Qry: TFDQuery;
begin
  Result := -1;
  Qry := CreateQuery;
  try
    case User.State of
      sdsNew:
      begin
        Qry.SQL.Text := GetSQLByName('COM_INSERT_USERS');
...
        Qry.ParamByName('ACC').AsInteger := User.AccessCount;
        Qry.ExecSQL;
        User.ID := GetLastId;
        Result := User.ID;
      end;
      sdsModified:
      begin
        Qry.SQL.Text := GetSQLByName('COM_EDIT_USERS');
        Qry.ParamByName('ID').AsInteger := User.ID;
        Qry.ParamByName('ROI1').AsInteger := User.Role_1.ID;
...

Quelltext New:

Delphi-Quellcode:

function TDatabaseBase.InsertWithGetLastID(Query: TFDQuery): Integer;
begin
  Query.Open;
  Result := Query.FieldByName('LastID').AsInteger;
end;
...
function TDatabase.Write(User: TSEAMUser): Integer;
var
  Qry: TFDQuery;
begin
  Result := -1;
  Qry := CreateQuery;
  try
    case User.State of
      sdsNew:
      begin
        Qry.SQL.Text := GetSQLByName('COM_INSERT_USERS');
...
        Qry.ParamByName('ACC').AsInteger := User.AccessCount;
        User.ID := InsertWithGetLastID(Qry);

        Result := User.ID;
      end;
      sdsModified:
      begin
        Qry.SQL.Text := GetSQLByName('COM_EDIT_USERS');
        Qry.ParamByName('ID').AsInteger := User.ID;
        Qry.ParamByName('ROI1').AsInteger := User.Role_1.ID;
...

Danke nochmal.

[jobo]

Zitat von haentschman:

Moin...

Zitat:

bevor ich alles umbaue.

...bei mir war das zügig erledigt. Ich habe mich für Variante 2 entschieden.

[Werbung ON]
Vieleicht hat mir geholfen daß ich die SQL in Dateien/Ressourcen gespeichert habe. Damit gab es "quasi" keinen Umbau am Quelltext. Siehe Bild...
..

Gut! Geordnete Strukturen, Trennung von Persistenz, Verhalten und GUI machen eine solche Umstellung mit Sicherheit sauberer und robuster.
Mein Hinweis zum Umbau galt eher der Problematik eines dosierten Funktionstests bzw. dann auch Praxistests rund um die Replikation. Die "Randbedingungen" bzw. Einschränkungen bei der Funkiont OUTPUT scheinen mir entgegen meiner Empfehlung nicht besonders sexy. Und da fehlt mir selbst die Praxiserfahrung mit MS SQL. Wenn ich mich nicht irre, war die Doku, die ich nach Deiner Trigger Problematik angeschaut hatte, halbwegs aktuell (SQL Server 2019), aber voller Einschränkungen.
Ich hoffe es funktioniert im Realbetrieb besser als die IDENTITY Verfahren!

[Uwe Raabe]

Zitat von haentschman:

Vieleicht hat mir geholfen daß ich die SQL in Dateien/Ressourcen gespeichert habe.

Wenn man es genau nimmt, dann speichert derjenige, der das SQL z.B. im gleichnamigen TFDQuery-Property einträgt, das ja auch in einer Ressource:

Delphi-Quellcode:

{$R *.dfm}

[jobo]

Zitat von Uwe Raabe:

Zitat von haentschman:

Vieleicht hat mir geholfen daß ich die SQL in Dateien/Ressourcen gespeichert habe.

Wenn man es genau nimmt, dann speichert derjenige, der das SQL z.B. im gleichnamigen TFDQuery-Property einträgt, das ja auch in einer Ressource:
..

Let's get nerdy!
Uwe hat Recht, aber da würde ich anmerken, Ressource ist nicht gleich Ressource.
Wenn man ausschließlich mit Delphi arbeitet, spielt der Zugang und die Änderbarkeit der Ressourcen nicht so eine große Rolle. Im Gegenteil, manchmal ist ja die Möglichkeit, alles in einer Anwendung zu integrieren (und as is auszuliefern) auch sehr gewollt und mit der resultierenden Statik auch besonders robust.
Bedeutet aber auch, dass Ressourcenänderungen mit der Neukompilation und Verteilung verbunden sind (außer, man fährt da mehrgleisig, womit der Faktor Robustheit an der Stelle aber auch hops geht.)
Ich kenne die Komponenten von haentschan nicht, aber Zugängigkeit und Dynamik der (ausgelagerten) Ressourcen sehe ich jedoch als wichtigen Faktor. Und mal kurz durchgespielt: Wenn ich mit transparent zugängigen, externen Ressourcen loslege, ist es aus dieser Richtung auch nicht sehr aufwändig, bei Bedarf Ressourcen zu embedden, automatisert und mir klaren Verantwortlichkeiten. Da würde mir ein Ressourcenmanager wie von haentschman wahrscheinlich besser gefallen, als ein *.dfm.

[haentschman]

Zitat:

Ich kenne die Komponenten von haentschan nicht

...keine Komponenten. Einfach SQL Files die eingebunden werden.
Anleitung:
https://www.delphipraxis.net/49505-s...einbinden.html

Zitat:

besser gefallen, als ein *.dfm.

...sucht sich leichter und ist von der verwendeten Komponente nicht abhängig.