Programm wird lansamer bei Mehrbenutzerzugriffen

Zugriff, Engines, Konvertierung. Von ADS über DBF bis zu SQL.

Moderator: Moderatoren

Gesperrt
Benutzeravatar
andreas
Der Entwickler von "Deep Thought"
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

Beitrag von andreas »

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.
Gruß,

Andreas
VIP der XUG Osnabrück
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15688
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Beitrag von brandelh »

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 ?
Gruß
Hubert
Benutzeravatar
andreas
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 1902
Registriert: Mi, 28. Sep 2005 10:53
Wohnort: Osnabrück
Hat sich bedankt: 4 Mal
Kontaktdaten:

Beitrag von andreas »

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.
Gruß,

Andreas
VIP der XUG Osnabrück
thomas
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 116
Registriert: Fr, 23. Sep 2005 16:07
Wohnort: Bad Oldesloe
Kontaktdaten:

Beitrag von thomas »

Hallo Andreas.

Ich würde es mit ODBC versuchen, dann kannst Du mit SQL die Daten wunderbar filtern und auswerten.


Gruß

Thomas
Benutzeravatar
andreas
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 1902
Registriert: Mi, 28. Sep 2005 10:53
Wohnort: Osnabrück
Hat sich bedankt: 4 Mal
Kontaktdaten:

Beitrag von andreas »

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.)
Gruß,

Andreas
VIP der XUG Osnabrück
Benutzeravatar
andreas
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 1902
Registriert: Mi, 28. Sep 2005 10:53
Wohnort: Osnabrück
Hat sich bedankt: 4 Mal
Kontaktdaten:

Beitrag von andreas »

Ich habe noch was festgestellt. In meinem Programm gib es eine Auswahl, nach der die Filterbediengungen ausgewählt werden:

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
Bei der Auswahl der letzten 2 Bediengungen funktioniert es schneller als bei der ersten. Warum?
Gruß,

Andreas
VIP der XUG Osnabrück
thomas
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 116
Registriert: Fr, 23. Sep 2005 16:07
Wohnort: Bad Oldesloe
Kontaktdaten:

Beitrag von thomas »

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
Benutzeravatar
andreas
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 1902
Registriert: Mi, 28. Sep 2005 10:53
Wohnort: Osnabrück
Hat sich bedankt: 4 Mal
Kontaktdaten:

Beitrag von andreas »

Hallo Thomas,

ich habe es mit dem ODBC ausprobiert. Selbst Abrufen der Daten beim Programmstart ist schon deutlich langsamer als mit dem Filter beim normalen Zugriff.
Das kann ich so nicht einsetzen.
Gruß,

Andreas
VIP der XUG Osnabrück
thomas
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 116
Registriert: Fr, 23. Sep 2005 16:07
Wohnort: Bad Oldesloe
Kontaktdaten:

Beitrag von thomas »

Hallo Andreas.

Schade ! Hast du denn mit SQL die Daten vorher auch selektiert ?
z.B. SELECT * from aufträge where be1_zugang-be1_abgang > 0

Gruß
Thomas
Benutzeravatar
andreas
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 1902
Registriert: Mi, 28. Sep 2005 10:53
Wohnort: Osnabrück
Hat sich bedankt: 4 Mal
Kontaktdaten:

Beitrag von andreas »

Hallo Thomas,

ja, ich habe die Daten vorher selektiert und auch "Order BY" angegeben.
Das Abrufen der Daten hat lange gedauert und das Sortieren funktioniert garnicht.
Gruß,

Andreas
VIP der XUG Osnabrück
Benutzeravatar
Lewi
1000 working lines a day
1000 working lines a day
Beiträge: 830
Registriert: Di, 07. Feb 2006 14:10
Wohnort: Hamburg
Danksagung erhalten: 2 Mal

Beitrag von Lewi »

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
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: Programm wird lansamer bei Mehrbenutzerzugriffen

Beitrag von AUGE_OHR »

hi,
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.
du hast noch nicht erwähnt welches OS (Client / Server)
und wo sich die *.DBF befinden (Server) und wie du darauf zugreifst
(TCP ? welcher Network-Client ? )
andreas hat geschrieben: An der Stelle, wo es langsam wird, muss ich Filter einsetzen,
da es nicht anders geht.
betr. SET FILTER hast du ja selbst schon mit SCOPE gearbeitet. Dies
ist wohl der "schnellste" Weg. ansonsten hab ich immer $ benutzte .

IF "FERTIGUNG" $ myField->XYZ
andreas hat geschrieben: Bei Programmupdates werden die Indexdateien neu erstellt,
so dass ich meine Indexes verlieren würde
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

gruss by OHR
Jimmy
Benutzeravatar
andreas
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 1902
Registriert: Mi, 28. Sep 2005 10:53
Wohnort: Osnabrück
Hat sich bedankt: 4 Mal
Kontaktdaten:

Beitrag von andreas »

