Delphi-PRAXiS - Delphi Array aus DB mit Zahlen füllen

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)

- Datenbanken (https://www.delphipraxis.net/15-datenbanken/)

- - Delphi Array aus DB mit Zahlen füllen (https://www.delphipraxis.net/178937-array-aus-db-mit-zahlen-fuellen.html)

Array aus DB mit Zahlen füllen

Moin,

bisher habe ich die Daten aus meiner DB einzeln ausgelesen. Also für jedes Einzeldatum ein FB-Zugriff. Das ist sehr zuverlässig aber auch sehr langsam.
Ich wollte mal fragen, welche Strategie für einen schnelleren Zugriff sinnvoll ist: die Verschachtelung von Befehlen statt des einzelnen Zugriffs (also statt des Zugriffs ein Anhängen von SQL-Sequenzen die dann in einem Schritt ausgelesen werden) oder eine SP die ein Array ausgibt? Zielvariable ist ein mehrdimensionales dynamisches Array.
Die erste Idee sieht auf den ersten Blick ziemlich fehleranfällig aus. Für die zweite Variante fehlt mir ein wenig der Ansatz.
Die Struktur ist Auftrag -> Fertigungslos -> Komponente -> Subkomponente -> Messwertarray
Die Daten gehören auf der Delphi-Seite also der Subkomponente.

Wie gehe ich das an, dass die Datenabfrage für die vorhandenen 300 Komponenten mit je 68 Subkomponenten (je 15 Messungen) nicht viele Minuten dauert?

Danke, Messie

AW: Array aus DB mit Zahlen füllen

Wie sieht denn deine Tabellen- bzw Datenbankstruktur aus? Generell geht es am einfachsten und am schnellsten mit einem schnöden

Code:

select * from Messwerte

AW: Array aus DB mit Zahlen füllen

Die Messswerte liegen in der DB als freie Abkömmlinge der Subkomponente und haben noch einen Zeitstempel als Zusatzinformation.

Im Moment hole ich mir das Fertigungslos, die Komponente und die Subkomponente einzeln. Die Messwerte werden auch einzeln geholt und ins Array gelegt.

Ein get * from Messwerte where diese und jenes? Mal ausprobieren

Grüße, Messie

AW: Array aus DB mit Zahlen füllen

Wenn Du innerhalb Deiner Anwendung wahlfreien Zugriff auf die Messwerte von 300x68 Subcomponenten benötigst, ist es evtl. sinnvoll, diese in einem Rutsch in ein entsprechend dimensioniertes Array einzulesen.
Ausgangspunkt wäre eine(!) Abfrage über alle Entitäten, die Dein Array hält, deren Daten dann iterativ ins Array übertragen werden.
Das wäre das Vorgehen, bei dem das Array Verfahren wohl erhalten bleiben könnte- wenn notwendig / gewünscht.

Frage wäre, wie sich das Volumen perspektivisch entwickelt und ob man an diesem Verfahren festhalten kann /muss.
Was spricht gegen eine gezielte Datenabfrage und Haltung in Datasets ohne Verwendung eines Arrays und die dazu notwendige Datenübertragung ins Array?

AW: Array aus DB mit Zahlen füllen

Ich würde mir eine stored proc schreiben, die mir zu einem Auftrag/Los alle notwendigen Informationen abholt. Das ist dann eine einzige Abfrage.

Die Messwerte holst du dir dann mit 'select * from Messwerte where SubComponentID = :SubComponentID'

AW: Array aus DB mit Zahlen füllen

Moin,

Zitat:

Zitat von Furtbichler (Beitrag 1246747)

Ich würde mir eine stored proc schreiben, die mir zu einem Auftrag/Los alle notwendigen Informationen abholt. Das ist dann eine einzige Abfrage.

Ich denke mal, das ist ein Ansatz der gut passt.

Zitat:

Zitat von jobo (Beitrag 1246735)

(...) evtl. sinnvoll, diese in einem Rutsch in ein entsprechend dimensioniertes Array einzulesen.

Das entsprechende Array gibt es schon. Es wurde vorher aus Textdateien gefüttert. Sieht also so aus als könnte das der richtige Ansatz sein.

Für Stichworte/Tipps/Links in Richtung Umsetzung wäre ich dankbar.

Grüße, Messie

AW: Array aus DB mit Zahlen füllen

Also ein Rutsch, das macht es wohl schneller, aber nicht besser und nicht "nachhaltig" - tolles Wort!
Dieser Vorschlag macht nur Sinn, wenn Du große Teile Deiner Anwendung (das Array und alles was dran hängt) so erhalten willst oder musst wegen des sonst bevorstehenden Änderungsaufwands.

Ich wiederhole also meine Frage, muss alles gleichzeitig im Zugriff sein?
Muss es im Array sein?
Was spricht gegen die einzelne Abfrage der benötigten Daten und deren verbleib im Dataset- ohne Array? Das sind für eine Subkomponente 1x68*15 Zeilen? Wären im Zugriff vielleicht ne 10tel Sekunde?!

Wie war noch mal die Mengenentwicklung?

Zur StoredProc:
Das kann man machen, bringt aber m.E. im Vergleich zu Select nur etwas, wenn mglw. ein komplexes Select Statement durch Procedure Sprachkonstrukte vereinfacht werden kann. Es garantiert darüber hinaus eine ordentliche Parametrierung und Vorkompilierung.
Lohnt sich vor allem bei hochfrequenter Nutzung, viele User, die ständig zugreifen.

AW: Array aus DB mit Zahlen füllen

Zitat:

Zitat von jobo (Beitrag 1247156)

Also ein Rutsch, das macht es wohl schneller, aber nicht besser und nicht "nachhaltig" - tolles Wort!

Hä? Wieso nicht? Was ist an 'nachhaltig' als Wort bemerkenswert?

Wieso ist 'schneller' (hier) nicht 'besser'?

Wenn man die Daten in einem `SELECT` abholen kann, um sie in ein Array zu packen (wenn man es braucht), was soll daran nicht nachhaltig sein?

Bezüglich der Nachhaltigkeit bzw. dem 'Änderungsaufwand' (falls ich das für dich übersetzen darf): Die Daten werden an einer(!) Stelle in der DB erzeugt (Stored Procedure) und an einer(!) Stelle in der Anwendung empfangen und umgeformt (aka ins Array geschrieben).

Selbst wenn man die komplette DB umschreibt, muss man für diesen Ansatz nur die Stored Procedure anpassen. Und selbst wenn man die Datenstruktur in der Anwendung komplett neu schreibt, muss man widerum nur eine Stelle anpassen (die SP).

Bin mal gespannt, was Du hier optimieren willst. (bin ja immer offen für Verbesserungen)

Zitat:

Zitat von jobo (Beitrag 1247156)

Was spricht gegen die einzelne Abfrage der benötigten Daten und deren verbleib im Dataset- ohne Array?

Wenn Du die Daten im Dataset lässt (und die Daten direkt aus der DB holst) machst Du deine Anwendung komplett(!) abhängig vom konkreten DB-Design: Ein Horrorszenario in komplexen Anwendungen.
Weiterhin: Will man die Daten anzeigen, aggregieren, weiterleiten, weiterverarbeiten etc. sollte man das schnellstmöglich aus dem Dataset holen. Etwas langsameres als ein Dataset fällt mir jedenfalls auf Anhieb nicht ein. Will man die Daten dagegen eh nur in seiner zusammengeklicken Oberfläche anzeigen (Chart o.ä.) dann kann man das so machen, also auf das Array verzichten. Aber so programmiert man heute eigentlich nur noch im LOB-Bereich, bei dem man die kleinen Frickeltools raushauen muss. Dafür ist Delphi ja geeignet.

Zitat:

Zur StoredProc:
Das kann man machen, bringt aber m.E. im Vergleich zu Select nur ...

Du hast das nicht verstanden:

Eine SP abstrahiert den Zugriff auf die Datenbank (Nachhaltigkeit bei Änderungen in der DB)
Eine SP verbirgt das konkrete DB-Design. Ich kann hier Daten aus unterschiedlichen Tabellen zusammensuchen, die sich so nicht verknüpfen (JOIN) lassen. (Drastische Vereinfachung und Verbergen eines schlechten DB-Designs).
Eine SP kann die Geschwindigkeit drastisch erhöhen: Wir schreiben gerade Anwendungen für die dritte Welt, bei der man mit Netzwerken um die 256kBit (shared auf 600 Clients) auskommen muss. Aber auch in Gigabit-Netzen zahlt sich jede gespaarte Anfrage aus: Eine SP kann auch mehrere Resultsets liefern (eine Batchanweisung natürlich auch).

Es sind also nicht nur performancetechnische Betrachtungen im Grenzbereich anzustellen, sondern auch Vereinfachungen und Nachhaltigkeit (schon wieder dieses Wort ;-)) bei der Softwareentwicklung, -weiterentwicklung, -anpassung und -wartung. Gleiches gilt für die DB. Ich muss offen für Erweiterungen sein: Eine Abstraktionsebene im DB-Layer(Views und SPs zum Laden und SPs und updateable Views zum Speichern) vereinfachen hier den Entwicklungsaufwand um den Faktor 5 und höher. Demgegenüber stehen jedoch zeitkritische Operationen, wo ich u.U. direkt mit den Daten reden muss (bulk updates z.B.). Hier muss man im Einzelfall entscheiden, inwieweit man die Anwendung abhängig vom konkreten Design machen muss.

AW: Array aus DB mit Zahlen füllen

Zitat:

Zitat von Furtbichler (Beitrag 1247181)

Zitat:

Zitat von jobo (Beitrag 1247156)

Also ein Rutsch, das macht es wohl schneller, aber nicht besser und nicht "nachhaltig" - tolles Wort!

Ein Rutsch ist natürlich schnell, sagt das Wort ja schon.
Ich habe aber bereits nachgefragt, wie das Array bzw. das Mengengerüst ist. Wenn er eines Tages 10T Subcomponenten hat, macht Rutsch wahrscheinlich irgendwo halt.

Zitat:

Zitat von Furtbichler (Beitrag 1247181)

Bezüglich der Nachhaltigkeit bzw. dem 'Änderungsaufwand' (falls ich das für dich übersetzen darf): Die Daten werden an einer(!) Stelle in der DB erzeugt (Stored Procedure) und an einer(!) Stelle in der Anwendung empfangen und umgeformt (aka ins Array geschrieben).

Natürlich, Du darfst hier alles, was die Forenregeln erlauben.
Um Dich vielleicht etwas zu beruhigen, was Du da schreibst hätte von mir sein können. Ich hab kein Problem mit SP. Es ist leider so, dass man auch hier häufig zu lesen bekommt, "ich mach das in einer SP, dann ist es schneller". Das stimmt halt so pauschal nicht. Eine SP die nichts anderes tut, als ein Selectstatement zu kapseln, bringt keinen nenneswerten Geschwindigkeitsvorteil. Erst unter gewissen Umständen, habe ich ja schon geschrieben.

Zitat:

Zitat von Furtbichler (Beitrag 1247181)

Selbst wenn man die komplette DB umschreibt, muss man für diesen Ansatz nur die Stored Procedure anpassen. Und selbst wenn man die Datenstruktur in der Anwendung komplett neu schreibt, muss man widerum nur eine Stelle anpassen (die SP).
Bin mal gespannt, was Du hier optimieren willst. (bin ja immer offen für Verbesserungen)

Abgesehen von der fehlenden Programmierbarkeit, kann ich das ganze Interfacing auch mit Views erreichen. An einer guten SP will ich nichts optimieren, weiß nicht, wo Du das gelesen hast.

Zitat:

Zitat von Furtbichler (Beitrag 1247181)

Zitat:

Zitat von jobo (Beitrag 1247156)

Was spricht gegen die einzelne Abfrage der benötigten Daten und deren verbleib im Dataset- ohne Array?

Ich aggregiere Daten in der Datenbank, verarbeiten tu ich sie erst Recht dort. Z.B. in Stored Procs :)
Selbst eine Weiterleitung mache ich gerne im Backend, also der DB per Link.

