TDBXError: Reader-hat-keine-weiteren-Zeilen

[Delbor]

Hi sx2008

Grundsätzlich denke ich, hast du damit recht, verschiedene DataSets zu verwenden. Ich sehe allerdings nicht,weshalb die Funktion eingeschränkt werden soll, wenn ich das einemal eine Selectanweisung und das andere mal ein Insert-Statement über dasselbe Dataset ausführe.

Zitat:

(* im Objektinspektor festgelegt, braucht daher nicht im Code zu sein
soll hier nur dem Verständnis dienen

Hmm... Das heisst dann: für jede Abfrage ein eigenes Dataset? Ist das nicht etwas viel?
Zum Beispiel, wenn eine Abfrage die ersten drei Felder liefern soll, eine andere alle und eine dritte nur eines?

Zitat:

du verwendest ExecSQL und Close hintereinander.

Wenn nach dem ExecSQL der Aufruf der Prozedur SelectLastId erfolgt und da das Dataset nach deinem Vorschlag erstmal geschlossen wird, entspricht dies in der Praxis genau dem... Sorry.
Das Close steht da auch erst, seit ich mit 'SELECT..MAX' arbeite und sicher sein wollte, das das Dataset auch wirklich geschlossen ist. Ich gehe mal davon aus, dass der Reader, von dem hier die Rede ist, die Objektinstanz ist, die das DataSet ausliest und von diesem erzeugt wird, wenn die Ergebnisse eines SELECT angefordert werden.

Zitat:

...achte darauf, dass Felder immer einen definierten Namen bekommen.

ÄÄÄhhh - und dann das einzige angeforderte und gelieferte Feld über seinen Index abfrage?

Gruss
Delbor

[sx2008]

Zitat von Delbor:

Grundsätzlich denke ich, hast du damit recht, verschiedene DataSets zu verwenden. Ich sehe allerdings nicht,weshalb die Funktion eingeschränkt werden soll, wenn ich das einemal eine Selectanweisung und das andere mal ein Insert-Statement über dasselbe Dataset ausführe.

Wenn du nur ein Dataset verwendest ist es im Prinzip wie ein globales Objekt und kann damit unerwünschte Seiteneffekte verursachen.

Zitat von Delbor:

Das heisst dann: für jede Abfrage ein eigenes Dataset? Ist das nicht etwas viel?
Zum Beispiel, wenn eine Abfrage die ersten drei Felder liefern soll, eine andere alle und eine dritte nur eines?

Ja, für jeden Zweck ein eigenes Dataset. Um das zu organiseren gibt es Datenmodule.
Die meisten Abfragen sind fest, d.h. man kann sie schon im Objektinspektor festlegen.
Dynamische Abfragen, also wenn das SqlCommand zur Laufzeit zusammengebaut wird, kann man natürlich auch verwenden, aber das ist eher selten.
Man kann ca 20 bis 30 Datasets auf ein Datenmodul packen bevor es unübersichtlich wird.

Zitat von Delbor:

ÄÄÄhhh - und dann das einzige angeforderte und gelieferte Feld über seinen Index abfrage?

In dem Fall sollte man das Feld über den Namen ansprechen.

Ich verstehe übrigens nicht so ganz, was du mit der LastId eigentlich bezweckst.
Eigentlich muss man die höchste ID nur abfragen, wenn man einen neuen Datensatz einfügen möchte.
Dann braucht man aber die höchste ID plus 1.
Und die Insertanweisung wäre dann Insert Into Bildtabelle(idBild, Thumbnail, NEF) Values (:FidBild, :FThumbMemory,:FNefMemory) weil man die neue ID schon beim Einfügen mitgeben muss.

Falls das Feld idBild ein Autoincrement-Feld ist muss man es allerdings beim Insert weglassen.
Dann ergibt sich allerdings das Problem, dass man nicht weiss mit welcher ID der letzte Datensatz eingefügt wurde. (was passiert wenn mehrere Clients quasi gleichzeitig einfügen?)
Ich würde empfehlen auf Autoincrement-Felder komplett zu verzichten und stattdessen die neue ID direkt vor dem Insert zu ermitteln.

[Delbor]

Hi sx2008

Zitat von sx2008:

Ich verstehe übrigens nicht so ganz, was du mit der LastId eigentlich bezweckst.

Die DB besteht aus insgesamt 7 Tabellen, die alle untereinander verknüpft sind; 2 davon mit n:m-Beziehungen, der Rest ist 1:n. Den letzten eingefügten/erzeugten Wert brauche ich für den Fremdschlüssel der Detailtabelle.

Zitat von sx2008:

Falls das Feld idBild ein Autoincrement-Feld ist muss man es allerdings beim Insert weglassen.
Dann ergibt sich allerdings das Problem, dass man nicht weiss mit welcher ID der letzte Datensatz eingefügt wurde. (was passiert wenn mehrere Clients quasi gleichzeitig einfügen?)

Die Primärschlüssel sämtlicher Tabellen sind autoinc-Felder. MySQL kennt die Funtion 'SELECT_LAST_INSERT_ID', die den letzten erzeugten Autoinc-Wert zurückliefert(InnoDB). Das hat ja erstmal auch funktioniert - so, wie es mir jetzt erscheint, glaub ich mich zu erinnern, dass ich erstmal diese Prozedur aufbaute, bevor ich die nächsten Insert-Prozeduren schrieb. Und seither krieg ich die bewusste Fehlermeldung...
Die Funktion 'SELECT_LAST_INSERT_ID' ist übrigens Verbindungsbezogen und mindestens der in Bearbeitung stehende Datensatz gesperrt. MySQL 5.1.xx ist da recht überzeugend.

Zitat von sx2008:

Ich würde empfehlen auf Autoincrement-Felder komplett zu verzichten und stattdessen die neue ID direkt vor dem Insert zu ermitteln.

Das hab ich mir auch schon überlegt, hatte dann aber den Eindruck, dass das DBX-Framework von DelphiXE inzwischen ein recht starkes Werkzeug ist. Fundierte Kenntnissse des Frameworks würden mir wohl bei der Entwicklung weiterer DB-bezogener Programme gute Dienste leisten, su dass ich vieles nicht mehr 'barfuss machen' muss.

Ich denk, ich werd' mal ein Testprogrämmchen zum Austesten des Frameworks schreiben und hier vorerst auf 'Indexvergabe per Hand' umsteigen.

Gleichwohl interessiert es mich immer noch, wenn irgendwer Kenntnisse über das DBX-Framework hat.

Gruss
Delbor