FB 3.0 Update mit where exists durchläuft alle Record der upd tbl.

[Uwe Raabe]

Zitat von himitsu:

Na eigentlich würde es ja reichen, wenn beim ersten Fund abgebrochen wird.
Gefunden ist gefunden und noch mehr finden ändert nichts.

Das ist schon richtig - und das wird im SELECT-Teil wohl auch so passieren. Ändert aber nichts daran, dass trotzdem der gesamte Artikelstamm durchsucht und für jeden Datensatz das EXISTS ausgewertet wird.

[himitsu]

kommt drauf an, wie es optimiert wird
und welche Datenlage wahrscheinlicher geben ist.

* das SubSelect zu Beginn einmal auswerten dann das Exists auf diese TempTable (also mit IN)
* in jedem Durchlauf das Exists+Select neu auswerten (also mit EXISTS)

Das Eine ist besser, wenn sehr viele ADRESSEN und sehr wenige RECHNUNGEN
das Andere ist besser, wenn sehr wenige ADRESSEN und sehr viele RECHNUNGEN (was hier bestimmt wahrscheinlicher sein wird).

[Kostas]

Rows affected funktioniert bei Execute Block auch nicht oder?

[Uwe Raabe]

Könntest du den BLOCK Code nicht als Stored Procedure anlegen?

[Kostas]

Zitat von Uwe Raabe:

Könntest du den BLOCK Code nicht als Stored Procedure anlegen?

das ist durchaus machbar.

[IBExpert]

ursache ist recht einfach, weil du hier einen fehler machst

WHERE R.RECHNUNGSNR = 1

was ist der fehler?

RECHNUNGSNR ist sicherlich kein integer sondern ein char oder varchar
und daher muss firebird integerwerte in index stringlisten suchen, das geht nicht
immer so einfach. umgekehrt ist das selten ein problem.

workaround

WHERE R.RECHNUNGSNR = '1'

das läuft das indiziert. in deinem execute block gehst du über variablen,
die werden vor der Nutzung intern passend zu den indizierten felder
umgewandelt.

mach einfach immer passende sqls zu deinen feldtypen.

[himitsu]

Zitat von IBExpert:

RECHNUNGSNR ist sicherlich kein integer sondern ein char oder varchar
und daher muss firebird integerwerte in index stringlisten suchen,

Man könnte sich doch auch einen passenden Index erstellen, also inkl. CAST zum Integer.