Komplette Abhängigkeit von der DB. Das klingt doch langsam etwas nach Sales BlaBla. Natürlich mache ich mich mit diesen und anderen Dingen abhängig von der Struktur. Deswegen gebe ich mir idR Mühe, eine performante und flexible Struktur zu schaffen.
Man kann das natürlich alles machen wie Du sagst, es muss nur am Ende jemand tun und bezahlen. In diesem Thread bswp. war jetzt nicht die Rede davon, die große, finale Anwendung zu schreiben. Ich hab schon 2 mal gefragt wo die Reise denn hingehen soll und mögliches Vorgehen skiziert.

Zitat:

Zitat von Furtbichler (Beitrag 1247181)

Zitat:

Zur StoredProc:
Das kann man machen, bringt aber m.E. im Vergleich zu Select nur ...

Du hast das nicht verstanden:

Eine SP abstrahiert den Zugriff auf die Datenbank (Nachhaltigkeit bei Änderungen in der DB)
Eine SP verbirgt das konkrete DB-Design. Ich kann hier Daten aus unterschiedlichen Tabellen zusammensuchen, die sich so nicht verknüpfen (JOIN) lassen. (Drastische Vereinfachung und Verbergen eines schlechten DB-Designs).
Eine SP kann die Geschwindigkeit drastisch erhöhen: Wir schreiben gerade Anwendungen für die dritte Welt, bei der man mit Netzwerken um die 256kBit (shared auf 600 Clients) auskommen muss. Aber auch in Gigabit-Netzen zahlt sich jede gespaarte Anfrage aus: Eine SP kann auch mehrere Resultsets liefern (eine Batchanweisung natürlich auch).

