Tweet
Hallo,
bin neu hier in der Runde und hoffe, jemand kann mir die Richtung weisen
.
OS : Windows
FB 2.03 auf der Entwicklungsmaschine als Server , bei der Auslieferung z.T. als Embedded.
IDE: Delphi6 ( mehr ist nicht greifbar)
Ich nutze die IB Standardkomponenten (darf nichts kosten s. oben)
Ich bin gerade dabei einige ältere Applikationen mit Paradox, neu auf Basis von Firebird zu realisieren.
Erste zwei Programme sind bereits bei den Kunden und auch OK.
Bei dem dritten Programm stockt es aber.
Zum Problem:
Bei einer (sehr breiten – 161 Spalten) Tabelle mit ca. 98.000 rows Dauert es sehr lange bis die Inhalte umsortiert werden.
Fachlich bedingt soll jede der unzähligen Spalten p. Mouseklick sortierbar sein.
Beim Query auf Spalte ohne Index dauert es bei default-Einstellung BufferChunks satte 54 Sekunden bis die Tabelle umsortiert ist. Bei Indizierten Spalten erheblich kürzer, an sich aber auch zu lange.
Setzte ich BufferChunks hoch bekommt die Sortierung `nen Turbogang rein aber...
Nach einigen Query-Sortierungen, egal ob zusätzliche Select-Einschränkungen da sind oder nicht, kommt die Exception der Klasse EOutOfMemory : Zu wenig Arbeitsspeicher.
Dabei werden von den vorhandenen 2GB led. 560MB (für alles, samt Betriebssystem) verbraucht.
Es sind durchgehend nur Leseoperationen, kein Insert oder Update. Alles p. Query. Jedes mal wird close/clear/add( für SQL – Statement - dynamisch, abhängig von Spalte)/open neu aufgesetzt.
Fragen:
- wie beschleunigt man das Lesen/Sortieren der Tabelle.
Aufteilung, egal in welche Richtung, steht nicht zur Debatte – Alle Werte (90% der Spalten sind Zahlen) der Tabellenzeile müssen im einem dBGrid angezeigt werden. Auch alle Spalten müssen zum sofortigen Zugriff zugänglich sein.
- wie stellt man den vermeintlichen Speichermangel ab?
Ich weiß es – alles ein wenig verwischt und unpräzise, ist aber schwierig zu beschreiben. Vielleicht doch irgendwelche Tipps?
Adam
bin neu hier in der Runde und hoffe, jemand kann mir die Richtung weisen
.OS : Windows
FB 2.03 auf der Entwicklungsmaschine als Server , bei der Auslieferung z.T. als Embedded.
IDE: Delphi6 ( mehr ist nicht greifbar)
Ich nutze die IB Standardkomponenten (darf nichts kosten s. oben)
Ich bin gerade dabei einige ältere Applikationen mit Paradox, neu auf Basis von Firebird zu realisieren.
Erste zwei Programme sind bereits bei den Kunden und auch OK.
Bei dem dritten Programm stockt es aber.
Zum Problem:
Bei einer (sehr breiten – 161 Spalten) Tabelle mit ca. 98.000 rows Dauert es sehr lange bis die Inhalte umsortiert werden.
Fachlich bedingt soll jede der unzähligen Spalten p. Mouseklick sortierbar sein.
Beim Query auf Spalte ohne Index dauert es bei default-Einstellung BufferChunks satte 54 Sekunden bis die Tabelle umsortiert ist. Bei Indizierten Spalten erheblich kürzer, an sich aber auch zu lange.
Setzte ich BufferChunks hoch bekommt die Sortierung `nen Turbogang rein aber...
Nach einigen Query-Sortierungen, egal ob zusätzliche Select-Einschränkungen da sind oder nicht, kommt die Exception der Klasse EOutOfMemory : Zu wenig Arbeitsspeicher.
Dabei werden von den vorhandenen 2GB led. 560MB (für alles, samt Betriebssystem) verbraucht.
Es sind durchgehend nur Leseoperationen, kein Insert oder Update. Alles p. Query. Jedes mal wird close/clear/add( für SQL – Statement - dynamisch, abhängig von Spalte)/open neu aufgesetzt.
Fragen:
- wie beschleunigt man das Lesen/Sortieren der Tabelle.
Aufteilung, egal in welche Richtung, steht nicht zur Debatte – Alle Werte (90% der Spalten sind Zahlen) der Tabellenzeile müssen im einem dBGrid angezeigt werden. Auch alle Spalten müssen zum sofortigen Zugriff zugänglich sein.
- wie stellt man den vermeintlichen Speichermangel ab?
Ich weiß es – alles ein wenig verwischt und unpräzise, ist aber schwierig zu beschreiben. Vielleicht doch irgendwelche Tipps?
Adam
einiges in Java machen muss.
Comment