Mehrplatzversion Datenzugriff manchmal langsam

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

Moderator: Moderatoren

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

Re: Mehrplatzversion Datenzugriff manchmal langsam

Beitrag von brandelh »

Nicht ganz, für Win7 Clients muss man zwingend den Patch installieren, da bei diesem Betriebssystem der Client Cache auch ein Problem ist.
Gruß
Hubert
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: Mehrplatzversion Datenzugriff manchmal langsam

Beitrag von AUGE_OHR »

Koverhage hat geschrieben:
die Syntax mit Full UNC-Path
ist die Anwendung dann schneller ?
wenn du die 16min meinst ... sicherlich ;)

wie immer ist die Antwort abhängig von dem was du machst.

die M$ OS() wurden ja auf immer mehr Bandbreite / Mengen getrimmt und wenn man die Daten dann auch noch komprimiert ...
Die Antwort ( in Zahlen ) findest man im Netzwerk-Monitor des Server wo man auch grafisch sehen kann wie das OS() versucht gleichzeitig grosse Datenmengen an die Clients zu senden.
bei Xbase (alle Versionen) DBF / Index Dateien haben wir aber Datensatz bezogene Aktionen, wie beim DbSkipper(), was suboptimal ist.
gruss by OHR
Jimmy
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: Mehrplatzversion Datenzugriff manchmal langsam

Beitrag von AUGE_OHR »

hi,
Bernd Reinhardt hat geschrieben:Wenn ich dich recht verstehe dann muss ich meinen Kunden sagen:
Es gibt KEIN "allgemeines" Rezept. Es handelt sich lediglich um Empfehlungen die sich bewährt haben.
Bernd Reinhardt hat geschrieben:1. Wir benötigen einen Server2008 bei dem SMB2 abgeschaltet ist. (Patch von Alaska)
für DBF / Index Dateien benötigst du einen File Server. Welches OS() / Server Software / NAS hängt von den Bedürfnissen ab.
Bernd Reinhardt hat geschrieben:2. WIN XP oder WIN 7 bei denen auch SMB2 abgeschaltet ist.
XP ist "out" ! gemischte OS() / Software Versionen ist NICHT zu empfehlen !

ein komplettes "abschalten" von SMBx ist ebenfalls NICHT zu empfehlen denn SMB enthält ja nicht nur Dateien sondern alles was der Server an "share" kontrollieren soll(te)
Bernd Reinhardt hat geschrieben:3. Die beiden Schlüssel über die Delaytime (KB /150384) auf allen Servern und Arbeitsstationen
siehe dir die Registry Schlüssel mal genau an !
denn da steht
\Services\Lanmanworkstation\Parameters
und das ist für ... richtig -> Workstation
wenn da nun steht
\Services\Lanmanserver\Parameters
dann ist es eben für den Server gedacht.
ist doch nun wirklich nicht schwer zu merken, oder ;)

beachte : Client hat auch Server Funktion default als Dienst eingeschaltet
Bernd Reinhardt hat geschrieben:4. Muss ich zwingend Active Directory einrichten, oder reicht es wenn auf dem Server ein Verzeichnis
frei gegeben wurde auf welches dann alle Programm zugreifen. Über gemappte Laufwerksbuchstaben oder \\servername\freigabename
hierzu kann ich nur auf verschiedene Diskussionen hier im Forum hinweisen zum Thema SMB2.

meine Empfehlung ist den Zugriff grundsätzlich auf vollen UNC-Path zu erweitern und Laufwerksbuchstaben, inklusive Lokalen, nicht mehr zu verwenden.

Laufwerksbuchstaben sind aus DOS Zeiten auf 26 begrenzt aber im Internet Zeitalter ebenfalls "out".
dafür hast du dann Ordner die zum UNC-Path führen die freigeben sein müssen.
*** snip ***
versuch mal einen lokalen Zugriff per UNC-Path im Netzwerk !
*** eof ***
Bernd Reinhardt hat geschrieben:4. Im Programm dann DBE_LOCKMODE auf LOCKING_EXTENDED
wenn Cl*pper im Spiel sein sollte -> NEIN.
aber erst mal solltest du deine Problem in Griff kriegen bevor du noch eine mögliche Baustelle eröffnest.
Bernd Reinhardt hat geschrieben:Wenn ich das alles so einhalte, dann funktionieren meine Programme problemlos?
dein Programm ist immer noch von der Hardware abhängig.
ein richtiger Switch und ordentliche Kabel ( nix 30m billig Ware ) sollte man auch nicht vergessen.
Bernd Reinhardt hat geschrieben:Kann ich dann meinen Kunden eine Garantie geben das es hier zu keinen Problemen mehr kommt.
(Wenn es dann nicht besser wird muss ich den ganzen Aufwand bezahlen. Wenn alles dann super
gut läuft kann ich die Kunden schon dazu bewegen hier zu investieren.)
wenn du die Geräte lieferst, der Kunden keine externe Software installierst, du einen 24Std Support lieferst ... und der Kunde das bezahlt !

Ein Netzwerk ist nicht ein Büro Stück wie ein Tisch. Inzwischen muss man EDV Teile auch nicht mehr auf 10 Jahre abschreiben.
Das die alten Teile überhaupt noch laufen ist fast ein Wunder ... aber da ist der Verschleiss ja auch nicht künstlich.