Dochdoch, ich verstehe das sehr gut. Die Tatsache, dass Du bei der möglichen Performancesteigerung "kann" schreibst, ist auch der einzige Haken an Deiner Liste. Habe ich ja oben schon erläutert. Ich muss nicht in die 3.Welt schauen, ich kann meine Anwendung auch per ISDN laufen lassen.
Eine SP ist nicht per se die beste Lösung. Eine schlechte clientseitige Implementierung wird nicht automatisch besser dadurch, dass ich auf die DBSeite wechsel. Das ist eigentlich alles, was ich sagen wollte. Erfahrungsgemäß lassen sich DB Anwendungen stellenweise bis zum Faktor 100, 1000, 10000 oder sogar unendlich tunen. Das ist keine Zauberei, sondern im Gegenteil recht einfach, wenn sie nämlich zuvor zum Stillstand gekommen sind.
Ursache ist bei großen Steigerungen allerdings meist eine ziemlich schlechte Erst-Implementierung.
Es gibt sehr naheliegende Dinge, die den Einsatz von SP empfehlenswert machen. Viele- auch hier- scheuen sich aber scheinbar davor.

Zitat:

Zitat von Furtbichler (Beitrag 1247181)

Nachhaltig, ist wirklich ein tolles Wort, bzw. der Gedanke, der darin steckt. Es ist in Mode gekommen, als man versucht hat, den Leuten beizubringen, dass man mit klein klein jetzt nicht mehr weiter kommt und für die Umwelt und die Banken und überhaupt nun mal was ordentliches auf die Beine stellen muss. Und wir ahnen es alle, das kostet!
Also Deine Gedanken halte ich nicht für verkehrt, ich bezweifele nur, dass sie dem TE helfen.

