[gelöst] DBGrid - Sroll - EDatabaseError

[kralle]

Moin,

wenn ich mittels

Code: Alles auswählen

 SQLQuery1.SQL.Text:='SELECT * FROM jos311_jdownloads_files_backup_3_2_69;';   

Daten filtere und in einem DBGrid anzeigen lasse, dann gibt es Probleme beim Scrollen.
Scrolle ich im Grid bis ans Ende und mache dann eine Versuch wieder an den Anfang zu scrollen, dann stürzt die Anwendung ab.
Das gleiche passiert wenn ich mich mittels DBNavigator im Grid bewege.

Exception class "EDatabaseError" at $00000000007A9D67 with message "Operation cannot be performed on an unidirectional dataset"

Wie ich diesem Beitrag https://forum.lazarus.freepascal.org/in ... ic=17615.0 entnehmen kann, gibt es das Problem schon mindestens seit 2012.

Der Tipp mit dem

Code: Alles auswählen

PacketRecords:=-1 and .Refresh

brachte nichts.

Irgendwelche Idee?

Nebenbei gefragte: Wenn ich ein

Code: Alles auswählen

Select

nutze, wo finde ich die Anzahl der gefundenen Treffer?

OS: Linux Mint 21.2 Cinnamon
Lazarus: 2.3.0
FPC: 3.3.1

[gladio]

Eventuell mal in den Optionen nachsehen, ob DisableInsert auf true steht.
Könnte sein, dass mit dem Scroll bis zum Schluss versucht wird einen neuen Datensatz einzufügen.

Deine Select-Anweisung filtert nichts.
In dieser Form werden einfach nur alle Datensätze aus der Tabelle ausgewählt.
Erst mit eine Where-Klausel im Anschluss schränkst du die Auswahl ein.

Code: Alles auswählen

select spalte1, spalte2 from Tabelle
where spalte1 > 200;

schränkt alle auszugebenden Datensätze ein auf die, deren Wert in spalte1 größer 200 ist.

[kralle]

Moin,

Code: Alles auswählen

DisableInsert 

ist False.

und das mit "Filtern" war nur falsch ausgedrückt.

Gruß Heiko

[charlytango]

Moin,

wenn ich mittels

Code: Alles auswählen

 SQLQuery1.SQL.Text:='SELECT * FROM jos311_jdownloads_files_backup_3_2_69;';   

Daten filtere und in einem DBGrid anzeigen lasse, dann gibt es Probleme beim Scrollen.

Wie gladio schon ausführte, filtert dieses SQL Statement gar nichts.
Ohne WHERE Klausel gibt es keinen Filter, du forderst einfach nur alle Spalten und alle Zeilen einer Tabelle auf einmal an.
In der Welt von SQL-Datenbanken ist das einfach schlechter Stil.

Man holt tatsächlich nur die Felder und die Zeilen die man wirklich braucht.
Das ist einfach eine andere Art zu denken, denn der tatsächliche Performance-Killer (wenn mit Indizes und anderen Methoden sichergestellt ist dass das Statement schnell ist) ist das Übertragen der angeforderten Daten.

Es gibt in meinen Applikationen praktisch KEIN Statement ohne Where-Klausel und SELECT * ist ebenso verbannt.

Bei ZEOS gibt es für solche Gelüste die komplette Tabelle zu holen die Komponente TZTable. Ein Äquivalent dazu existiert meines Wissens in SQLDB nicht.

Als Test würde ich deinem Statement mal eine WHERE Klausel verpassen, vielleicht kennt sich die Komponente dann besser aus.

Code: Alles auswählen

SELECT * FROM Tablename WHERE 1;

Ich merke gerade, selbst beim Schreiben des Statements verkrampft es meine Finger

Exception class "EDatabaseError" at $00000000007A9D67 with message "Operation cannot be performed on an unidirectional dataset"

Es existieren unterschiedliche Varianten wie Daten vom SQL-Server angefordert werden können - unidirektional und bidirektional. Der Grid braucht einen bidirektionalen Modus.
Scheinbar ist da irgendetwas in der Komponentenkette von der DB-Verbindung zum Grid (inkl. des SQL Statements) nicht ganz in Ordnung eingestellt.

Teste das mal in einem neuen Projekt mit den Standardeinstellungen.

Nebenbei gefragte: Wenn ich ein

Code: Alles auswählen

Select

nutze, wo finde ich die Anzahl der gefundenen Treffer?

Die Frage ist unvollständig gestellt. Denn der Zeitpunkt der Fragestellung ist entscheidend.

Die angeforderten Daten werden in der TSQLQuery zwischengespeichert um sie dem Grid anzubieten. Aber nicht alle Daten auf einmal, die werden Blockweise abgeholt und nur diejenigen Daten retrieved die der Grid gerade braucht.

Zu diesem Zeitpunkt "weiß" TSQLQuery noch nicht wie viele Records noch kommen.
Erst ein TSQLQuery.Last fetcht alle Daten, danach kann man mit TSQLQuery.RecordCount deren Anzahl ermitteln. Macht nur Sinn wenn die Datenmenge übersichtlich ist und ich die Daten danach ohnedies brauche.

Eine andere Variante ist (ungetestet) TSQLQuery.RowsAffected die scheinbar unabhängig vom Fetch-Stand den SQL-Cursor abfragt wieviele Record betroffen sind. Denn der sollte das ja wissen.