Tip : bei einer SSD sollte man evtl. zu einer älteren Generation mit 32nm greifen.
die 20nm Generation ist deutlich kleiner und bietet weniger Platz für "Löcher" die den Verschleiss ausmachen.
Bernd Reinhardt hat geschrieben:Aber warum hat dann Hubert mit so einer Konstellation Probleme.
Oder habe ich hier was falsch verstanden?
NAS welche SMB2/3 beherrschen gibt es IMHO nur in der echten Server Klassen > 1000,-€
es gibt allerdings auch schon in der 500,-€ Klasse NAS mit Dual oder Quad CPU und 2 Netzwerkkarten (Chips) und SMB1.
diese sind inzwischen als File Server so leistungsfähig das ein gleichzeitiger Zugriff von mehreren Workstationen nicht so schnell zum Einbruch führt.

ob man nun ein fertigen Server oder NAS kauft oder sich selbst was zusammenstellt hängt vom Geld und den Erfordernissen ab.
unabhängig der Hardware / OS() Lösung arbeitet der "share" Zugriff IMMER per SMBx.

SMBx Probleme treten häufiger auf bei unterschiedlicher Hard- / Soft-Ware auf also wenn möglich gleiche Ausstattung ( was auch für die Entwickler Seite gilt zum simulieren )


Fazit :
Ein System was 10 Jahre in Betrieb war wird sicherlich nicht noch weitere 10 Jahre laufen ohne mehr Schwierigkeiten zu machen.

Tip : bei der nächsten Renovierung sollte man nicht nur die Netzwerk sondern auch die Stromkabel Kabel austauschen.
Wenn der Elektriker sieht was alles inzwischen an solchen alten Stromkabeln als Last hängt ... :angry4:
das schlimmste dabei sind nun "verlängerte" Steckdosen wo dann vielleicht noch eine dran hängt ... :banghead:
gruss by OHR
Jimmy
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15689
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: Mehrplatzversion Datenzugriff manchmal langsam

Beitrag von brandelh »

Die Hardware darf man keinesfalls unberücksichtigt lassen. Ein Markenswitch (3COM) liefert hier deutlich schnellere Übertragungen wie der TB zu Hause.
Allerdings sind die Datenmengen bei DBF Zugriffen nie das Problem. Dort wird eh immer mit 512 Byte Blocks (von der Festplatte) gearbeitet.
Die saubere Verkabelung (keine Knicke, Trittstellen, Quetschungen ... Staub, Feuchtigkeit) ist extrem wichtig wenn man GigaBit möchte, für 3 Stationen reicht aber auch 100 MBit.

Gerade verstaubte Geräte und feuchte Luft führen zu seltsamen Fehlern.
Gruß
Hubert
Bernd Reinhardt
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 159
Registriert: So, 16. Apr 2006 11:12
Wohnort: Öhringen

Re: Mehrplatzversion Datenzugriff manchmal langsam

Beitrag von Bernd Reinhardt »

Hallo.

Ich bin nun einen Schritt weiter aber an einer Lösung vom Problem noch weiter entfernt.
Ich habe mein Testprogramm so abgeändert das ich komplett ohne Indexdateien
arbeite. Dann läuft die Software stabil, ich kann von mehreren Arbeitsplätzen gleichzeitig auf die DBF-Datei zugreifen,
RLOCK und update von Records durchführen und das Programm stürzt nicht ab.
Sobald nun Indexdateien mit ins Spiel kommen stürzen die Programme ab, z. B. bei Rlock.

Dann wollte ich mal mit lokalen Indexen arbeiten. Die dbf-Datei liegt im Netz und ich baue mir einen Index lokal auf.
(Welche Probleme rein bei append und update von Schlüsselfeldern vorhanden sind ist mir schon klar).
Es wäre von der Applikation her möglich bei jedem öffnen der Datei die lokale Indexdatei aufzubauen.

Wenn ein Programm die dbf-Datei öffnet und sich eine lokale Indexdatei aufbaut dauert der Aufbau der Indexdatei
kleiner 1 sekunde.
Hat ein zweites Programm die dbf-Datei ebenfalls geöffnet, so dauert der lokale Indexaufbau ca. 20 Sekunden.
In beiden Fällen ist aber hinterher eine richtige Indexdatei lokal vorhanden.
Wie so das so lange dauert weiß ich auch nicht.

Ich vermute das nun mein eigentliches Problem, Mehrplatzversion Datenzugriff teilweise sehr langsam,
hier zu suchen ist. Eventuell baut xBase++ den Index hier auch irgendwie neu auf.

Also Microsoft alleine kann hier ja nicht schuld sein, denn die dbf-Datei kann von mehreren Arbeitsplätzen bearbeitet werden.
Ohne Indexdatei läuft das, nur mit Indexdatei nicht.
Wenn ich mit Indexdateien arbeite, und nur Felder ändere die NICHT im Index vorhanden sind, so läuft das Programm trotzdem
nicht stabil. Hier müsste ja die Indexdatei gar nicht angefasst werden.

Die einzige Möglichkeit hier zu arbeiten sehe ich darin komplett ohne Indexdatei zu arbeiten und die Daten komplett
in ein Array zu lesen. Das Array zu indizieren und damit dann die sortieren Listen anzeigen.