AW: Array aus DB mit Zahlen füllen

Moin und Danke erstmal für die Tipps. Hat ja ein wenig gedauert bis ich da wieder Zeit für habe.
Der Grund: der Import alter Daten dauert jetzt schon ein paar Wochen. Auch hier habe ich für jedes Fertigungslos, die Komponente und die Subkomponente sowie die Messdaten je einen Zugriff der sehr langsam ist. Hier kann ich auch nicht sicher sagen, ob ein Teil der Datensätze schon in der DB vorhanden ist und ich ein paar weitere Messdaten hinzu fügen muss (Die Messdaten sind oft in verschiedenen Dateien abgelegt).

Kann man das Beschreiben der Datenbank irgendwie beschleunigen?

Struktur ist:

Delphi-Quellcode:

			 
      s := 'SELECT count(*) FROM ' + Fertigungslos + ' WHERE (Auftragsnummer = ' + QuotedStr(IntToStr(JobID)) + ' .... )';

      i := DM.IBCQuery1.FieldByName('COUNT').AsInteger;

      if i > 0 then

      begin

        //modify entry in table

        s := 'SELECT ID FROM ' + Fertigungslos + ' WHERE (Auftragsnummer = ' + QuotedStr(IntToStr(JobID)) + '....  )';

        if not DM.IBCQuery1.IsEmpty then

        begin

          idx := DM.IBCQuery1.fieldbyname('ID').AsInteger;

        end;

        s := 'UPDATE ' + Fertigungslos +, DRAWING_NO = .... 'WHERE ID = ' + IntToStr(idx);

        DM.IBCQuery1.SQL.Add(s);

        DM.IBCQuery1.ExecSQL;

        DM.IBCTransaction1.Commit;

      end

      else

      begin

        //add entry to table

        s := 'INSERT INTO ' + Fertigungslos + QuotedStr(Batch.DrawNo) + ....')';

        DM.IBCQuery1.SQL.Add(s);

        DM.IBCQuery1.ExecSQL;

        DM.IBCTransaction1.Commit;

      end;

      DM.IBCTransaction1.StartTransaction;

      DM.IBCQuery1.SQL.Clear;

      //Kontrolle

      s := 'SELECT ID FROM ' + Fertigungslos + ' WHERE (Auftragsnummer = ' + QuotedStr(IntToStr(JobID) .... ' )';

      DM.IBCQuery1.SQL.Add(s);

      DM.IBCQuery1.Open;

      if not DM.IBCQuery1.IsEmpty then

      begin

        idx := DM.IBCQuery1.fieldbyname('ID').AsInteger;

      end

      else

      begin

        Result := False;

        DM.IBCTransaction1.Commit;

        Exit;

      end;

      Batch.DBindex := idx;

      DM.IBCTransaction1.Commit;

      if SavePumps then

      begin

        for i := 0 to Fertigungslos.PumpCount -1 do

        begin

          //pumpen speichern

          SavePumpToDB(Fertigungslos.Items[i],idx);  ------> hier gehen die Strukturen iterativ weiter.

        end;

      end;

      Result := True;

Das blöde ist, ich brauche es nur ein Mal.

Grüße, Messie

AW: Array aus DB mit Zahlen füllen

Da fallen mir doch ein paar wesentliche Dinge auf

Das ständige COMMIT bremst ... Starte die Transaktion, trage alle Daten ein, und ganz zum Schluss ein COMMIT
Du erstellst die SQL-Statements ständig neu, dadurch kommst du nicht in den Genuss der Prepared-Statements, die wesentlich schneller ablaufen. Erstelle die für jedes Statement ein Query-Objekt und benutze das (Parameter verwenden)

Delphi-Quellcode:

LCount_Query.SQL.Text := 'SELECT count(*) FROM ' + Fertigungslos + ' WHERE (Auftragsnummer = :JobId) ...';
...
LCount_Query.ParamByName('JobId').Value := JobID;

Generell würde ich den Import aber anders auf die Beine stellen:

Anlage einer (oder mehrerer) Import-Tabelle(n)
Views von den Import-Tabellen anlegen, um die Daten in das neue Format zu überführen
Mit diesen Views den Import durchführen

Ab dem Schritt 2 läuft dann alles auf der Datenbank selber und sollte erheblich schneller funktionieren.
Sollte (wenn die Zieltabellen einen vernünftigen Index haben) sich dann nur um Stunden handeln ;)