Falls ich eine sehr große Ergebnismenge erwarte (was ich unter allen Umständen zu vermeiden suche) frage ich direkt die Datenbank mit einem eigenen SQL-Statement.

Code: Alles auswählen

SELECT COUNT(*) FROM Tablename WHERE 1.

[kralle]

Moin,

reibt Euch nicht an mein

Daten filtere

und dem

Code: Alles auswählen

Select

auf.
Auch die Performance ist mir aktuell egal.

@charlytango Deinen Tipp mit für die Ermittlung der Gesamtanzahl von Treffern werde ich mir anschauen.

Code: Alles auswählen

     //  Ermittelt die Anzahl der Einträge in der Tabelle
     SQLQuery1.Close;;
     SQLQuery1.SQL.Text:='SELECT COUNT(*) FROM jos311_jdownloads_files_backup_3_2_69;';
     SQLQuery1.Open;
     ShowMessage(SQLQuery1.Fields[0].AsString); // Shows "105"
     SQLQuery1.Close;     

Jetzt weiß ich, das es 105 Zeilen gibt, und das hilft mir leider in diesem Moment nicht weiter.

Es existieren unterschiedliche Varianten wie Daten vom SQL-Server angefordert werden können - unidirektional und bidirektional. Der Grid braucht einen bidirektionalen Modus.
Scheinbar ist da irgendetwas in der Komponentenkette von der DB-Verbindung zum Grid (inkl. des SQL Statements) nicht ganz in Ordnung eingestellt.

Da werde ich mal nachforschen.

Gruß Heiko

[kralle]

Moin,
nachdem ich ein Testprojekt erstellt habe und der Fehler da nicht auftratt, habe ich im ursprünglichen Projekt erst das DBGrid gelöscht und neu eingepflegt, aber ohne Änderung.
Dann habe ich die Query-Komponente gelöscht und neu eingepflegt und siehe da, der Fehler ist weg.
Was jetzt in der Query-Komponente die Ursache war weiß ich nicht.

Gruß Heiko

[af0815]

Was jetzt in der Query-Komponente die Ursache war weiß ich nicht.

Wenn man es im GIT hat, so kann man ein Diff der lfm machen. Oder manuell nachsehen wo da der Unterschied ist.

Mir ist eine Variante eingefallen, wann das zurückgehen in der Tabelle Probleme macht. Wenn die Query keinen eindeutigen Primärschlüssel findet. Das macht generell Probleme wenn der fehlt.

[kralle]

Moin,

ich nehme mir immer wieder vor GIT für meine Projekte zu nutzen, aber finde die Zeit dazu nicht.

Gruß Heiko

[af0815]

Zeit findet man nicht, die muss man sich nehmen

Ich würde ein einzelnes Projekt Mal nehmen und in einen lokalen GIT verschieben, dann kann sich Übung holen. Es sind ein paar Befehle am Anfang mit denen man beginnt und freie Bücher und Artikel über den Start mit GIT sind schnell gelesen . Die Scherzen kommen immer erst später

[kralle]

Moin,

Achtung wir werden OT.

Ich habe für GIT sogar einen Kurs besucht, aber da Git nicht direkt in die IDE installiert ist und das was man nachträglich manuell einrichtet, nach einem Update von Lazarus via fpcupdeluxe (funktioniert immer nur in der Form: Lösche vorhanden Version unter Manjaro, Mint und Debian 11 und installiere komplett neu) weg ist, schleift das etwas.

Gruß Heiko

[photor]

Hallo,

trotz off-topic:

Also für die "tägliche Arbeit" reicht Git in der Konsole eigentlich doch aus (nach dem das erstmal lokale Repo initiiert ist):

• Sourcen bearbeiten
• "git status" - um zu sehen, welche Files sind geändert bzw. neu
• "git add <die Files, die jetzt neu>" - um die Neuerungen der Files zum Einchecken vorzumerken (Git-Sprech "stage"n)
• git commit -m "EINE SINNVOLLE BESCHREIBUNG" - damit werden die Files wirklich ins Git-Repo eingecheckt (Git-Sprech "commited")
• Bei mir kommt dann noch ein git push dazu, um das dann mit meinem Server abzugleichen; das ist aber für ein rein lokales Repo nicht nötig.

Das ist erstmal alles, was man sich nur angewöhnen muss. Und am besten immer kleine Änderungen einchecken.

Für das Initialisieren des rein lokalen(!) Repos sollte eigentlich ein git init im Projektverzeichnis reichen (Remark: bitte nochmal nachlesen; das mache ich zu selten - ich nutze einen zentralen Git-Server im Heimnetz).

Damit stehen jetzt die Sourcen schonmal im Git-Repo - gut. Alles andere (taggen, Branches, Ändern der Kommentare ...) kann man sich bei Bedarf anlesen und probieren. Solange man nur die eigenen Source, an denen man auch nur alleine arbeitet, verwalten will, reicht das. Größere Arbeitsgruppen ...

Ich habe (ich glaube sogar hier) mal nach der Integration in die Lazarus IDE gefragt. Ich bin aber mittlerweile der Meinung: Warum? Das geht von der Konsole so schön schnell.

Ciao,
Photor