FireDAC Merkwürdigkeiten

[haentschman]

Moin...

Interessant, das man Probleme findet, die so niemals in den Kopf kamen...

Zitat:

Soll es so sein, dass nur auf DSBrowse (und kein anderer State) geprüft wird?

Zitat:

scheint mir das Ignorieren der Locate Rückgabe suboptimal zu sein

Zitat:

Für eine stabile Netzwerkverbindung sorgen.

Zitat:

Dann scheitert es mindestens an der Relationslogik oder aber an DB Constraints

...die Zeilen stammen aus der alten Codebasis. Ich konnte mich leider noch nicht darum kümmern. Das sieht man an dem vorhandenem Locate.
Unabhängig davon ist mir ehrlich gesagt das mit der nicht behandelten Funktionsrückgabe nicht aufgefallen... Es wird später alles auf Objekte und SQL umgebaut. Dann habe ich andere Probleme...

Ihr braucht nicht mehr die Ursache finden...es gibt wichtigere Baustellen.

Danke.

[jobo]

Ich finde jetzt Locate nicht so schlimm, richtig angewendet. Heute würde ich es nicht mehr nutzen, aber hab ich mal, vor 20 Jahren. Das ist ja eigentlich eine der guten Seiten an Delphi, seine Kompatibilität/Beständigkeit.
Du gehst ja mit deinem eigenen Objekt und Storage Layer andere Wege, geht halt auch.
Aber es geht für mich an den mächtigen DB Features von Delphi vorbei. Alles da, was man braucht.

[haentschman]

Moin...

Zitat:

Ich finde jetzt Locate nicht so schlimm

Mit MSSQL hatte schon mehrfach meine Probleme. Sowohl in der alten Firma als auch jetzt. Das Locate kam False zurück obwohl der Datensatz definitiv vorhanden war.
Deshalb schmeiße ich die raus...

[Uwe Raabe]

Zitat von haentschman:

Mit MSSQL hatte schon mehrfach meine Probleme. Sowohl in der alten Firma als auch jetzt. Das Locate kam False zurück obwohl der Datensatz definitiv vorhanden war.
Deshalb schmeiße ich die raus...

Na ja, auch eine Art der Fehlerbeseitigung.

Wobei ich Locate schon immer (BDE, dbExpress, FireDAC) und mit verschiedenen Datenbanken ohne Probleme genutzt habe und das auch jetzt noch tue. Eine inhärente Fehlfunktion würde ich daher eher ausschließen.

[jobo]

Zitat von haentschman:

Moin...

Zitat:

Ich finde jetzt Locate nicht so schlimm

Mit MSSQL hatte schon mehrfach meine Probleme. Sowohl in der alten Firma als auch jetzt. Das Locate kam False zurück obwohl der Datensatz definitiv vorhanden war.
Deshalb schmeiße ich die raus...

Mmh, solche pauschalen Aussagen sind leider schwer nachvollziehbar, dient schlimmstenfalls der Legendenbildung.
Es gibt ja noch ein paar Optionen für Locate und die Kombination mit Filter. Da kann schon was schief gehen beim Coden.
Es gab auch mal in bestimmten Fällen einen Bug bei zeitgleich gesetzten Filtern, was aber eher den umgekehrten Effekt hatte den Du beschreibst, es gab True zurück, obwohl der Datensatz außerhalb der Filtermenge lag.
Würde mich da eher Uwe anschließen.

[haentschman]

Zitat:

Mmh, solche pauschalen Aussagen sind leider schwer nachvollziehbar

... kann ich jetzt nicht beweisen. Aber es gab damals mehrere Zeugen...mit offenen Augen.

PS: wir reden über MSSQL!
damals:
1. Vor dem Locate in die Query geguckt (Grid auf die Form...gefiltert oder nicht) -> Datensatz vorhanden!
2. Query.Locate -> False
...Logic im Ar...

Erklären kann ich das nicht. Damals war es ADO. Aber bei FireDAC habe ich es einmal auch gesehen. Imho tritt das nicht grundsätzlich auf. Ich habe nie herausgefunden welche Konstellation schief gelaufen ist. Vieleicht ist MSSQL das Problem.

Nach Umbau auf ein "select" gab es nie wieder Probleme.

Jetzt reden wir nicht mehr darüber...

[Frickler]

Zitat von jobo:

Ich finde jetzt Locate nicht so schlimm, richtig angewendet. Heute würde ich es nicht mehr nutzen, aber hab ich mal, vor 20 Jahren. Das ist ja eigentlich eine der guten Seiten an Delphi, seine Kompatibilität/Beständigkeit.

Eine ständig offene Query, in der man per Locate, Edit und Post rumhampelt, hat schon was von TTable...

Ich würde so ein Konstrukt einfach durch eine UPDATE Anweisung ersetzen oder noch besser einen SP-Aufruf, der die eigentliche Datenbankstruktur verbirgt.

[DasWolf]

Probleme beim Locate gibt es, wenn Felder in der Datenbank als CHAR oder NCHAR mit einer Länge > 1 definiert sind
und zusätzlich in der FDConnection die Eigenschaft FormatOptions.StrsTrim auf False gesetzt ist.