AW: Array aus DB mit Zahlen füllen

Zitat:

Zitat von Sir Rufo (Beitrag 1251780)

Indizes,Import und Geschwindigkeit vertragen sich nicht gut.
Import ohne Index oder Indizes läuft schneller. Am Ende - Insert der aufbereiteten Daten- lässt sich natürlich ein Index in der Zieltabelle selten vermeiden. Ausnahme wäre bspw. ein einmaliger Import, bei dem zuvor die Indizierung deaktiviert / gelöscht und nach dem Import wieder restauriert
wird.

Ich verwende gerne "Raw" Importe, also 1:1 Import Altdaten in DB. Dort habe ich per SQL elegante Aufbereitungsmöglichkeiten. Der reine Import der Altdaten läuft dabei nur in Texttypen rein. Die Importtabelle wird dann gereinigt, plausibilisiert und typkonvertiert in die Zieltabelle eingetragen.
Das ist umgekehrt zu ETL, das Extrakt, Transform kommt erst nach dem Load. Ich hab aber nie so große Datenmengen importieren müssen, dass ich mir / dem System das nicht erlauben konnte.

AW: Array aus DB mit Zahlen füllen

[QUOTE=jobo;1251785]

Zitat:

Zitat von Sir Rufo (Beitrag 1251780)