Oder hat jemand noch eine Idee wie man mit Indexdateien richtig umgehen kann. Hat den außer mir hier niemand
Probleme? Nach allem was ich jetzt versucht und gemacht habe (Server 2008, WIN 7, XP, NAS) war das Ergebnis immer ähnlich.
Es gab keine Hardwarekonstellation die richtig zuverlässig funktioniert hat.

Mich wundert nur das ich offensichtlich der einzige bin der solch massive Probleme hat.
Ich kann mein Testprogramm auch mal zur Verfügung stellen, vielleicht sieht hier jemand das Problem.

Ich öffne 4 dbf-Dateien mit Indexen ändere einen Record und schließe die Dateien. Warte 800 msec und mache das ganze
von vorne.
Das Programm läuft dann auf drei Arbeitsplätzen gleichzeitig.
Hab mir schon überlegt eine Preis auszusetzen wenn es jemand schafft mir eine bei mir nachvollziehbare Lösung
aufzuzeigen mit dem die drei Programme mindestens eine Stunde fehlerfrei ohne Verzögerungen stabil durchlaufen.

Gruß
Bernd
Bernd Reinhardt
fa.reinhardt@gmx.de
georg
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2823
Registriert: Fr, 08. Feb 2008 21:29
Hat sich bedankt: 95 Mal
Danksagung erhalten: 13 Mal

Re: Mehrplatzversion Datenzugriff manchmal langsam

Beitrag von georg »

Hallo,


ganz einfach, migriere weg von DBF/NTX zu SQL. Entweder mit ADS, oder MySQL-Wrapper von Hector Peroza, oder mit SQLExpress. (In allen drei Fällen werden Daten und Index-Dateien von dem entsprechenden Server verwaltet.)

Deine Überlegung mit den lokalen Index-Dateien ist nett, bis Du an Station 1 arbeitest und Station 2 einen Datensatz anlegt. Der wird in Deinem Index nicht auftauchen. Auch Änderungen, welche von den anderen Stationen durchgeführt werden, spiegeln sich in dem lokalen Index auf Deinem Rechner nicht wider.

Ist zwar eine blöde Idee, aber: mal ein kleines Netzwerk mit neuen Rechnern aufgesetzt und versucht, wie es damit läuft?
Liebe Grüsse aus der Eifel,

Georg S. Lorrig
Redakteur der Wiki des Deutschprachigen Xbase-Entwickler e.V.
Bernd Reinhardt
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 159
Registriert: So, 16. Apr 2006 11:12
Wohnort: Öhringen

Re: Mehrplatzversion Datenzugriff manchmal langsam

Beitrag von Bernd Reinhardt »

Hallo Georg.

Hier hast du meine Nachricht nicht richtig gelesen. Wenn ich die Datenbank öffne, und das passiert nach jeder Aktion,
baue ich den Index neu lokal auf. Damit finde ich auch Datensätze die auf anderen Arbeitsplätzen geändert oder neu
angelegt werden. Wie gesagt das Problem kenne ich und für meine Applikation (und nur für meine) wäre datentechnisch
ein lokaler Index selbst bei Mehrplatzversion möglich. Das ist aber überhaupt nicht das Thema.

Wie so wird ein Index in 1 sec aufgebaut wenn die Datei auf keinen anderen Arbeitsplatz offen ist, und in 20 sec
aufgebaut wenn die Datei noch von einem anderen Programm offen ist.

Wie so stürzt ein Programm nach ca. 30 min ab wenn drei Programme gleichzeitig auf DBF-NTX Dateien zugreifen.
Wie so stürzt das Programm nicht ab wenn nur auf dbf und nicht auf Indexdatei gleichzeitig zugegriffen wird.

Ich habe sehr viele modifizierte Programmversionen beim Kunden. Jedes mal wenn bei einem Kunden ein zweiter / dritter
Arbeitsplatz dazukommt muss ich auf SQL, ADS oder sonst was umstellen. Da bin ich Monate damit beschäftigt und kriege
das nicht bezahlt.
Das sich Alaska Software dem Problem nicht annimmt finde ich schon befremdlich. SQL und ADS bedeuten ja auch erst mal
zusätzliche Installationen und komplette umbau vom Programm bei allen DAtenbankzugriffen, Listen usw.
Die Unterstützung von Alaska ist hier nur verbal, seit Jahren ist die Software auf dem gleichen alten Stand. Das letzte Update
schon Jahre her. Mit einer fertigen stabilen Version 2.0 kann man ja noch lange nicht rechnen.

Damit verliert xBase++ den Vorteil der super einfachen Installation, der einfachen Datensicherung, lauffähig vom Stick ohne Installation auf dem PC.
Keine Änderungen in der Registry notwendig (na ja bis auf SMB2).

Damit konnte ich gegenüber ACCESS, Visual Basic usw. beim Verkaufsgespräch punkten. Einfach alles in ein Verzeichnis kopieren und das Programm läuft.
Keine dll-Dateien ins system32
Wenn ich jetzt zum Kunde komme und sage ich brauche einen SQL-Server, brauche Änderungen in der Registry und installiere nicht nur mehr
in mein Verzeichnis dann habe ich ein größeres Problem bei der Argumentation.

