Ado Mssql

[Tim Henford]

Hallo,

also ich krieg hier langsam die Krise. Seit 4 Tagen versuche ich nun eine Replikationsfunktion zu basteln, doch irgendwie will es nicht klappen.

Ich hab mir das so vorgestellt, dass ich aus einer vorhandenen Tabelle in einer MSSQL Datenbank die Werte in ein DBGrid lade und diese dann sozusagen "offline" berarbeitet werden können und mittels

AdoDataSet1.SaveToFile('test.dat');

in einer Datei gespeichert werden.

Nun suche ich nach einem einfachen Weg, die neu dazugekommenen Einträge wieder in die DB zu bekommen, die gelöschten ebenfalls aus der DB Tabelle zu löschen bzw. die geänderten eben in der Datenbank abzuändern, aber eben auf Knopfdruck.

Kann mir bitte jemand einen Tipp geben?

[Bernd Schulz]

Hallo!

TAdodataset hat eine Funktion UpdateBatch die exakt das macht, was Du suchst.

BYE BERND

[Tim Henford]

Danke Dir. Das habe ich auch probiert, aber irgendwie kommt

bei meinen Code hier:

  tempCmd.CommandText:= 'CREATE TABLE temp ('+
      'OpID INTEGER IDENTITY(1,1),'+
      'Name NVARCHAR(20),'+
          'created DATETIME,'+
          'lastChange DATETIME,'+
      'PRIMARY KEY (OpID))';
  tempCMD.Execute;

  tempData.CommandText:= 'SELECT * FROM temp';
  tempData.Open;

  tempData.LoadFromFile ('test.dat');
  tempData.Open;

  // in die DB schreiben
  tempData.UpdateBatch(arAll);

Row cannot be located for updating. Some values may have been changed since it was last read.

Was kann das denn sein, die Meldung kommt auch nicht immer, nur wenn ich mehrere Zeile neu erstelle???

[Bernd Schulz]

Hallo!

ADO generiert für das Update einfach eine Reihe von SQl Statements. Die Meldung besagt, dass mehere Zeilen vom Update betroffen sind, obwohl es ja eigentlich pro Statement nur EINE Zeile sein kann. Den Vorgang kann man im Profiler überigens sehr schön beobachten...
ADO hat Einstellungen, die sich auf das generieren der Update Statements auswirken. Wenn Du statt der Standard Delphi Komponenten das TAdooBetterDataset (such mal hier im Forum) verwendest lassen sich solche Dinge einstellen...

Zurück zum Problem:
Der Klassiker für diese Meldung ist ein fehlender Primärschlüssel.

Hat die entsprechende Tabelle einen Primärindex?
Hast Du die beim lokalen Einfügen den Primärschlüssel korrekt gesetzt?
Wenn Offline eindeutige Schlüssel generiert werden sollen bietet sich eine GUID an. die Läßt sich leicht generieren und ist praktisch immer eindeutig.

BYE BERND

[Tim Henford]

Alles klar, dann hab ich einen falschen Index erstellen lassen. Danke Dir.
Aber er updatet die Tabelle in der DB jetzt nicht, stattdessen sagt er:

"FILE SELECT * FROM temp cannot be found."
Was ist denn das nun wieder?

[Bernd Schulz]

Hallo!

>Was ist denn das nun wieder?
Erstmal entspannen und in Ruhe die Optionen Deines Datasets im Objektexplorer durchgehen.

Scheinbar hast Du den CommandType verstellt?!?

PS: Von Andreas Kosch gibt es sehr gute Bücher über ADO. Absolut empfehlenswert!!!

Viel Spass, ich mach erstmal Urlaub.. desshalb erstmal keine weiteren Antworten
BYE BERND

[Tim Henford]

Danke Dir. Das Buch vom Andreas hab ich mir bestellt, aber das kommt wohl nicht vor Montag....

Noch eine Frage, vielleicht liegt es ja daran:

ich lade doch die Daten folgendermaßen

  tempData.LoadFromFile ('test.dat');
  tempData.UpdateBatch(arAll);

Mir kommt es sovor als wolle er das in die Datei zurückschreiben, oder dort aktualisieren, woher weiß er, dass es in die DB gehen soll?

Einen schönen Urlaub schonmal und großes Danke.

[Bernd Schulz]

Hallo!

Einen letzten...
Du holst Dir die Daten von der Datenbank, speicherst das Ganze in einer lokalen Datei und willst es irgendwann wieder zurück auf die Datenbank haben.

Wenn das in die DB zurück soll musst Du wieder die Connection zur DB aufbauen BEVOR Du Dein UpdateBatch machst...
Wenn Du hier im Forum mal nach "UpdateBatch" suchst wirst Du bestimmt was passendes finden!!!

BYE BERND

[Tim Henford]

Ja hab ich schon danke dir. Nur irgendwie werden nur die Zeilen die ich nochmal im DBGrid bearbeitet habe übertragen und wenn ich nix geändert habe, wird auch nix in die DB eingetragen...mhm das macht ein Ärger der Kram.

[Bernd Schulz]

Hallo!

Also in der DB sind die Sätze A, B, C

Ich hole mir die Daten und ändere LOKAL B und ergänze D
Danach ein UpdatetBatch. Das Sollte ein Update auf B und ein Insert für D generieren?!? A und B bleiben vollkommen unbeeindruckt, da sich ja nichts geändert hat. Wenn zwischenzeitlich jemand in der DB A gelöscht hat BLEIBT A gelöscht!!! Lokal hat sich ja an A nichts geändert...

Darf ich Dir den SQL Profiler ans Herz legen... Starten und mal beobachten, was da so passiert. dass hat mir beim Einstieg sehr geholfen...

Nur zu Sicherheit: Du willst doch wirklich "nur" Daten holen bearbeiten und wieder speichern. Daten duplizieren etc. funktioniert so nicht!!

Wenn Du fix antwortest kann ich nochmal hier reinsehen...
BYE BERND

[Tim Henford]

Super, echt danke für deine Hilfe.

Na eigentlich führe ich eine Synchronisation im Schilde, also dass ein User irgendwann mal eine Kopie der einen Tabelle aus der DB holt und daran dann am Wochenende Änderungen vornimmt, die er dann Montag früh wenn er online geht auf den Server hochlädt.

Da schien das doch eine gute brauchbare Lösung

[Bernd Schulz]

Hallo!

>Da schien das doch eine gute brauchbare Lösung
Da ist exakt die richtige Lösung!

Bei uns:
Vertreter lädt seine Kunden aufs Notebook fährt in der Gegend rum ändert Kunden legt neue Ansprechpartner an und lädt beim nächsten Besuch alle Änderungen und neuen Datensätze auf den DB hoch.

Das klappt einwandfrei. Replikationsprobleme mal gänzlich aussen vor gelassen (Anwender A ändert die Telefonnummer und Anwender B macht das unterwegs ebenfalls)

Das Ganze ist ein "Lebendes Recordset"
Siehe auch hier:
http://entwickler-forum.de/archive/i...p/t-20119.html

BYE BERND