Ich hab aber nie so große Datenmengen importieren müssen, dass ich mir / dem System das nicht erlauben konnte.

Groß sind die Datenmengen eigentlich nicht: nur 20-30 MB - leider aber aufgeteilt in etwa 3000 Aufträge mit jeweils unterschiedlichen Messdaten mit TimeStamps aus den vergangenen zehn Jahren.

Ich bin gerade dran, das von den Commits zu befreien...

Grüße, Messie

AW: Array aus DB mit Zahlen füllen

@jobo

Das mag zutreffen, wenn man nicht - wie in diesem Fall - auf Dubletten überprüfen muss.
Hier werden Daten zusammengeführt.

Ein gangbarer Weg wäre aber die gültigen Importsätze wiederum in einer temporären Tabelle zu speichern, dann den Index bei der Zieltabelle abschalten, Importdaten einfügen und den Index aufbauen lassen.

AW: Array aus DB mit Zahlen füllen

Richtig, ich fand einfach nur die Aussage Import mit Index etwas zu pauschal, auch wenn es in diesem Thread etwas spezieller (Dubletten) gefasst war.

AW: Array aus DB mit Zahlen füllen

Zitat:

Zitat von messie (Beitrag 1251788)

Zitat:

Zitat von jobo (Beitrag 1251785)

Zitat:

Zitat von Sir Rufo (Beitrag 1251780)

Ich hab aber nie so große Datenmengen importieren müssen, dass ich mir / dem System das nicht erlauben konnte.

Der Kommentar ist bezieht sich wohl auf meine Äußerung nicht auf Sir Rufo.
Mit großen Datenmengen meine ich nicht 20-30 MB, sondern Volumen wo sich durch den Rohimport eine DB im 2-3 stelligen GB Bereich bspw. verdoppeln würde, ohne dass überhaupt Daten in Prod. Tabellen gelandet sind.
Wie gesagt, in kleineren Größenordnungen kann man sich durchaus den Luxus gönnen.
Damit meine ich nicht, einfach mit Speicherplatz rumzuasen, sondern diverse Vorteile dieses Verfahrens zu nutzen. Z.B. Performance und bequemer Dublettenabgleich gleichzeitig, begleitet von Reinigung, Validierung, Typkonvertierung der Daten. Eben nicht klassische ETL, sondern eher LET.

