Zitat von FredlFesl:

Wieso achtest Du beim *schreiben* der Daten nicht auf die Schreibweise? Dann brauchst Du das komische 'REPLACE' bei der Abfrage nämlich nicht mehr.

Auch immer wieder gerne gefragt und durchaus interessant: Wer scrollt eigentlich durch die 40.000 Datensätze?

Leider muß ich, was die Schreibweise angeht, davon ausgehen, dass sie eben nicht immer absolut im gleichen format vorhanden ist. Sonst hätte ich das nicht so machen müssen.

Kein Scrollt durch 40000 Datensätze. Darum ja auch die Abfrage. Bleiben ja nur so 20 übrig.

@Sir Rufo: Ich hab jetzt mal versucht, den Code von dir zu übernehmen. Leider stoße ich da mal wieder an meine Grenzen. Das Projekt ist ein D7 geschrieben. Und teile deines Codes funktionieren unter D7 noch nicht.
Im Grund sollte das kein Problem sein, aber durch meine begrenzte Erfahrung mit Threads bedeuten die Änderungen für mich schon ein Problem.

Zum einen sind da Sachen wie:

Generics.Collections -> Kennt D7 ja nicht.

ebenso dieses: TList<TStrings>.Create und for lField in FData.Fields do (ich denke for .. in kennt D7 auch nicht).

Aber das krieg ich schon hin.

Aber hiermit hab ich wirklich probleme:

Synchronize( procedure begin SendDataToListView( AListView, lItems, Sync ); end ) geht wohl so in D7 auch noch nicht.

Ich kann jetzt aber auch nicht mit dem Projekt auf D2010 umziehen.

Das ist doch nur eine Inline Definition. Schreib die zu synchronisierende procedure einfach normal und ruf sie dort auf. Also aus:
Synchronize( procedure begin SendDataToListView( AListView, lItems, Sync ); end ) wird dann

markieren

Delphi-Quellcode:

procedure TMeinThread.SyncProc
begin
   SendDataToListView( AListView, lItems, Sync );
end;

...

Synchronize(SyncProc)

Das ganze hier ist aber aus meiner Sicht komplett überflüssig, da das Problem in der Datenbankdefinition und der Abfrage liegt. Du treibst hier einen affenartigen Aufwand um Kosmetik zu betreiben.

Dein KennZeichen Feld sollte normalisiert werden. Wo kommt der Abfrage Parameter her? Und wie sieht die Mastertabelle aus?

Ich kann mich nur union anschließen.

Statt die Ursache in der Datenhaltung zu beseitigen, wird das "Problem" in einem Thread versteckt.

Wieviel Nutzer verwenden diese Maske? Wie oft am Tag?
Sicher, es sind nur ein paar Sekunden pro Aufruf. Aber ich vermute, dass Euer Hardwarehandler vielleicht bald mit einem großen Paket vorbeikommt, wenn Du den Stil beibehälst.

Ok, unter D7 ist das so tatsächlich nicht möglich

Mal sehen ob ich da eine D7-taugliche Version dir bereitstellen kann.

Allerdings solltest du tatsächlich mal das Kennzeichen in den Index aufnehmen und mit einem Trigger sicherstellen, dass dort keine Leerzeichen auftauchen.

Dann geht diese Abfrage bestimmt wie der Teufel

markieren

Code:

Select Datum, Zeit, Wer, Arbeiten from main where lfdnr = erster AND KZ = :kennzeichen

EDIT: Da fällt mir doch gerade auf, dass du das Feld erster auch in den Index aufnehmen solltest

Zitat von Captnemo:

Kein Scrollt durch 40000 Datensätze. Darum ja auch die Abfrage. Bleiben ja nur so 20 übrig.

Und für 20 Datensätze machst Du so einen Aufstand?
Investiere eine Stunde Arbeit und bring Deine DB auf Vordermann. Auch Benutzer sollten sich an ein wenig Datenerfassungsdiziplin gewöhnen können. oder willst Du auch noch alle "/" durch "7" ersetzen? Aber nur wenn die Daten am Freitag erfasst wurden.....

Gruß
K-H

Ihr habt ja alle Recht. Und dank jfheins, der mich mit dem Befehl Explain auf die Richtige spur gebracht hat, hab ich das Problem mit der langen Abfrage mittlerweile auch lösen können.

Und...tatsächlich lag es an einem Index, den MySQL nicht verwendet hatte, weil ich dort ein Feld zuviel drin hatte. Ich wußte nur nicht, wie ich sehen kann, welchen Index MySQL denn bei einer Abfrage verwendet. Jetzt ist bezüglich der Abfrage alles wieder top. Liegt jetzt bei 30-40 Milisekunden.

Aber die Thread-Problematik wollte ich trotzdem bis zum Ende durchziehen, denn es hilft mir vielleicht mal an andere Stelle, wenn ich jetzt das ganze hinbekomme und verstehe. Deswegen, würde ich gerne an dieser Stelle noch probieren, bis ich die Abfrage über den Thread hinbekommen habe. Auch wenn ich es später so nicht im Code verwenden werde (weil ja jetzt nicht mehr notwendig)

Im Grunde ist das mit den Threads recht einfach, vor allem wenn man TThread als Basis nimmt. Kurzform: Alles was in der überschriebenen Methode "Execute()" passiert bzw. da heraus aufgerufen wird, passiert in einem eigenen Thread. Bamms. Abgesehen davon ist ein TThread-Nachfahre eine Klasse wie jede andere auch.

Was das ganze etwas verkompliziert, ist das Zusammenspiel mehrerer Threads, so z.B. mit dem Hauptthread deiner Anwendung, in dessen Kontext u.a. alles was mit der VCL GUI zu tun hat läuft. Da kommen dann so Spiele wie Synchronisation hinzu. Als einfachst-mögliche Fausregel könnte man eventuell sagen: Nutze in einem Thread niemals Dinge, die nicht innerhalb des Threads erstellt wurden. "Innerhalb des Threads" heisst bei TThread, dass es entweder in dessen Kontruktor, oder der Execute-Methode.
Gemein ist dabei, dass es an sich prinzipiell geht, und 1000 Mal auch ohne Probleme, aber auch das wir einem eines schönen Tages in den Hintern beissen. Daher gleich rigoros sein, und nicht "rumhacken".

Sobald man mit anderen Threads kommunizieren will (z.B. einem VCL Control eine StringList unterjubeln), muss man threadsichere bzw. threadsichernde Wege wählen, wozu das direkte Beschreiben von Properties (oder aufrufen von Methoden) nicht zählt, es sein denn, man tut dies in einer Critical-Section (TCriticalSection), die die beteiligten für die Dauer der Operation zusammenführt.
Alternativ, und das ist mein Favorit, Windows-Messages vom Thread an ein Formular schicken, und dort dann mit einem Handler reagiern.

Btw: Schön, dass wir dich doch noch zur "Wurzelbehandlung" an der DB bekommen haben - das beruhigt meinen Magen

Zitat von Medium:

Btw: Schön, dass wir dich doch noch zur "Wurzelbehandlung" an der DB bekommen haben - das beruhigt meinen Magen

Es war nie so, dass ich mich dagegen gewehrt hätte. Nur hatte ich die Frage bzgl. der DB unter Datenbank schon gestellt und war nicht weiter gekommen. Und durch die Tatsache, dass ich nicht wußte, wie ich prüfen kann, welchen Index MySQL verwendet, kam ich auch nicht weiter. Jetzt wo ich von jfheins den Tipp mit Explain bekommen habe, war die Sache nach 5 Min erledigt.