Ich möchte doch einfach nur von drei Arbeitsplätzen mit den Möglichkeiten die mir xBase++ 1.9SL1 bietet auf Daten zugreifen.
Wenn ich ein Auto kaufe möchte ich doch auch damit fahren, und es nicht auf einen Transporter stellen das ich es bewegen kann.

Gruß
Bernd
Bernd Reinhardt
fa.reinhardt@gmx.de
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:

Re: Mehrplatzversion Datenzugriff manchmal langsam

Beitrag von Martin Altmann »

Moin Bernd,
das hört sich alles nach den nötigen Tuningeinstellungen für die Order-Komponente an!
Schau Dir doch mal z.B. den Parameter DBE_LOCKMODE der NTXDBE an - wenn Du den auf LOCKING_EXTENDED setzt, dann wird der Index nur noch bei Schreibzugriffen gesperrt.

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.
georg
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2823
Registriert: Fr, 08. Feb 2008 21:29
Hat sich bedankt: 95 Mal
Danksagung erhalten: 13 Mal

Re: Mehrplatzversion Datenzugriff manchmal langsam

Beitrag von georg »

Hallo, Bernd -


ja, ich habe nicht das komplette Thema gelesen.

Aber die allgemeine Erfahrung spricht gegen Dein Problem, d.h. ich habe das bis heute NICHT erlebt.

Also stellt sich doch die Frage nach der Ursache. Die liegt entweder

bei den PCs
beim Netzwerk
Deinem Programm

Zumindest sind das mal die wahrscheinlichsten Punkte. Ich würde ein kleines Netz mit drei PCs simulieren und - ausser den erforderlichen Patches - nichts installieren, Deine Software drauf, ausprobieren. Unter diesem Test würde ich auch den Netzwerk-Aspekt sehen.

Kommen wir zu Deinem Programm.
Wenn ich die Datenbank öffne, und das passiert nach jeder Aktion, baue ich den Index neu lokal auf.
Kannst Du das mal genauer beschreiben? Du legst einen neuen Kunden an, schliesst die Kunden.dbf, öffnest sie neu und erstellst den Index neu? Nach der Änderung eines Artikels wird die Artikel.dbf geschlossen, neu geöffnet und der Index neu erstellt?
Liebe Grüsse aus der Eifel,

Georg S. Lorrig
Redakteur der Wiki des Deutschprachigen Xbase-Entwickler e.V.
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15689
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: Mehrplatzversion Datenzugriff manchmal langsam

Beitrag von brandelh »

Ich kann nur sagen, dass ich die geschilderten Probleme SO nie hatte !
Vor den Optimierungen von XP / VISTA / WIN 7 hatte ich überhaupt keine Probleme mit mehreren Arbeitsplätzen auf der gleichen Datei.
Ein peer Netzwerk von XP und Win 7 ist sich selbst nicht ganz grün (XP Freigaben werden nicht automatisch erkannt), aber selbst damit kann ich hier einwandfrei geshared arbeiten,
denn ich habe alle Registry-Keys gesetzt die nötig sind.Das kann man übrigens - mit genug Rechten - vom Programm erledigen lassen.

Wenn der "Server" aber z.B. ein DOS Programm aufruft oder sonstwie die Platten beschäftigt, dann wird das für die anderen Rechner zäh !
Daher der Ratschlag die Daten immer auf NAS / eigenen Rechner auslagern. Bei 3 Anwendern muss der kein Serverbetriebssystem haben.
Wie so wird ein Index in 1 sec aufgebaut wenn die Datei auf keinen anderen Arbeitsplatz offen ist, und in 20 sec
aufgebaut wenn die Datei noch von einem anderen Programm offen ist.
was du da schreibst, legt nahe, dass die DBF nicht exclusiv geöffnet ist wenn du den INDEX aufbaust.
Das sollte man aber tun, unter Clipper ging es - soweit ich mich erinnere gar nicht anders.
In der Doku steht, dass ...
Der Befehl schließt alle offenen Index-Dateien in der aktuellen Workarea und legt die Index-Datei <cIndexFile> neu an. Die Index-Datei wird anschließend exklusiv geöffnet und der Index wird in ihr aufgebaut. Falls die Datei nicht exklusiv geöffnet werden kann (z.B. in einer Netzwerkumgebung), entsteht ein Laufzeitfehler. Andernfalls wird der Index nach Abschluß der Indexierung zum kontrollierenden Index in der aktuellen Workarea und der Satzzeiger wird auf den ersten logischen Datensatz positioniert.
Ein Programm muss grundsätzlich immer alle Indexdateien zusammen mit der DBF offen haben, sonst sind Probleme zu erwarten.
Wie kann man aber eine DBF mit Indexen offen haben und ein anderer baut sie gerade neu auf ?
- Sollte sich die Aussage auf "Indexe lokal, Daten zentral" beziehen, dann wäre das zwar was anderes, aber ...

Wenn du so wenige Datensätze hast, dass du immer neu Indizieren kannst, kannst du auch grundsätzlich auf einen Index verzichten und Daten mit dbLocate() suchen bzw. fürs browsen in ein Array einlesen.
Ich möchte doch einfach nur von drei Arbeitsplätzen mit den Möglichkeiten die mir xBase++ 1.9SL1 bietet auf Daten zugreifen.
Wenn ich ein Auto kaufe möchte ich doch auch damit fahren, und es nicht auf einen Transporter stellen das ich es bewegen kann.
normalerweise geht das auch, sonst würde hier keiner mehr mit Xbase++ arbeiten !
Gruß
Hubert
Bernd Reinhardt
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 159
Registriert: So, 16. Apr 2006 11:12
Wohnort: Öhringen

Re: Mehrplatzversion Datenzugriff manchmal langsam

Beitrag von Bernd Reinhardt »

Hallo Hubert.

Ich zweifele ja auch schon an mir, vielleicht habe ich ein grundsätzliches Problem und sehe vor lauter
Bäumen den Wald nicht mehr.
Es fing ja damit an das plötzlich mehrere Kunden meldeten, das die Programme, wenn was gearbeitet wird sich gegenseitig blockieren und dann diese lange Wartezeit von bis zu 2 min (gefühlt vom Kunden) auftreten.
Wenn wenig gleichzeitig geändert wird tritt das Verhalten kaum auf.

Das mit den lokalen Indexdateien ist schon so, das die DBF- im Netz liegt und shared geöffnet ist.
use (\\RechnerIP\Datei) shared
die Indexdatei aber lokal aufgebaut wird. War ja nur mal ein Versuch. Wenn die Datei SHARED nicht
Exclusiv aber nur von einem Arbeitsplatz geöffnet wurde, dann baut sich der lokale Index in kleiner 1 sekunde auf.
Wenn die DBF-Datei von mehreren Arbeitsplätzen SHARED geöffnet ist dann baut sich der Index langsam (30sec) auf.
In beiden Fällen ist die DBF-Datei nicht exclusive geöffnet. (Hier stimmt die Beschreibung nicht).

Mein Testprogramm läuft hier am besten, wenn keine Indexdatei geöffnet ist und ich die Datenbankdatei nicht schließe.
Sobald Indexdateien mit ins Spiel kommen stürzt das Programm nach kurzer Zeit ab.
do while .t.
use\\rechnername\ Datei
set index to \\rechnername\index
go top
rlock
ändere Datensatz
unlock
mywartezeit
use
mywarteZeit // geht mit Appevent und xbe_None os das Events verarbeitet werden.
enddo

Ich kann mir das alles auch nicht erklären, aber Fakt ist das das Programm bei mir zu Hause (XP WIN 7) und in der Firma
Server, XP, WIN 7 ebenfalls nach kurzer Zeit abstürzt.

Beim Kunden verriegeln sich die Programme und dafür suche ich eine Lösung. Deshalb der Versuch was machen die Indexdateien.
Sicherlich habe ich ein Problem weil ich die Datenbanken häufig schließe und dann gleich wieder öffne. Ich werde mal versuchen die
Datenbanken immer offen zu halten. Sobald ein neuer Datensatz angehängt wird schließe ich die Datei und öffne Sie wieder neu.
Um sicher zu sein das der Datensatz auch in der Datenbank und nicht im Speicher ist (kommt glaube ich noch aus Clipper Zeiten).

Gruß
Bernd
Bernd Reinhardt
fa.reinhardt@gmx.de
Bernd Reinhardt
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 159
Registriert: So, 16. Apr 2006 11:12
Wohnort: Öhringen

Re: Mehrplatzversion Datenzugriff manchmal langsam

Beitrag von Bernd Reinhardt »

Hallo
Nur noch zur Ergänzung. Ich habe beim Kunden denn ins Programm Zeitmessungen eingebaut und
festgestellt, das in aller Regel der Befehl set index in kleiner 1 sec bearbeitet wurde.
Wenn dann die Verzögerung auftrat hat der Befehl set index 50 sec gedauert.
DBF- und Indexdatei liegen hier im Netzwerk.

Deshalb dann die Versuche was wie passiert um dem Verhalten näher zu kommen.
Und der Effekt wenn die Datei von zwei Arbeitsplätzen geöffnet ist und ich den Index lokal aufbaue
kommt dem Verhalten (was den Zeitverzug betrifft) beim Kunden nahe.

Gruß
Bernd
Bernd Reinhardt
fa.reinhardt@gmx.de
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:

Re: Mehrplatzversion Datenzugriff manchmal langsam

Beitrag von Martin Altmann »

Du hast schon gelesen, was ich geschrieben hatte - oder?

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.
Benutzeravatar
Herbert
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 1991
Registriert: Do, 14. Aug 2008 0:22
Wohnort: Gmunden am Traunsee, Österreich
Danksagung erhalten: 3 Mal
Kontaktdaten:

Re: Mehrplatzversion Datenzugriff manchmal langsam

Beitrag von Herbert »

Bernd, du bist nicht allein... schau hier http://www.xbaseforum.de/viewtopic.php?f=20&t=6035

Auch ich habe sehr viele Versuche unternommen, Tipps von hier geholt und mit in neue Tests aufgenommen - ohne Erfolg. Ich weiss echt nicht, woran es liegt. Ich bin ziemlich sicher, dass nicht die lokale Konfiguration schuld ist. Bei mir sind bei den 4 Absturz-Kunden (von 80 mit demselben Programm) durchwegs Citrix-Komponenten auf Server-Seite vorhanden. Bei dir?

Dies war einer der gewichtigen Gründe für mich, von Xbase wegzugehen. Letzte Woche habe ich beim ersten Kunden mit meinem Absturzphänomen umgestellt. Jetzt läuft alles ohne Abstürze - mit Windev.
Grüsse Herbert
Immer in Bewegung...
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15689
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: Mehrplatzversion Datenzugriff manchmal langsam

Beitrag von brandelh »

Früher hatte ich auch immer alle Dateien offen, das mache ich heute nicht mehr, weil man dann auch die Indexe nicht einfach löschen kann und jeder Netzwerkfehler sofort zu defekten Indexdateien führt.
Heute öffne ich die Datei zum Lesen/Suchen der Daten und zum Speichern. Das geht im LAN so schnell, dass man es nicht messen kann < 1 sec.

Ganz wichtig sind einige Grundregeln (neben der technisch einwandfreien Netzwerkumgebung).

1. Normale Indexe werden nur auf EXCLUSIV geöffneten DBF Dateien erzeugt !
- mögliche Ausnahmen müssen lokal liegen und werden z.B. temporär für eine Aufgabe erzeugt (sowas nutze ich nicht).
2. EINE Funktion im Programm (bzw. identisch in anderen) kümmert sich um die Indexerstellung und Dateiöffnung, so ist sichergestellt, dass die Reihenfolge der Zugriffe und Sperren identisch bleiben.
3. NETERR() nach USE ist ein Hinweis daruf, dass eine andere Station dabei ist die Indexe aufzubauen.
4. Bei jedem Öffnen vorher prüfen ob die Indexdateien auch da sind.
5. USE öffnet KEINEN Index (also nicht USE ... INDEX ... verwenden, sondern erst USE, dann NETERR() prüfen, dann set index to )
6. Statt mehrere NTX, eine CDX verwenden.
7. Wenn eine Indexdatei fehlt, testen ob die DBF exclusive geöffnet werden kann, wenn ja, die dazugehörenden Indexe löschen und neu erzeugen, wenn nein Meldung "Index wird gerade erzeugt, bitte warten")
8. Man kann nur einzelne DBF Dateien öffnen, aber NIE nur einige der vorhandenen Indexdateien der DBF ! (Immer alle NTX zu einer DBF gleichzeitig in gleicher Reihenfolge öffnen !)

Dass du keinen SQL Server installieren willst, kann ich verstehen, aber im Vortrag über die ADS ist sehr deutlich geworden, dass
1. Die Einbindung der ADS sehr schnell geht
2. Das Programm kaum geändert werden muss
3. Solange man keinen "Serverbetrieb" benötigt, mit der lokal arbeitenden Version gearbeitet werden kann.
4. Falls so Probleme mit dem Netz auftreten, man schnell auf Serverbetrieb umschalten kann und nach der Installation des Server-Programmes (läuft als Dienst), keine Administration nötig ist.
5. Der lokale Betrieb kostet nichts, außer der ADSDBE.

Kannst du die Probleme bei dir im kleinen Netz nachvollziehen ?
Wenn ja, kannst du sie dort auch lösen. Schlimmer ist es wenn es normal funktioniert und nur bei einigen Kunden nicht.

Martin hatte ja schon auf die DBE Einstellungen hingewiesen ...
- EXTENDED locking, das Indexe nur noch fürs Schreiben sperrt, könnte dir helfen.
- Retry und Wait Parameter anpassen (kürzer einstellen) und dafür lieber eine msgbox mit Fehlermeldung ("wir gerade gesperrt, später nochmal versuchen") kann DeadLocks verhinden.

Du solltest die öffnen / schließen / speichern Teile isolieren und versuchen den Fehler einzugrenzen, eventuell auch die Codestellen hier rein stellen.
Gruß
Hubert
Benutzeravatar
Koverhage
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2470
Registriert: Fr, 23. Dez 2005 8:00
Wohnort: Aalen
Hat sich bedankt: 102 Mal
Danksagung erhalten: 3 Mal
Kontaktdaten:

Re: Mehrplatzversion Datenzugriff manchmal langsam

Beitrag von Koverhage »

ich würde immer noch auf den Virenscanner tippen.
Gruß
Klaus
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15689
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: Mehrplatzversion Datenzugriff manchmal langsam

Beitrag von brandelh »

Koverhage hat geschrieben:ich würde immer noch auf den Virenscanner tippen.
genau, den hatte ich vergessen ;-)

DBF, NTX, CDX, DBT, FPT - Dateien von der Überwachung ausnehmen.
Gruß
Hubert
Benutzeravatar
adrian
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 265
Registriert: Mo, 08. Mai 2006 8:58
Wohnort: Aadorf TG
Danksagung erhalten: 1 Mal
Kontaktdaten:

Re: Mehrplatzversion Datenzugriff manchmal langsam

Beitrag von adrian »

Nun, Bernd, Du bist definitiv nicht alleine, auch wenn Dir der Trost nichts bringt.

Wir haben die gleichen Probleme seit eh und je (oder besser seit der Umstellung auf xBase vor x Jahren). Wir haben eine Branchenlösung und 190 Mal in Betrieb, von 2-3 Arbeitsplätzen bis ca. 30 Arbeitsplätze. Die Hardware selbst betreuen wir in ganz wenigen Fällen. Daher, haben wir auf dieses Thema auch sehr wenig Einfluss und können nur Empfehlungen aussprechen. Doch wenn danach alles langsam ist, dann sind wir in den Augen des Kunden trotzdem Schuld.

Ich werde sicherlich als nächstes den Test mit ADS machen, und falls dies dann läuft, denn Kunden diesen als Alternative anbieten.

Bei vielen Kunden habe ich auf TerminalServer gesetzt, da ist die ganze Geschichte viel besser. Wir setzen die Software von http://www.thinstuff.com ein, da kannst Du aus jedem Windows PC einen TerminalServer für wenig Geld erstellen. Bei Windows XP / 7 genügt die Light-Version.

So haben wir auch Mac-Kunden angeschlossen. Da haben wir einen Windows 7 PC mit ThinStuff ins Netz gestellt und diesen per Remote auf den Mac's verbunden, da läuft alles wunderbar.

es Grüsst Dich

Adrian
es Grüessli

Adrian
Benutzeravatar
Manfred
Foren-Administrator
Foren-Administrator
Beiträge: 21165
Registriert: Di, 29. Nov 2005 16:58
Wohnort: Kreis Wesel
Hat sich bedankt: 206 Mal
Danksagung erhalten: 67 Mal

Re: Mehrplatzversion Datenzugriff manchmal langsam

Beitrag von Manfred »

So wie ich das sehe, scheint ja der Vortrag von Joachim gefruchtet zu haben. Ich werde mich in den nächsten Tagen auch mal mit dem ADS auseinandersetzen.
Gruß Manfred
Mitglied der XUG Osnabrück
Schatzmeister des Deutschsprachige Xbase-Entwickler e.V.
großer Fan des Xbaseentwicklerwiki https://wiki.xbaseentwickler.de/index.p ... Hauptseite
Doof kann man sein, man muß sich nur zu helfen wissen!!
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15689
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: Mehrplatzversion Datenzugriff manchmal langsam

Beitrag von brandelh »

Ein Terminal Server mit LOKALEN Daten ist sicher die beste Lösung :!:
Gruß
Hubert
Bernd Reinhardt
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 159
Registriert: So, 16. Apr 2006 11:12
Wohnort: Öhringen

Re: Mehrplatzversion Datenzugriff manchmal langsam

Beitrag von Bernd Reinhardt »

Hallo
Eine kurze Zusammefassung:
Bei einem Kunden mit Problemen ist definitiv KEIN Virenscanner installiert. Netzwerk hat keinen Internetzugriff.
Hab aber mal einen SCAN mit aktuellem Scanner von CD gemacht, keine Viren.
Netzwerk ist ständig aktiv, kein Power Save der Netzwerkkarte, Router oder ähnliches.
Habe die Daten auch mal auf eine NAS gelegt. Gleiches Problem.
Es werden Lieferscheine gedruckt, d. h. Kunde suchen, auswählen, Material suchen / auswählen
Lieferschein drucken und speichern. Dann alle Dateien schließen und neu öffnen dann nächster
Lieferschein. Es werden nur Lieferschein angehängt, keine Daten gelöscht bzw. verändert.
Somit keine Doubletten, keine Datensätze DELETED. Somit ist kein ständiger REINDEX notwendig.
(Reindex als Menupunkt vorhanden. DEL *.ntx dann Index neu aufbauen wenn alle anderen Arbeitsplätze aus sind)


Berücksichtigt wurden:
http://support.microsoft.com/kb/150384/en-us
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters bzw. LanmanWorkstation
Value Name: SharingViolationDelay Data Type: REG_DWORD Data: 0 (Default: 200)
Value Name: SharingViolationRetries Data Type: REG_DWORD Data: 0 (Default: 5)

http://support.microsoft.com/kb/296264/de
opportunistic locking
Gibt es hier noch spezielle Einstellungen die notwnendig sind?

Außer SMB2 noch irgendwelche Parameter die man einstellen kann im REGEDIT?

// Alles mögliche hier versucht ohne verbesserung
DbeInfo( COMPONENT_DATA, DBFDBE_LOCKRETRY, 10000)
DbeInfo( COMPONENT_DATA, DBFDBE_LOCKDELAY, 50)
DbeInfo( COMPONENT_ORDER, NTXDBE_LOCKRETRY, 10000)
DbeInfo( COMPONENT_ORDER, NTXDBE_LOCKDELAY, 50)
DbeInfo (COMPONENT_ORDER, DBE_LOCKMODE, LOCKING_EXTENDED)

// Hier noch falsche Einstellungen ??
SET RUSHMORE OFF
SET SMARTFILTER OFF
SET OPTIMIZE OFF
SET EXCLUSIVE OFF // Netzwerk
SET DELETED ON
SET EXACT ON
SET UNIQUE OFF
SET CONFIRM ON
SET CURSOR OFF
SET DELIMITERS OFF
SET DATE GERMAN
SET CENTURY OFF
SET SCOREBOARD OFF

pfad_pd enthält keine verknüpften Laufwerke nur \\rechnername\freigabename Full UNC-Path
Kann ich hier noch was verbessern?
USE (pfad_dp + cDatabase) // Datenbank im Netzwerk öffnen
IF NETERR()
msgbox(cDatabase + " zur Zeit gesperrt.")
LOOP
else
SET INDEX TO (pfad_dp + "dknd1.ntx"), ;
(pfad_dp + "dknd2.ntx")