Bspw. allein der Murks, der häufig als Datum/Timestamp über Text reinkommt, kann einem das Leben schon sehr schwer machen. Wenn ich auf DB Seite per SQL eine Konvertfunktion mit definierter Formatmaske darauf ansetze, kann ich gleich noch eine Rückkonvertierung in Text mit Assert auf den Originalstring draufsetzen und bin damit sowohl gegen Original-Datenmüll als auch gegen Kovertierungsfehler 100% abgesichert. Geschieht das alles per SQL auf der DB, kostet mich das ungefähr 0% Aufwand.

AW: Array aus DB mit Zahlen füllen

Moin,

ich habe mich schon auf Sir Rufo (#11) bezogen. Dass ich pro Import einer Datei tausend Mal ein commit sende was dann jedes Mal die DB beschickt, den Cache leert und was sonst noch so, ist verständlich.
Ich habe die Commits raus genommen und laufe vor die nächste Wand. Query.ExecSQL klappt nicht mehr. Offensichtlich hat das commit die verbundene Transaction so geerdet, dass ein Neuaufruf mit StartTransaction möglich ist.

Wie ist der genaue Ablauf? Ich habe eine Query, die einer Transaction zugeordnet ist. Die Transaction steht auf read_committed.
Ich habe bisher Transaction.StartTransaction -> Query.SQL.Clear -> Query.SQL.Add -> Query.ExecSQL. Wenn ich danach eine Query.open abfrage, bekomme ich eine Exception.

Ich vermute, dass ich das commit mit etwas Anderem ersetzen muss.

Grüße, Messie

Edit: wann kann ich auf das Transaction.StartTransaction verzichten? Denn das spuckt mir (Edit4: nach dem Entfernen des commit) in die Suppe. Ist das mit Performance verbunden? Also eher Transaction.Active = false und dann mit Starttransaction oder kann die die ganze Zeit offen bleiben?
Edit2: sehe ich das richtig, dass eine Query.open (nur Lesen) kein Transaction.active braucht und eine Query.ExecSQL (z.B. Schreiben) eine Transaction.active benötigt? Das sieht mir gerade so aus...
Edit3: ist dem Query.Open der Zustand der Transaction wegen des Nur-Lesens egal?

Danke!

AW: Array aus DB mit Zahlen füllen

Hallo,

Nicht Query.Clear, sondern Query.SQL.Clear.
Es gibt doch den SQL-Monitor zum Prüfen der Queries.
Die Geschwindigkeit lässt sich über prepared Queries erhöhen.
Drittens: Insert or Update benutzen, statt ständig per Select zu suchen, ob der Eintrag bereits existiert.

In einem Projekt hatte ich sogar sämtliche IDS in ein StringList geladen (Import lief exklusiv)

Heiko

AW: Array aus DB mit Zahlen füllen

Moin,

ich habe die Transaction rausgenommen und die Daten kommen nicht in der DB an. Womit mache ich denn das kaputt?
Ich aktiviere die Transaction, frage dann per Query.Open an und füge bei Bedarf per Query.ExecSQL ein. Das mache ich rekursiv und zum Schluss ein commit. Irgendwo hakt es da aber. Ich habe die Vorstellung, dass meine ExecSQLs alle in einen Cache kommen und mit dem commit gespeichert werden. War das nicht so?

Grüße, Messie

AW: Array aus DB mit Zahlen füllen

Moin,

ich habe mich mal durch die Einstellungen der IBCTransAction und der IBCQuery gearbeitet. Welche Kombination von Einstellungen sind denn sinnvoll für Transaction.IsolationLevel und Query.AutoCommit?

Grüße, Messie