Hallo Olaf,
Im Übrigen empfehle ich Dir, ein "SetFilter()" unter Einbeziehung der Optimierungsstrategien von "SET OPTIMIZE" und "SET SMARTFILTER" zu testen.
so weit ich weiss, führt DbSetFilter() das gleiche aus, wie Set Filter.
"SET OPTIMIZE" und "SET SMARTFILTER" setze ich schon ein. Leider habe ich nur ein Index, der dafür nur zum Teil passt.
Zu Deiner Geschwindigkeitsfrage: ersetzte im ersten Fillter doch mal "!=" mit "<>"
Das habe ich auch schon probiert. Kein Ergebnis.

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.
Gruß,

Andreas
VIP der XUG Osnabrück
Benutzeravatar
andreas
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 1902
Registriert: Mi, 28. Sep 2005 10:53
Wohnort: Osnabrück
Hat sich bedankt: 4 Mal
Kontaktdaten:

Beitrag von andreas »

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.
betr. SET FILTER hast du ja selbst schon mit SCOPE gearbeitet. Dies
ist wohl der "schnellste" Weg. ansonsten hab ich immer $ benutzte
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.
IF "FERTIGUNG" $ myField->XYZ
Was meinst du damit? Wie könnte ich das beim Filtern einsetzen?
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
Die Updates führt das Fremdprogramm, was das ganze erschwert. Vielleicht bringt der XBase++ 1.9 mit seinen temporären Indexes die Lösung.
Gruß,

Andreas
VIP der XUG Osnabrück
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Beitrag von AUGE_OHR »

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.
bei Linux kenne ich mich nicht aus, aber auf dem W2003 Server / Client :
"Opportunistic locking" gesetzt ?
IF "FERTIGUNG" $ myField->XYZ
Was meinst du damit? Wie könnte ich das beim Filtern einsetzen?
set filter to (be1_zugang-be1_abgang)>0 .AND. alltrim(be1_name)=="FERTIGUNG

set filter to (be1_zugang-be1_abgang)>0 .AND. "FERTIGUNG" $ be1_name

! Achtung bei $ evtl SET RUSHMORE OFF, SET SMARTFILTER OFF,
SET OPTIMIZE OFF
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

Die Updates führt das Fremdprogramm, was das ganze erschwert.
schon 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.
Vielleicht bringt der XBase++ 1.9 mit seinen temporären Indexes die Lösung.
ja das könnte auch noch eine Lösung sein ...

gruss by OHR
Jimmy
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15688
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Beitrag von brandelh »

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.
Gruß
Hubert
MaBeLa
Cut&Paste-Entwickler
Cut&Paste-Entwickler
Beiträge: 21
Registriert: Mi, 08. Mär 2006 14:08
Wohnort: bei Berlin

Beitrag von MaBeLa »

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
Benutzeravatar
Lewi
1000 working lines a day
1000 working lines a day
Beiträge: 830
Registriert: Di, 07. Feb 2006 14:10
Wohnort: Hamburg
Danksagung erhalten: 2 Mal

Beitrag von Lewi »

Jimmy schrieb:
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.
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.

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
Benutzeravatar
andreas
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 1902
Registriert: Mi, 28. Sep 2005 10:53
Wohnort: Osnabrück
Hat sich bedankt: 4 Mal
Kontaktdaten:

Beitrag von andreas »

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.
Gruß,

Andreas
VIP der XUG Osnabrück
Benutzeravatar
Lewi
1000 working lines a day
1000 working lines a day
Beiträge: 830
Registriert: Di, 07. Feb 2006 14:10
Wohnort: Hamburg
Danksagung erhalten: 2 Mal

Beitrag von Lewi »

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.
Benutzeravatar
Armin
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 389
Registriert: Mo, 26. Sep 2005 12:09
Wohnort: 75331 Engelsbrand
Danksagung erhalten: 3 Mal
Kontaktdaten:

Beitrag von Armin »

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")
Benutzeravatar
andreas
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 1902
Registriert: Mi, 28. Sep 2005 10:53
Wohnort: Osnabrück
Hat sich bedankt: 4 Mal
Kontaktdaten:

Beitrag von andreas »

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.
Gruß,

Andreas
VIP der XUG Osnabrück
Benutzeravatar
andreas
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 1902
Registriert: Mi, 28. Sep 2005 10:53
Wohnort: Osnabrück
Hat sich bedankt: 4 Mal
Kontaktdaten:

Beitrag von andreas »

Hallo Armin,

dein Vorschlag

Code: Alles auswählen

!(alltrim(be1_name)=="FERTIGUNG")
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.
Gruß,

Andreas
VIP der XUG Osnabrück
Benutzeravatar
Martin Altmann
Foren-Administrator
Foren-Administrator
Beiträge: 16502
Registriert: Fr, 23. Sep 2005 4:58
Wohnort: Berlin
Hat sich bedankt: 111 Mal
Danksagung erhalten: 48 Mal
Kontaktdaten:

Beitrag von Martin Altmann »

Hallo Andreas,
andreas hat geschrieben:Die Erstellung zus. Indextags hat mein Problem gelösst und ich denke, dass damit diser Posting abgeschlossen werden kann.
Dein Wunsch ist mir Befehl...

Viele Grüße,
Martin
:grommit:
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.
Gesperrt