Hallo Ihr Wissenden,

habe bisher über ADO nur auf DB-Server zugegriffen, nun muss es eine (weil viele projektbezogene kleine) Access-Datenbanken sein. Klappt soweit auch alles, habe 4 Tabellen pro DB, die über master-detail usw. gut zusammenarbeiten. Editiere ich nun in einer ADOTable einen dezimalen Wert, meldet die DB Fehler "weil die Zeile zum Aktualisieren nicht gefunden werden kann". Das kann so nicht sein, denn ein String in der gleichen Tabelle läßt sich problemlos ändern. Nun suche ich schon eine Zeit lang den Fehler bei der Deklaration dieser Dezimalzahlen - und kann nichts finden!

Weiß jemand, woran das liegen kann?

Vielen Dank schon mal.

Bernd.

ADO ist total bescheuert, wenn es um ein UPDATE geht. Anstatt in der WHERE-Klausel des Update-Befehls nur den Primary Key anzugeben
Sei 'Kunden' eine Tabelle und KdID der Primary Key.
Anstatt

erzeugt ADO


Es werden in der WHERE-Klausel also alle Felder und deren alten Werte angegeben. Hier vermute ich das Problem bezüglich Dezimalwerten und Rundungsfehlern bei Floatingpoint. Genaueres kann man aber erst sagen, wenn Du mal ein Beispiel postest.

Sorry, bin erst jetzt zurück....

Wenn das von Dir geschilderte Szenario ursächlich sein sollte, hätte ich das Problem dann nicht auch bei Nicht-Dezimalwerten? Es kommt der Datenbankfehler nur bei der Änderung von Dezimalzahlen in der ADOTable. Du meinst, dass der Umrechnungfehler den "alten" Wert falsch widergibt?

Probehalber habe ich die ADOTable mal durch ein ADODataSet ersetzt, aber mit gleichem Erfolg. Soll ich vielleicht die betroffenen Werte in der Datenbank als Strings speichern und mit xxx.AsFloat verwenden. Das wäre allerdings schon grober Unsinn...

Was soll ich denn für ein Beispiel posten? Es gibt eine ADOConnection, vier ADOTable und zwei DBTable und sonst noch gar nichts weiter! Habe sämtliche andere Funktionalitäten in anderen Units und davon noch nichts eingebunden. Wollte erstmal die DB-Funktionen schreiben.

Hat noch jemand eine Idee?

Bernd.

Der Fehler tritt bei der Änderung von Strings ja nicht auf. Wie gesagt, es ist nur eine Theorie, weil mir ein Beispiel fehlt (eine kleine Access-DB wäre mal was zum Probieren )
ADO baut das UPDATE -wie erwähnt- so zusammen:

Stell Dir das nun mit FloatingPoint und seinen Macken vor (DezimalWert sei 0.1):

Wir wissen ja, das 0.1 in floating point nicht 100% exakt dargestellt werden kann... Wie gesagtr, so könnte es sein und wenn es so wäre, wäre es richtig sch*****.

Ich verwende mittlerweile kaum noch TADODatasets, sondern nur noch Memory-Tables und lade/speichere mir mein Zeugs selbst mit handgebissenen SQL-Befehlen. Damit erreiche ich wesentlich höhere Speicherdurchsätze, da ich UPDATE / INSERT's sammeln kann und dann dieses Skript dann auf einmal zum Server schicke. Weeeeesentlich schneller.

Das glaube ich Dir unbesehen, dass Deine Lösung schneller ist. Schon wegen der Allgemeingültigkeit einer OLE-Schnittstelle ist da immer ein ganzer Rucksack Zusatzmaterie bei. Nur übersteigt Deine Lösungsmöglichkeit meinen Horizont wohl etwas...

Wenn es so wäre (und es wäre beschi..!), bin ich dann der Erste mit dem Problem? ADO gibt es schon eine ganze Weile...
Auf der anderen Seite verstehe ich die "Altwertprüfung" irgendwie als Updatekontrolle zur Gültigkeitsprüfung, also das der zu "updatete" Wert wirklich der letzte gültige ist und nicht zwischendurch durch einen anderen DB-User verändert wurde. Bei "feldweisem" Look wäre das doch eine Begründung, oder...

Was mache ich nun? Ich baue erstmal auf string um, dann sehe ich weiter, konvertieren muss ich eh immer zur Anzeige und die mm-Genauigkeit würde mir ja reichen und Editmasken müssen dann ja auch her - wirklich glücklich macht mich das aber alles nicht.

Bernd.

Erfolgsmeldung:

Ich habe als Zahlenfomat/Größe in der Access-DB jetzt den Typ -Double- vereinbart und alles funktioniert, wie es soll.

Ich bedanke mich für das allgemeine Mitdenken und wünsche Euch einen guten Rutsch ins Jahr 2009.

Bernd.