MSSQL Replikation

[haentschman]

8-)
[neue Frage]
Ich habe auf dem Live System NUR eine Veröffentlichung erstellt. Der Snapshot wird aller 5 Minuten ausgeführt...ohne Probleme.
An dieser Veröffentlichung hängt noch kein Abonnent dran.

Fehler beim normalen Speichern (SQL) eines komplexen Objektes innerhalb einer Transaktion:

Zitat:

exception message : [FireDAC][Phys][ODBC][Microsoft][SQL Server Native Client 11.0][SQL Server]Ein Rollback für SP_3 kann nicht ausgeführt werden. Es wurde keine Transaktion oder kein Sicherungspunkt mit diesem Namen gefunden.

vereinfacht:

Delphi-Quellcode:

begin
  Qry := CreateQuery;
  try
    Transaction := TFDTransaction.Create(nil);
    try
      Transaction.Connection := FConnection;
      Qry.Transaction := Transaction;

      Transaction.StartTransaction;
      try
        case Receipt.State of
          sdsModified:
          begin
            Qry.SQL.Text := GetSQLByName('XXX_UPDATE_ID');
            Qry.ParamByName('ID').AsInteger := Receipt.ID;
            FillParameters; 
            Qry.ExecSQL;
            WriteLists; //wieder SQL für Detail Objekte
          end;
        end;
        Transaction.Commit;
      except
        Transaction.Rollback;
      end;
    finally
      Transaction.Free;
    end;
  finally
    Qry.Free;
  end;
end;

PS: es gibt keine SP_3. In Fehlermeldungen später war es auch u.a. SP_2. :roll:

..nach Entfernung der Veröffentlichung wird wieder normal gespeichert. :?

Nach was muß ich suchen? :gruebel:

[rokli]

Neuer Gedanke
Status in den Tabellen:

Status = 0 > neuer Datensatz ... System1 darf verarbeiten

System 1 liest ein und setzt Status danach = 10
Status = 10 > System1 hat verarbeitet

System 2 liest ein und setzt Status danach = 20
Status = 20 > System2 hat verarbeiten

So weißt du immer, wer das schon bearbeitet hat und wer nicht ...

[haentschman]

Danke für deine Idee. :thumb:

Inzwischen habe ich herausgefunden, daß diese Meldung das Ergebnis einer vorgehenden Feldermeldung ist. :? Da muß ich weiter suchen... :wink:

[jobo]

Sowohl uns als auch Dir bleibt der SQL Code inkl. Parameter verborgen.

Code:

            Qry.SQL.Text := GetSQLByName('XXX_UPDATE_ID');
            Qry.ParamByName('ID').AsInteger := Receipt.ID;
            FillParameters;

Wie wäre es, das finale Statment oder Params getreten zu loggen und wenn einem der Fehler nicht ins Auge springt, dann zu Fuß auf die DB loslassen?

Wenn es kein SP2, SP3 gibt und das so schick dynamisch ist, klingt es ein wenig, als ob da Werte reinlaufen, die beim Parsen / Quoten versehentlich zu SQL werden, statt Parameter zu bleiben.

[haentschman]

Moin...

Zitat:

Wie wäre es, das finale Statment oder Params getreten zu loggen

PS: Das Statement funktioniert und ist hunderte Mal täglich im Einsatz. Mir war klar das das mit der "Aktivierung" der Replikation zu tun hat.

Zitat:

Sowohl uns als auch Dir bleibt der SQL Code inkl. Parameter verborgen.

...mir nicht. Euch wollte ich die 280 Zeilen Statement nicht antun. :zwinker:
Auszug:

Code:

update XXX set
   Nummer = :ZGIWB
  ,DatumBeleg = :OGMIT
...
  ,DATEV = :PDSOS
  where ID = :ID

Ich bin gerade dabei die DB anzupassen und den Quelltext zu korrigieren. Im Quelltext gab es eine Anweisung die die Replikationsspalte per Update geändert hat. Das ist nicht zulässig! Der obige Fehler ist u.a. das Ergebnis hieraus...:zwinker:

Trotzdem Danke...:cheers:

[jobo]

Na nichts zu danken, es war ja sowieso eher eine leise Kritik. Wie soll man an einem unbekannten Statement mit unbekannten Parametern und unbekanntem Modell einen DB-Fehler finden?

:cheers:

[haentschman]

[Update]
Das mit der "manuellen" Änderung der Replikationsspalte war die Ursache. :roll: Ich habe aufgehört die Referenzen zu zählen...:?
...jetzt klappt das auch mit dem "Nachbarn" = SQL. :P

[haentschman]

HINWEIS:
(durch Test verifiziert) :evil:

Durch die eingerichtete Replikation funktioniert

@@IDENTITY
SCOPE_IDENTITY()
GetLastAutoGenValue (benutzt imho SCOPE_IDENTITY())

als Value für den eingefügten Datensatz nicht mehr richtig! (In der Tabelle steht es richtig, aber die Rückgabe ist falsch)

Da die Replikation in der Session reichlich Werte neu anlegt, kommen nach dem Speichern komische ID als LastID raus. :evil:
Beispiel:
Nach Insert in der Tabelle ID=326236
Nach GetLastAutoGenValue ID = 56 :shock:
...Replikation gelöscht...es kommt wieder nach Insert in der Tabelle ID=326237 raus.

Die einzige Variante:
IDENT_CURRENT(tablename)

...:kotz:

Was kommt noch? :gruebel:

Zitat:

SELECT @@IDENTITY
It returns the last IDENTITY value produced on a connection, regardless of the table that produced the value, and regardless of the scope of the statement that produced the value.
@@IDENTITY will return the last identity value entered into a table in your current session. While @@IDENTITY is limited to the current session, it is not limited to the current scope. If you have a trigger on a table that causes an identity to be created in another table, you will get the identity that was created last, even if it was the trigger that created it.

SELECT SCOPE_IDENTITY()
It returns the last IDENTITY value produced on a connection and by a statement in the same scope, regardless of the table that produced the value.
SCOPE_IDENTITY(), like @@IDENTITY, will return the last identity value created in the current session, but it will also limit it to your current scope as well. In other words, it will return the last identity value that you explicitly created, rather than any identity that was created by a trigger or a user defined function.

SELECT IDENT_CURRENT(‘tablename’)
It returns the last IDENTITY value produced in a table, regardless of the connection that created the value, and regardless of the scope of the statement that produced the value.
IDENT_CURRENT is not limited by scope and session; it is limited to a specified table. IDENT_CURRENT returns the identity value generated for a specific table in any session and any scope.

[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...8-)

@jobo: :cheer: ...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 :wink:)

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. :zwinker:


Welche Variante würdet ihr bevorzugen?

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

Danke...:wink: