Adoquery-, Trigger- und Anforderungsfehler

Question

Ich habe eine Adoquery, die einen Datensatz in die SQL Server 2005 -Tabelle einfügt, in der Daten in eine andere Tabelle einfügen. Ich verwende den folgenden Code, um die Abfrage zu aktualisieren und zu vermeiden Row cannot be located for updating (Es gibt PKs in jeder Tabelle, UpdateCriteria -Eigenschaft sind festgelegt, Cursors sind auf dynamisch eingestellt, aber ich erhalte manchmal den Fehler. Manchmal ist es jedoch nicht die Frage.)

procedure Requery(T: TCustomADODataSet; IDField: string);
var
  i: integer;
begin
  if T.RecordCount > 0 then
    i := T.FieldByName(IDField).AsInteger;
  T.Requery();
  if T.RecordCount > 0 then
    T.Locate(IDField, i, []);
end;

Vor der Anforderung kann ich einen Wert des ID -Feldes erhalten. Nach der Anforderung gibt das Feld des ID jedoch den Wert des ID -Felds des anderen durch Triggers eingefügten Tabellenaufzeichnungen zurück. Beide Tabellen haben ID -Feld mit demselben Namen. Ich habe auch hinzugefügt SET NOCOUNT ON .... OFF zu vermeiden auslösen Too Many Rows Affected Fehler, ich glaube jedoch nicht, dass dies mein Problem beeinflusst. Ich habe keine solchen Fehler gesehen, als ich mit Delphi 6 - 7 und SQL Server 2000 gearbeitet habe. Daher bin ich bereit zu geben SDAC oder Dao ein Versuch. Würde SDAC oder DAO das Problem lösen oder gibt es eine Lösung, ohne die Adoquery zu ändern?

Answer 1

Ich bin mit Adoquery nicht vertraut, aber wie Sie sagen, dass Sie eine ID der vom Trigger betroffenen Tabelle erhalten, während Sie erwarten, dass die ursprüngliche Tabelle ID erhalten kann Bester Weg, um die Identität der eingefügten Zeile zu erhalten?

BEARBEITEN

Es scheint, dass das Problem mit der Tatsache zusammenhängt, dass die Ado -Abfrage selbst @@ Identity verwendet, um die ID des hinzugefügten Datensatzes zu erhalten, während sie wirklich Scope_identity () verwenden müssen Enthält Identitätsspalten wie in Ihrem Fall - siehe Link oben für Einzelheiten zu Scope_Identity und @@ Identity. Dieser Beitrag hat einige Details des Problems

Answer 2

Der One -Weg in diesem Durcheinander, das ich in der Vergangenheit verwendet habe, bestand darin, meiner Master -Tabelle ein GUID -Feld hinzuzufügen, bevor ich speichern würde (wenn die GUID leer wäre), würde ich einen neuen GUID in Code generieren und diese Referenz festhalten. Dann würde ich den Datensatz speichern und den Datensatz, der die bekannte Richtlinie enthält, wieder geeignet. Dies versicherte mir, dass ich den genauen Datensatz erhielt, den ich wollte, und dann den FK dem Identitätswert des Master -Datensatzes zuweisen. Sicher, das ist langsamer, aber es funktioniert immer statistisch.