Wenn ich bei meinem Testprogramm auf drei Rechnern nur mit dbf-datein arbeite, keine einzige Indexdatei benutze, dann läuft das Programm schnell und stabil ohne Abstürze.
Das zeigt doch das xBase++ in Verbindung mit dem Betriebssystem sauber und richtig zuverlässig auf dbf-Dateien zugreifen kann.
Warum geht das nicht mehr wenn Indexdateien mit im Spiel sind.

Das zeigt doch das vom Betriebssystem her alles o.k. Hier sollte doch Alaska mal die Indexdateien mal besser unter die Lupe nehmen.

Gruß
Bernd
Bernd Reinhardt
fa.reinhardt@gmx.de
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:

Re: Mehrplatzversion Datenzugriff manchmal langsam

Beitrag von Martin Altmann »

Moin Bernd,
die DbeInfo()-Einstellung machst Du natürlich, bevor Du irgendeine Datei öffnest - oder?

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.
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15689
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: Mehrplatzversion Datenzugriff manchmal langsam

Beitrag von brandelh »

Bernd Reinhardt hat geschrieben: http://support.microsoft.com/kb/296264/de
opportunistic locking
Gibt es hier noch spezielle Einstellungen die notwnendig sind?
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MRXSmb\Parameters
- OplocksDisabled => REG_DWORD 0 oder 1 => Standard: 0 (nicht deaktiviert) => 1 (deaktivieren)

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters
- EnableOplocks => REG_DWORD 0 oder 1 => Standard: 1 (aktiviert) => 0 (deaktivieren)

diese Verweise und Parameter lassen mich vermuten, dass XP SP3 aktiv ist, stimmt das ?
Bernd Reinhardt hat geschrieben: Außer SMB2 noch irgendwelche Parameter die man einstellen kann im REGEDIT?
Ist SMB2 nicht erst ab Vista gekommen ?

Wenn du Win7 Clients hast, sind einige der obigen Zweige nicht mehr da, dafür müssen dort 3 andere Parameter gesetzt werden.

Sind alle Rechner im Netz mit dem gleichen OS bestückt ?
Hast du ein "ideales Hausnetz" zum testen ?

Wenn du meinst, dass es an den ALASKA NTX Treibern liegt, ist das einfachste zunächst auf CDX zu wechseln, diese sollten zwar alle TAGs in einer Datei mit gleichem Namen haben,
aber nur, damit man das Handling einfacher hat. Es gehen auch mehrere mit verschiedenen Namen.

Vorgehen:

".NTX" suchen und durch die Funktion OrdBagExt() ersetzen ...
alle alten Indexdateien löschen
CDX Indexe sind nicht Abhängig von Groß-/Kleinschreibung, wenn du das brauchst, hast du ein Problem !
Testen

Die andere Möglichkeit ist der Einsatz des ADS LOKAL Treibers, wobei ich denke dass du die ADSDBE dafür benötigtst.

Ansonsten kannst du auch obigen TerminalServer Ansatz wählen, dann arbeitet deine EXE nur noch LOKAL auf einem Rechner und die anderen sehen nur noch die Bildschirme.
Auf diese Art (RemoteDesktopVerbindung) rufe ich von unterwegs eine EXE auf meinem Rechner zu Hause auf und gebe Werte ein wenn es nötig ist. Geht mit Funknetz (3.5 MBit) wunderbar, sollte also im Netz fliegen. Oben gibt es ja einen LINK, damit es auf normalen Rechnern geht.

Aus Gründen der Datensicherheit und damit nicht einfach der lokale User den Rechner abschaltet, sollte es ein eigener Rechner im abgeschlossenen Raum sein.

PS: du könntest natürlich auch eine Subscription mit Support abschließen und Alaska mit dem Problem nerven ... 8)
Gruß
Hubert
Benutzeravatar
azzo
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 483
Registriert: So, 28. Mär 2010 19:21
Danksagung erhalten: 11 Mal

Re: Mehrplatzversion Datenzugriff manchmal langsam

Beitrag von azzo »

Hallo Adrian,

auch wir haben unsere Installationen auf RemoteDesktop umgestellt.

Hast du eigentlich eine definitive Antwort gefunden, ob thinstuff den Lizenzrichtlinien von Microsoft entspricht.

Mfg
Otto

http://otto-atzwanger-gmbh.com/#./page-12

http://otto-atzwanger-gmbh.com/#./ServerBook

http://otto-atzwanger-gmbh.com/#./page-22
Benutzeravatar
adrian
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 265
Registriert: Mo, 08. Mai 2006 8:58
Wohnort: Aadorf TG
Danksagung erhalten: 1 Mal
Kontaktdaten:

Re: Mehrplatzversion Datenzugriff manchmal langsam

Beitrag von adrian »

Interessiert mich dies #-o , ich glaube nicht.

Dies sollte Sache von Thinstuff sein, ansonsten soll MS sich mit denen Unterhalten, dafür sind meine Kunden definitiv zu klein, denn ich spreche ja nicht von Server-Lösungen sondern mit der Möglichkeit einem PC mehr Funktionalität zu geben, was es bei MS ja nicht gibt.

Adrian
es Grüessli

Adrian
Antworten