Programm wird lansamer bei Mehrbenutzerzugriffen
Moderator: Moderatoren
- andreas
- Der Entwickler von "Deep Thought"
- Beiträge: 1902
- Registriert: Mi, 28. Sep 2005 10:53
- Wohnort: Osnabrück
- Hat sich bedankt: 4 Mal
- Kontaktdaten:
Programm wird lansamer bei Mehrbenutzerzugriffen
Hallo Leute,
ich habe ein Geschwindigkeitsproblem.
Wenn nur ein Benutzer mit dem Programm arbeitet, geht es noch. So bald ein weiterer Benutzer das Programm startet, wird das Programm bemerkbar langsam bei beiden Benutzern. Ich verwende FoxPro-Dateien. An der Stelle, wo es langsam wird, muss ich Filter einsetzen, da es nicht anders geht.
Hat jemand eine Idee? Umstieg auf ADS geht nicht, da es die Daten eines anderen Programms vom Drittanbieter sind.
ich habe ein Geschwindigkeitsproblem.
Wenn nur ein Benutzer mit dem Programm arbeitet, geht es noch. So bald ein weiterer Benutzer das Programm startet, wird das Programm bemerkbar langsam bei beiden Benutzern. Ich verwende FoxPro-Dateien. An der Stelle, wo es langsam wird, muss ich Filter einsetzen, da es nicht anders geht.
Hat jemand eine Idee? Umstieg auf ADS geht nicht, da es die Daten eines anderen Programms vom Drittanbieter sind.
- brandelh
- Foren-Moderator
- Beiträge: 15710
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 73 Mal
- Danksagung erhalten: 38 Mal
- Kontaktdaten:
Hallo,
versuche wenn irgendmöglich die Datensatzanzahl über einen führenden Index zu begrenzen und die Grenzen mit scope festzulegen, den Rest filtern.
Ansonsten ginge eventuell pro Abfrage ein bedingter Index.
Wenn du die Satznummern der gewünschten Datensätze in ein Array einliest, geht nachher wenigstens das blättern schneller. Allerdings müssen dann die codeblocks alle auf Arraysprünge umgestellt werden.
Das Array könnte auch ein eigener Thread einlesen, während du die ersten Treffer anzeigst ...
Oder versuche den Filterbegriff zu vereinfachen.
Wie groß sind denn die Datenbestände ?
versuche wenn irgendmöglich die Datensatzanzahl über einen führenden Index zu begrenzen und die Grenzen mit scope festzulegen, den Rest filtern.
Ansonsten ginge eventuell pro Abfrage ein bedingter Index.
Wenn du die Satznummern der gewünschten Datensätze in ein Array einliest, geht nachher wenigstens das blättern schneller. Allerdings müssen dann die codeblocks alle auf Arraysprünge umgestellt werden.
Das Array könnte auch ein eigener Thread einlesen, während du die ersten Treffer anzeigst ...
Oder versuche den Filterbegriff zu vereinfachen.
Wie groß sind denn die Datenbestände ?
Gruß
Hubert
Hubert
- andreas
- Der Entwickler von "Deep Thought"
- Beiträge: 1902
- Registriert: Mi, 28. Sep 2005 10:53
- Wohnort: Osnabrück
- Hat sich bedankt: 4 Mal
- Kontaktdaten:
Hallo Brandelh,
die Datei hat zur Zeit über 240000 Datensätze und wächst ständig weiter. Deswegen wird es etwas schwieriger mit dem Einlesen in ein Array.
Mit den Index habe ich auch schon überlegt. Das Problem liegt aber daran, das die Datenbanken aus dem Programm vom Drittanbieter kommen und das Programm in Visual FoxPro geschrieben ist. Die Datenbanken sind irgendiwe intern mit den Indexdateien verknüpft, so dass beim Öffnen der Datei in FoxPro die Indexdatei automatisch mitgeöffnet wird. Bei Programmupdates werden die Indexdateien neu erstellt, so dass ich meine Indexes verlieren würde. Mit dem Erstellen temporärer Indexes habe ich nicht probiert, da ich Angst habe, dass diese automatische Indexverknüpfung evtl. gestört wird, was zu Problemmen in dem Programm führen könnte.
Der Filter in meinem Programm ist schon minimal gestaltet, muss aber für die Suche immer nach der Benutzereingaben neu gesetzt werden, wobei auch schon Set Scope verwendet wird.
die Datei hat zur Zeit über 240000 Datensätze und wächst ständig weiter. Deswegen wird es etwas schwieriger mit dem Einlesen in ein Array.
Mit den Index habe ich auch schon überlegt. Das Problem liegt aber daran, das die Datenbanken aus dem Programm vom Drittanbieter kommen und das Programm in Visual FoxPro geschrieben ist. Die Datenbanken sind irgendiwe intern mit den Indexdateien verknüpft, so dass beim Öffnen der Datei in FoxPro die Indexdatei automatisch mitgeöffnet wird. Bei Programmupdates werden die Indexdateien neu erstellt, so dass ich meine Indexes verlieren würde. Mit dem Erstellen temporärer Indexes habe ich nicht probiert, da ich Angst habe, dass diese automatische Indexverknüpfung evtl. gestört wird, was zu Problemmen in dem Programm führen könnte.
Der Filter in meinem Programm ist schon minimal gestaltet, muss aber für die Suche immer nach der Benutzereingaben neu gesetzt werden, wobei auch schon Set Scope verwendet wird.
- andreas
- Der Entwickler von "Deep Thought"
- Beiträge: 1902
- Registriert: Mi, 28. Sep 2005 10:53
- Wohnort: Osnabrück
- Hat sich bedankt: 4 Mal
- Kontaktdaten:
Hallo Thomas,
hast du vielleicht ein Beispiel für Öffnen der FoxPro-Dateien über ODBC?
So weit ich gehört habe, ist der FoxPro-Treiber bei MDAC nicht mehr dabei. Wo kann ich dann nehmen, ohne FoxPro zu installieren.
Kann ich dann vielleicht auch die Daten zurückschreiben? (Letzte Frage ist erstmal nicht so wichtig.)
hast du vielleicht ein Beispiel für Öffnen der FoxPro-Dateien über ODBC?
So weit ich gehört habe, ist der FoxPro-Treiber bei MDAC nicht mehr dabei. Wo kann ich dann nehmen, ohne FoxPro zu installieren.
Kann ich dann vielleicht auch die Daten zurückschreiben? (Letzte Frage ist erstmal nicht so wichtig.)
- andreas
- Der Entwickler von "Deep Thought"
- Beiträge: 1902
- Registriert: Mi, 28. Sep 2005 10:53
- Wohnort: Osnabrück
- Hat sich bedankt: 4 Mal
- Kontaktdaten:
Ich habe noch was festgestellt. In meinem Programm gib es eine Auswahl, nach der die Filterbediengungen ausgewählt werden:
Bei der Auswahl der letzten 2 Bediengungen funktioniert es schneller als bei der ersten. Warum?
Code: Alles auswählen
local cWert := alltrim(::einAuswahl:XBPSle:getdata())
IF cWert=="SONSTIGE"
set filter to (be1_zugang-be1_abgang)>0 .AND. alltrim(be1_name)!="FERTIGUNG"
elseIF cWert=="FERTIGUNG"
set filter to (be1_zugang-be1_abgang)>0 .AND. alltrim(be1_name)=="FERTIGUNG"
else
set filter to (be1_zugang-be1_abgang)>0
ENDIF
-
- Rekursionen-Architekt
- Beiträge: 116
- Registriert: Fr, 23. Sep 2005 16:07
- Wohnort: Bad Oldesloe
- Kontaktdaten:
Hallo Andreas.
Den ODBC-Treiber für FoxPro findest du hier => http://msdn.microsoft.com/vfoxpro/downl ... fault.aspx
Mit dem SQL Update Statement kannst du auch Daten speichern.
Ein Beispiel mit FoxPro kann ich dir leider nicht liefern, denn ich hatte noch kein
Anwendungsfall in diesem Bereich gehabt.
Gruß
Thomas
Den ODBC-Treiber für FoxPro findest du hier => http://msdn.microsoft.com/vfoxpro/downl ... fault.aspx
Mit dem SQL Update Statement kannst du auch Daten speichern.
Ein Beispiel mit FoxPro kann ich dir leider nicht liefern, denn ich hatte noch kein
Anwendungsfall in diesem Bereich gehabt.
Gruß
Thomas
- Lewi
- 1000 working lines a day
- Beiträge: 830
- Registriert: Di, 07. Feb 2006 14:10
- Wohnort: Hamburg
- Danksagung erhalten: 2 Mal
Hallo!
Ich gehe mal davon aus, das Deine Anwendung nur lesend auf die Daten der externen Anwendung zugreift.
Wenn dies der Fall, spricht überhaupt nichts dagegen, mit eigenen Index-Dateien zu arbeiten. Du kannst die Datenbank öffnen, ohne das die orginären Index-Dateien der Fremdapplikation mit geöffnet werden.
Allerdings stellt sich dann das Problem, dass die "eigenen" Index-Dateien bei Datenänderungen bzw. bei neuen Datensätzen nicht automatisch aktualisiert werden. Vor der Selektion ist dann ein reindex durchzuführen oder Du baust die Indexdateien in Abhängigkeit der Filterbedingung temporär auf.
Im Übrigen empfehle ich Dir, ein "SetFilter()" unter Einbeziehung der Optimierungsstrategien von "SET OPTIMIZE" und "SET SMARTFILTER" zu testen.
Zu Deiner Geschwindigkeitsfrage: ersetzte im ersten Fillter doch mal "!=" mit "<>"
Gruß, Olaf
Ich gehe mal davon aus, das Deine Anwendung nur lesend auf die Daten der externen Anwendung zugreift.
Wenn dies der Fall, spricht überhaupt nichts dagegen, mit eigenen Index-Dateien zu arbeiten. Du kannst die Datenbank öffnen, ohne das die orginären Index-Dateien der Fremdapplikation mit geöffnet werden.
Allerdings stellt sich dann das Problem, dass die "eigenen" Index-Dateien bei Datenänderungen bzw. bei neuen Datensätzen nicht automatisch aktualisiert werden. Vor der Selektion ist dann ein reindex durchzuführen oder Du baust die Indexdateien in Abhängigkeit der Filterbedingung temporär auf.
Im Übrigen empfehle ich Dir, ein "SetFilter()" unter Einbeziehung der Optimierungsstrategien von "SET OPTIMIZE" und "SET SMARTFILTER" zu testen.
Zu Deiner Geschwindigkeitsfrage: ersetzte im ersten Fillter doch mal "!=" mit "<>"
Gruß, Olaf
- AUGE_OHR
- Marvin
- Beiträge: 12913
- Registriert: Do, 16. Mär 2006 7:55
- Wohnort: Hamburg
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 46 Mal
Re: Programm wird lansamer bei Mehrbenutzerzugriffen
hi,
und wo sich die *.DBF befinden (Server) und wie du darauf zugreifst
(TCP ? welcher Network-Client ? )
ist wohl der "schnellste" Weg. ansonsten hab ich immer $ benutzte .
IF "FERTIGUNG" $ myField->XYZ
"FELD"der ( FCOUNT() ), dann die Index (TAGs) Files (Indexkey).
das Problem beim "updaten" sollte "lösbar" sein
gruss by OHR
Jimmy
du hast noch nicht erwähnt welches OS (Client / Server)andreas hat geschrieben: Wenn nur ein Benutzer mit dem Programm arbeitet, geht es noch. So
bald ein weiterer Benutzer das Programm startet, wird das Programm
bemerkbar langsam bei beiden Benutzern. Ich verwende FoxPro-Dateien.
und wo sich die *.DBF befinden (Server) und wie du darauf zugreifst
(TCP ? welcher Network-Client ? )
betr. SET FILTER hast du ja selbst schon mit SCOPE gearbeitet. Diesandreas hat geschrieben: An der Stelle, wo es langsam wird, muss ich Filter einsetzen,
da es nicht anders geht.
ist wohl der "schnellste" Weg. ansonsten hab ich immer $ benutzte .
IF "FERTIGUNG" $ myField->XYZ
naja, ich überprüfe beim öffnen von *.DBF erstmal die Anzahl derandreas hat geschrieben: Bei Programmupdates werden die Indexdateien neu erstellt,
so dass ich meine Indexes verlieren würde
"FELD"der ( FCOUNT() ), dann die Index (TAGs) Files (Indexkey).
das Problem beim "updaten" sollte "lösbar" sein
gruss by OHR
Jimmy
- andreas
- Der Entwickler von "Deep Thought"
- Beiträge: 1902
- Registriert: Mi, 28. Sep 2005 10:53
- Wohnort: Osnabrück
- Hat sich bedankt: 4 Mal
- Kontaktdaten:
Hallo Olaf,
"SET OPTIMIZE" und "SET SMARTFILTER" setze ich schon ein. Leider habe ich nur ein Index, der dafür nur zum Teil passt.
Ich konnte jetzt ein Wenig die Geschwindigkeit erhöhen, in dem ich den Aufruf der Filterfunktion reduziert habe. Früher wurde bei jedem Keyboard-Ereignis die Funktion aufgerufen. Jetzt passiert es nur bei der Bestätigung mit ENTER.
Das hat einiges gebracht aber noch nicht genug.
so weit ich weiss, führt DbSetFilter() das gleiche aus, wie Set Filter.Im Übrigen empfehle ich Dir, ein "SetFilter()" unter Einbeziehung der Optimierungsstrategien von "SET OPTIMIZE" und "SET SMARTFILTER" zu testen.
"SET OPTIMIZE" und "SET SMARTFILTER" setze ich schon ein. Leider habe ich nur ein Index, der dafür nur zum Teil passt.
Das habe ich auch schon probiert. Kein Ergebnis.Zu Deiner Geschwindigkeitsfrage: ersetzte im ersten Fillter doch mal "!=" mit "<>"
Ich konnte jetzt ein Wenig die Geschwindigkeit erhöhen, in dem ich den Aufruf der Filterfunktion reduziert habe. Früher wurde bei jedem Keyboard-Ereignis die Funktion aufgerufen. Jetzt passiert es nur bei der Bestätigung mit ENTER.
Das hat einiges gebracht aber noch nicht genug.
- andreas
- Der Entwickler von "Deep Thought"
- Beiträge: 1902
- Registriert: Mi, 28. Sep 2005 10:53
- Wohnort: Osnabrück
- Hat sich bedankt: 4 Mal
- Kontaktdaten:
Hallo Jimmy,
in der Arbeitsumgebung liegen Daten auf dem Windows 2003 Server. Der Zugriff läuft über verbundene Netzlaufwerke. Die Client sind Windows 98 bis XP.
In der Testumgebung liegen die Daten auf dem Linux-Server mit Samba-Freigaben. Der Zugriff erfolgt auch über verbundene Neztlaufwerke. Client-Systeme: Windows XP.
In beiden Fällen habe ich das gleiche Problem.
in der Arbeitsumgebung liegen Daten auf dem Windows 2003 Server. Der Zugriff läuft über verbundene Netzlaufwerke. Die Client sind Windows 98 bis XP.
In der Testumgebung liegen die Daten auf dem Linux-Server mit Samba-Freigaben. Der Zugriff erfolgt auch über verbundene Neztlaufwerke. Client-Systeme: Windows XP.
In beiden Fällen habe ich das gleiche Problem.
Ich muss den Filter einsetzen, da kein passender Index vorhanden ist und dafür noch Berechnung in der Bediengung stattfinden muss, da nur die Daten mit vorhandenem Bestand angezeigt werden müssen.betr. SET FILTER hast du ja selbst schon mit SCOPE gearbeitet. Dies
ist wohl der "schnellste" Weg. ansonsten hab ich immer $ benutzte
Was meinst du damit? Wie könnte ich das beim Filtern einsetzen?IF "FERTIGUNG" $ myField->XYZ
Die Updates führt das Fremdprogramm, was das ganze erschwert. Vielleicht bringt der XBase++ 1.9 mit seinen temporären Indexes die Lösung.naja, ich überprüfe beim öffnen von *.DBF erstmal die Anzahl der
"FELD"der ( FCOUNT() ), dann die Index (TAGs) Files (Indexkey).
das Problem beim "updaten" sollte "lösbar" sein
- AUGE_OHR
- Marvin
- Beiträge: 12913
- Registriert: Do, 16. Mär 2006 7:55
- Wohnort: Hamburg
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 46 Mal
bei Linux kenne ich mich nicht aus, aber auf dem W2003 Server / Client :andreas hat geschrieben: in der Arbeitsumgebung liegen Daten auf dem Windows 2003 Server. Der Zugriff läuft über verbundene Netzlaufwerke. Die Client sind Windows 98 bis XP.
In der Testumgebung liegen die Daten auf dem Linux-Server mit Samba-Freigaben. Der Zugriff erfolgt auch über verbundene Neztlaufwerke. Client-Systeme: Windows XP.
In beiden Fällen habe ich das gleiche Problem.
"Opportunistic locking" gesetzt ?
set filter to (be1_zugang-be1_abgang)>0 .AND. alltrim(be1_name)=="FERTIGUNGIF "FERTIGUNG" $ myField->XYZ
Was meinst du damit? Wie könnte ich das beim Filtern einsetzen?
set filter to (be1_zugang-be1_abgang)>0 .AND. "FERTIGUNG" $ be1_name
! Achtung bei $ evtl SET RUSHMORE OFF, SET SMARTFILTER OFF,
SET OPTIMIZE OFF
schon verstanden, aber trotzdem kann deine Anwendung doch trotzdemnaja, ich überprüfe beim öffnen von *.DBF erstmal die Anzahl der
"FELD"der ( FCOUNT() ), dann die Index (TAGs) Files (Indexkey).
das Problem beim "updaten" sollte "lösbar" sein
Die Updates führt das Fremdprogramm, was das ganze erschwert.
sowas prüfen und ggf. "overrulen". Es macht dem Fremdprogramm
normal nichts aus wenn du z.b. den IndexKey() am "Ende" erweiterst
oder weiter "TAGs" hinzufügst. Auch sollten *.CDX Dateien, wenn ich mich
nicht irre, unter VFP automatisch mit der *.DBF geöffnet werden und somit
das "updaten" kein Problem darstellen.
ja das könnte auch noch eine Lösung sein ...Vielleicht bringt der XBase++ 1.9 mit seinen temporären Indexes die Lösung.
gruss by OHR
Jimmy
- brandelh
- Foren-Moderator
- Beiträge: 15710
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 73 Mal
- Danksagung erhalten: 38 Mal
- Kontaktdaten:
Hallo,
sowohl der Filter als auch ein temporärer Index muss einmal die ganze Datei durchsuchen, um an die gewünschten Datensätze zu kommen.
Insoweit kann man nur dem Indexbegriff alle unnötigen Berechnungen abnehmen und diese vorher machen.
Wenn die Daten nur als 'Schnappschuß' für die weitere Verwendung benötigt werden, wie wäre es mit dbexport() in eine eigene temporäre Datei auf der lokalen Festplatte (oder copy fields ... to). Nur passende Sätze mit den nötigsten Feldern. Auswertungen und Anzeige darauf wäre wieder schnell. Wenn man einen eindeutigen Schlüssel benötigt, und in den Feldern keinen hat, wäre eine eigene Exporroutine nicht schlecht, welche per DBeval() die nötigen Datensätze in eine Ziel DBF kopiert und in einem Feld dann die Ursprungs-RECNO speichert. Packen darf man dann natürlich zwischenzeitlich nicht
PS: ich würde die Originaldatei auch nur READONLY öffnen, dann gibt es keine Probleme mit VisualFoxPro.
sowohl der Filter als auch ein temporärer Index muss einmal die ganze Datei durchsuchen, um an die gewünschten Datensätze zu kommen.
Insoweit kann man nur dem Indexbegriff alle unnötigen Berechnungen abnehmen und diese vorher machen.
Wenn die Daten nur als 'Schnappschuß' für die weitere Verwendung benötigt werden, wie wäre es mit dbexport() in eine eigene temporäre Datei auf der lokalen Festplatte (oder copy fields ... to). Nur passende Sätze mit den nötigsten Feldern. Auswertungen und Anzeige darauf wäre wieder schnell. Wenn man einen eindeutigen Schlüssel benötigt, und in den Feldern keinen hat, wäre eine eigene Exporroutine nicht schlecht, welche per DBeval() die nötigen Datensätze in eine Ziel DBF kopiert und in einem Feld dann die Ursprungs-RECNO speichert. Packen darf man dann natürlich zwischenzeitlich nicht
PS: ich würde die Originaldatei auch nur READONLY öffnen, dann gibt es keine Probleme mit VisualFoxPro.
Gruß
Hubert
Hubert
Hallo Andreas,
ich meine Hubert hat da schon den richtigen Weg vorgegeben. Der Zeitunterschied zwichen set filter und der Arbeit mit Index ist riesig.
Solange Du nicht in die Original-DB schreiben musst, können Dir deren Indexe etc. egal sein. Ich mache bei uns folgendes: Wir haben mehrere Lager aus denen der Nutzer Artikel in den verschiedensten Fertigungsstufen abruft, um z.B. Liefertermine zusagen zu können. Der Nutzer gibt die gesuchten Daten ein, mehr oder weniger differenziert, dann importiere (DbImport) ich die gesuchten Daten aus allen Lager-DB's in eine DB auf LW C (vorher leeren), erstelle hier die Indexe (z.B. gestaffelt nach Fertigungsstufe) und gebe die Informationen auf Bildschirm und/oder Drucker aus. Wenn man die DB auf LW C auf die gerade nötigen Felder reduziert, wird's noch schneller.
Gruß MaBeLa
ich meine Hubert hat da schon den richtigen Weg vorgegeben. Der Zeitunterschied zwichen set filter und der Arbeit mit Index ist riesig.
Solange Du nicht in die Original-DB schreiben musst, können Dir deren Indexe etc. egal sein. Ich mache bei uns folgendes: Wir haben mehrere Lager aus denen der Nutzer Artikel in den verschiedensten Fertigungsstufen abruft, um z.B. Liefertermine zusagen zu können. Der Nutzer gibt die gesuchten Daten ein, mehr oder weniger differenziert, dann importiere (DbImport) ich die gesuchten Daten aus allen Lager-DB's in eine DB auf LW C (vorher leeren), erstelle hier die Indexe (z.B. gestaffelt nach Fertigungsstufe) und gebe die Informationen auf Bildschirm und/oder Drucker aus. Wenn man die DB auf LW C auf die gerade nötigen Felder reduziert, wird's noch schneller.
Gruß MaBeLa
- Lewi
- 1000 working lines a day
- Beiträge: 830
- Registriert: Di, 07. Feb 2006 14:10
- Wohnort: Hamburg
- Danksagung erhalten: 2 Mal
Jimmy schrieb:
Wie auch immer. Temporäre Indexe sind im Prinzip mit jeder xbase-Version möglich. Die Index-Dateien müssen halt nur einen von der Datenbank unabhäbgigen Namen bekommen. Index-Dateien können separat geöffnet werden.
Wenn Setfilter() als solches zu langsam ist, dann bleibt nur der Weg über (separate) Indexdateien. Insofern vermag ich der Diskussion nicht mehr ganz zu folgen, weil der Lösungsansatz doch offentsichlich auf der Hand liegt.
Gruß, Olaf
Davon würde ich aus vielerlei Gründen dringend abraten. Zum einen könnte die Fremdanwendung einen weiteren Tag erstellen oder Tags erstellen, die einen Funktionaufruf enthalten, der in der Auswertungsanwendung nicht zur Verfügung steht.chon verstanden, aber trotzdem kann deine Anwendung doch trotzdem
sowas prüfen und ggf. "overrulen". Es macht dem Fremdprogramm
normal nichts aus wenn du z.b. den IndexKey() am "Ende" erweiterst
oder weiter "TAGs" hinzufügst. Auch sollten *.CDX Dateien, wenn ich mich
nicht irre, unter VFP automatisch mit der *.DBF geöffnet werden und somit
das "updaten" kein Problem darstellen.
Wie auch immer. Temporäre Indexe sind im Prinzip mit jeder xbase-Version möglich. Die Index-Dateien müssen halt nur einen von der Datenbank unabhäbgigen Namen bekommen. Index-Dateien können separat geöffnet werden.
Wenn Setfilter() als solches zu langsam ist, dann bleibt nur der Weg über (separate) Indexdateien. Insofern vermag ich der Diskussion nicht mehr ganz zu folgen, weil der Lösungsansatz doch offentsichlich auf der Hand liegt.
Gruß, Olaf
- andreas
- Der Entwickler von "Deep Thought"
- Beiträge: 1902
- Registriert: Mi, 28. Sep 2005 10:53
- Wohnort: Osnabrück
- Hat sich bedankt: 4 Mal
- Kontaktdaten:
Hallo Leute,
ich habe das mit allen vorgeschlagenen Methoden ausprobiert.
Das Problem mit der Geschwindigkeit scheint nur bei der Benutzung des Befehls "SET FILTER" aufzutretten.
Bei der Umstellung auf zus. Indextags und ausschliessliche Benutzung des Befehls "SET SCOPE" mit der passender Tag-Umschaltung bei der Auswahl hat die besten Ergebnisse gebracht.
Da die Datenbanken zu einem Fremdprogramm gehören, habe ich nach dem Öffnen der Datenbanken überprüft, ob meine eigene Indextags vorhanden sind. Notfalls müssen die angelegt werden. Ein Nachteil dabei ist, dass die Datenbank exclusive geöffnet werden muss, um die Tags anlegen zu können.
Wenn die Tags nicht angelegt werden können, kommt eine Meldung und die Funktionsausführung wird blockiert.
Danke für alle Vorschläge.
ich habe das mit allen vorgeschlagenen Methoden ausprobiert.
Das Problem mit der Geschwindigkeit scheint nur bei der Benutzung des Befehls "SET FILTER" aufzutretten.
Bei der Umstellung auf zus. Indextags und ausschliessliche Benutzung des Befehls "SET SCOPE" mit der passender Tag-Umschaltung bei der Auswahl hat die besten Ergebnisse gebracht.
Da die Datenbanken zu einem Fremdprogramm gehören, habe ich nach dem Öffnen der Datenbanken überprüft, ob meine eigene Indextags vorhanden sind. Notfalls müssen die angelegt werden. Ein Nachteil dabei ist, dass die Datenbank exclusive geöffnet werden muss, um die Tags anlegen zu können.
Wenn die Tags nicht angelegt werden können, kommt eine Meldung und die Funktionsausführung wird blockiert.
Danke für alle Vorschläge.
- Lewi
- 1000 working lines a day
- Beiträge: 830
- Registriert: Di, 07. Feb 2006 14:10
- Wohnort: Hamburg
- Danksagung erhalten: 2 Mal
Hi Andreas,
Du könntest die Probleme der "exclusiven Öffnung" umgehen, indem Du von die entsprechenden Dateien der Fremdanwendung für die Auswertung in temporäre Dateien kopierst. Dann kannst auf die "temporäre" Datei "exclusive" zugreifen. Do solltest dabei im Mehrbenutzerzugriff allerdings beachten, dass für jeden Client jeweils eigene tempäre Dateien erzeugt werden.
Vielleicht hilft Dir dieser Tip ja weiter.
Du könntest die Probleme der "exclusiven Öffnung" umgehen, indem Du von die entsprechenden Dateien der Fremdanwendung für die Auswertung in temporäre Dateien kopierst. Dann kannst auf die "temporäre" Datei "exclusive" zugreifen. Do solltest dabei im Mehrbenutzerzugriff allerdings beachten, dass für jeden Client jeweils eigene tempäre Dateien erzeugt werden.
Vielleicht hilft Dir dieser Tip ja weiter.
- Armin
- Rekursionen-Architekt
- Beiträge: 394
- Registriert: Mo, 26. Sep 2005 12:09
- Wohnort: 75331 Engelsbrand
- Danksagung erhalten: 3 Mal
- Kontaktdaten:
local cWert := alltrim(::einAuswahl:XBPSle:getdata())
IF cWert=="SONSTIGE"
set filter to (be1_zugang-be1_abgang)>0 .AND. alltrim(be1_name)!="FERTIGUNG"
elseIF cWert=="FERTIGUNG"
set filter to (be1_zugang-be1_abgang)>0 .AND. alltrim(be1_name)=="FERTIGUNG"
else
set filter to (be1_zugang-be1_abgang)>0
ENDIF
das Pendant wäre: !(alltrim(be1_name)=="FERTIGUNG")
IF cWert=="SONSTIGE"
set filter to (be1_zugang-be1_abgang)>0 .AND. alltrim(be1_name)!="FERTIGUNG"
elseIF cWert=="FERTIGUNG"
set filter to (be1_zugang-be1_abgang)>0 .AND. alltrim(be1_name)=="FERTIGUNG"
else
set filter to (be1_zugang-be1_abgang)>0
ENDIF
das Pendant wäre: !(alltrim(be1_name)=="FERTIGUNG")
- andreas
- Der Entwickler von "Deep Thought"
- Beiträge: 1902
- Registriert: Mi, 28. Sep 2005 10:53
- Wohnort: Osnabrück
- Hat sich bedankt: 4 Mal
- Kontaktdaten:
Hallo Lewi,
die Erstellung temporärer Dateien habe ich schon abgeschlagen, da es zu lange dauern würde.
Deswegen das erstellen der zus. Indextags, die einmalig erzeugt werden müssen und ständig aktuell bleiben.
Zum Erstellen der Tags kann ich auch damit leben, dass ich nach dem Update des Fremdprogramms einmalig das Programm an einem Arbeitsplatz starte, um exclusiven Zugriff zu bekommen.
Die früheren Filterbediengungen habe ich als FOR-Bedingung in den Tags angegeben, was die Sache sehr schnell macht und keine temporären Daten mehr braucht.
die Erstellung temporärer Dateien habe ich schon abgeschlagen, da es zu lange dauern würde.
Deswegen das erstellen der zus. Indextags, die einmalig erzeugt werden müssen und ständig aktuell bleiben.
Zum Erstellen der Tags kann ich auch damit leben, dass ich nach dem Update des Fremdprogramms einmalig das Programm an einem Arbeitsplatz starte, um exclusiven Zugriff zu bekommen.
Die früheren Filterbediengungen habe ich als FOR-Bedingung in den Tags angegeben, was die Sache sehr schnell macht und keine temporären Daten mehr braucht.
- andreas
- Der Entwickler von "Deep Thought"
- Beiträge: 1902
- Registriert: Mi, 28. Sep 2005 10:53
- Wohnort: Osnabrück
- Hat sich bedankt: 4 Mal
- Kontaktdaten:
Hallo Armin,
dein Vorschlag
habe ich schon vorher selbst ausprobiert. Das bringt aber nichts.
Die Erstellung zus. Indextags hat mein Problem gelösst und ich denke, dass damit diser Posting abgeschlossen werden kann.
dein Vorschlag
Code: Alles auswählen
!(alltrim(be1_name)=="FERTIGUNG")
Die Erstellung zus. Indextags hat mein Problem gelösst und ich denke, dass damit diser Posting abgeschlossen werden kann.
- Martin Altmann
- Foren-Administrator
- Beiträge: 16586
- Registriert: Fr, 23. Sep 2005 4:58
- Wohnort: Berlin
- Hat sich bedankt: 116 Mal
- Danksagung erhalten: 48 Mal
- Kontaktdaten:
Hallo Andreas,
Viele Grüße,
Martin
Dein Wunsch ist mir Befehl...andreas hat geschrieben:Die Erstellung zus. Indextags hat mein Problem gelösst und ich denke, dass damit diser Posting abgeschlossen werden kann.
Viele Grüße,
Martin
Webseite mit XB2.NET und ausschließlich statischem Content in Form von HTML-Dateien: https://www.altem.de/
Webseite mit XB2.NET und ausschließlich dynamischem Content in Form von in-memory-HTML: https://meldungen.altem.de/
Mitglied der XUG Osnabrück
Vorsitzender des Deutschsprachige Xbase-Entwickler e. V.