Geschwindigkeit von MyReader.Read() auf MS-Access

Computer: Software & Programmierung .NET & C#
#1

Hallo zusammen.

Ich suche eine Idee zur Performancesteigerung für eine DB-Abfrage über c#.

Wie man eine Abfrage abwickelt mit Connector etc. ist mir klar, es geht sich nur um Geschwindigkeit.

Läuft die Schleife
while (MyReader.read() { machWas();}
erfolgen die Aktionen wie gewünscht. Allerdings wir das letzte, erfolglose Read in ca. 1,5 Minuten ausgeführt. Dies liegt wohl an den ca. 180 Tausend Zeilen die nutzloser weise kontrolliert werden (was allerdings natürlich nicht vorher sagen kann :wink:). Führe ich die Abfrage direkt in Access aus dauert es kaum eine Sekunde.

Freue mich über jeden Vorschlag für ein anderes Konzept!

Dirk

Handle so, daß Dein Handeln Grundlage eines allgemeinen Gesetzes sein kann. (Immanuell Kant)

#2

Dieser Beitrag wurde von der Community gemeldet und ist vorübergehend ausgeblendet.

#3

liest Du denn Datensatz für Datensatz aus?
kannst du ev. ein wenig mehr code posten?

gruss

[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]

#4

Hallo Giuseppe.

Vielen Dank für die Antwort.

Gerne kann ich mehr Code posten, aber das wesentliche ist das schon.

Das letzte Read() dauert halt sehr lange weil bis ans bittere Ende gesucht wird und meine Lösung über die tempTabelle ist soweit ok.

Die Idee sollte halt ein Alternative aufzeigen: Ganze Tabelle aus Access ins Ram einlesen (Sind ja nur 50MB :wink: oder so) in ein DataGrid, Table, Array oder egal und darin suchen. Gibt´s fürs Suchen Methoden? In welches Objekt ich lesen würde ist eher egal, Hauptsache schnelle Suche. Pro Job brauche ich bis zu 1000 Suchen. Ich will auch noch prüfen, wie weit eine vorherige Aufbereitung in der DB hilft. Grundsäzlich lese ich ca. 5-10 Sätze auf Basis von drei Kriterien aus denen ich ein Feld mit Text zu einem Text „aufaddiere“. Das kann man vorbereiten. Aber wenn kein Satz da ist (oder am Schluß) wird´s auch dauern. Das macht´s zwar sicher schneller, aber ist eher ein Work-Around.

Freue mich auf eine weiter Diskussion.

MfG

Dirk

Handle so, daß Dein Handeln Grundlage eines allgemeinen Gesetzes sein kann. (Immanuell Kant)

#5

Hallo Dirk

Das letzte Read() dauert halt sehr lange weil bis ans bittere
Ende gesucht wird und meine Lösung über die tempTabelle ist
soweit ok.

Hmm… kann es sein, dass du keine Indices gesetzt hast, und der zugriff darum immer langsamer wird? Unten schreibst Du, dass du „suche“ brauchst. Was genau verstehst Du darunter?

Die Idee sollte halt ein Alternative aufzeigen: Ganze Tabelle
aus Access ins Ram einlesen (Sind ja nur 50MB :wink: oder so) in
ein DataGrid, Table, Array oder egal und darin suchen. Gibt´s
fürs Suchen Methoden? In welches Objekt ich lesen würde ist
eher egal, Hauptsache schnelle Suche. Pro Job brauche ich bis
zu 1000 Suchen. Ich will auch noch prüfen, wie weit eine
vorherige Aufbereitung in der DB hilft. Grundsäzlich lese ich
ca. 5-10 Sätze auf Basis von drei Kriterien aus denen ich ein
Feld mit Text zu einem Text „aufaddiere“. Das kann man
vorbereiten. Aber wenn kein Satz da ist (oder am Schluß)
wird´s auch dauern. Das macht´s zwar sicher schneller, aber
ist eher ein Work-Around.

Du kannst die Daten in ein (Typed)DataSet speichern. Im DataSet (resp. auf der DataTable) gibt es Methoden um Datensätze zu suchen.

Gruss
Giuseppe

Freue mich auf eine weiter Diskussion.

MfG

Dirk

Handle so, daß Dein Handeln Grundlage eines allgemeinen
Gesetzes sein kann. (Immanuell Kant)

#6

Hallo Giuseppe

Vielen Dank für den Hinweis. Ich werde mal DataSet oder DataTable ausprobieren. Das SQl Statement, das ich zur Zeit verwende lautet ungefähr so:

select text from textTable where (sp1 like „wert1“ and sp2 like „wert2“ and sp3 like „wert3“)

Hoffe das ist richtig geschrieben, das *echte* Statement tut`s auf jeden Fall.

Ich glaube allerdings nicht, dass Read() langsamer wird. Kann es sein, das durch Read() ACCEESS sozusagen immer wieder angestoßen wird den Nächsten zu suchen? Da keiner gefunden wird erfolgt die Suche bis ans Ende der Tabelle. Interessant währe es, vorab die Anzahl der Zeilen zu bestimmen um die Schleife selbst abzubrechen. Würde die Suche bis zum biteeren Ende ersparen. Direkt in ACCEESS scheint das optimaler zu klappen.

Auf einer SQL DB habe ich das in einer Stored Procedure komplett samt Aufbereitung (Alle texte in ein Feld „summieren“) wesentlich schneller hinbekommen. Dort verwende ich das obige select zum Füllen einer tempTable die ich dann per cursor in ein Feld „summiere“. Kann man sowas für ACCESS auch machen? Da dann genau eine Zeile entsteht, in der der Text enthalten ist, könnte ich mir das while (MyReader.Read()) { mach es!} sparen!

Fast eine Grundsatzfrage:
Bei Verwendung einer DB: Wer soll´s machen? DB oder Code? Im Extremfall alle Daten der DB lesen und im Code bearbeiten oder „SQL“ bis das benötigte Ergebnis da ist? Hängt wohl an vielen Fragen (lokal oder fürs web, Anzahl der Datensätze, Schwierigkeit der Aufbereitung) Gibt´s da sowas wie "Faustregeln?

Sobald der Test per Data* gelaufen ist melde ich mich mal.

MfG

Dirk

Handle so, daß Dein Handeln Grundlage eines allgemeinen
Gesetzes sein kann. (Immanuell Kant)

#7

Hi

select text from textTable where (sp1 like „wert1“ and sp2
like „wert2“ and sp3 like „wert3“)

hast du auf dem feld sp1, sp2 und sp3 einen index definiert?

ist ein like wirklich nötig? genügt nicht ein gleich: also sp1 = „wert1“ ?

Ich glaube allerdings nicht, dass Read() langsamer wird. Kann
es sein, das durch Read() ACCEESS sozusagen immer wieder
angestoßen wird den Nächsten zu suchen?

Ich weiss nicht genau wie sich ein Read verhaltet, aber so wie Du mir erzählt hast sieht es danach aus als würde immer erneut suchen… deshalb kann es sein, dass es immer langsamer wird. darum kannst du mit einem index dagegenwirken.

Auf einer SQL DB habe ich das in einer Stored Procedure
komplett samt Aufbereitung (Alle texte in ein Feld
„summieren“) wesentlich schneller hinbekommen. Dort verwende
ich das obige select zum Füllen einer tempTable die ich dann
per cursor in ein Feld „summiere“. Kann man sowas für ACCESS
auch machen? Da dann genau eine Zeile entsteht, in der der
Text enthalten ist, könnte ich mir das while (MyReader.Read())
{ mach es!} sparen!

in access kannst du nicht so mit cursor arbeiten. die sql befehle von access sind relativ beschränkt.

Fast eine Grundsatzfrage:
Bei Verwendung einer DB: Wer soll´s machen? DB oder Code? Im
Extremfall alle Daten der DB lesen und im Code bearbeiten oder
„SQL“ bis das benötigte Ergebnis da ist? Hängt wohl an vielen
Fragen (lokal oder fürs web, Anzahl der Datensätze,
Schwierigkeit der Aufbereitung) Gibt´s da sowas wie
"Faustregeln?

Ich versuche soviel wie möglich mit T-SQL abzuhandeln, und dann was nicht geht mit Programmierlogik. Ist aber wohl eher eine geschmacksfrage.

gruss

1 Like
#8

Hi

hast du auf dem feld sp1, sp2 und sp3 einen index definiert?

Nein, aber damit wird´s auch nicht besser.

ist ein like wirklich nötig? genügt nicht ein gleich: also sp1

= „wert1“ ?

Nein: Viel besser: Statt 1.11 Minuten CPU nur 2 Sekunden (oder gar weniger?)! werde das mal so lassen.

Vielen Dank für die interessante Diskussion, und hoffentlich (oder lieber nicht?) ergibt sich bald ein neuer Thread!

mfg

Dirk

#9

P.S.:

Habe jetzt meine „Große“ Datei umsetzen lassen und bin begeistert. Von ca. 70 Minuten auf eine halbe Minuteb Laufzeit. Mensch was willst du mehr!

Werde jetzt in einer anderen Applikation, die auch arg langsam ist, nach unnötigen like suchen!

Vielen Dank

Dirk.

#10

Hi

hast du auf dem feld sp1, sp2 und sp3 einen index definiert?

Nein, aber damit wird´s auch nicht besser.

und wieso nicht? alles was im where kommen kann sollte eigentlich einen index kriegen!

gruss

#11

Hallo

Hi

hast du auf dem feld sp1, sp2 und sp3 einen index definiert?

Nein, aber damit wird´s auch nicht besser.

und wieso nicht? alles was im where kommen kann sollte
eigentlich einen index kriegen!

Sehe ich ja ein. Aber bei meinen „Messungen“ hat sich kein sichtbarer Erfolg eingestellt. Das mit dem like war entscheidend. Kann es sein, dass für ein like da anders reagiert als ein „=“ ?

mfg

Dirk

#12

Sehe ich ja ein. Aber bei meinen „Messungen“ hat sich kein
sichtbarer Erfolg eingestellt. Das mit dem like war
entscheidend. Kann es sein, dass für ein like da anders
reagiert als ein „=“ ?

ja das ist so. = ist schneller als like.

gruss