HILFE: Schreiben von Daten in die DBF über Netzwerk !

[xbaseklaus]

Statt eines commit()s ist ein DbSkip(0) effektiver, sofern ich mich an die Ausführungen von Steffen korrekt erinnere.

Viele Grüße,
Martin

DBskip hatte ich ja jetzt mit drin , aber alleine zeigte es keine Wirkung !

mfg Klaus

[Manfred]

Neuaufbau würde mich mal interessieren, ob dann das Problem weg ist. Vor allen Dingen warum es dann weg sein sollte.

[xbaseklaus]

Martin,

ich hatte damals alles ausprobiert. DbCommit() DbCommitAll() DbSkip(0) DbSkip(1) vor und zurück. Nichts half. Es gab immer wieder Probleme. Ein Exklusives Öffnen, Schreiben und wieder Schließen hat dem Problem sofort den garaus gemacht. Es muß (in dem Fall) ja nur ab und an passieren und schon ist das System inkonsistent. Ich denke mal, irgendwas, was die Daten weiterreicht hat das Wort SCHREIBEN nicht verstanden.

Das schlimme ist jedoch für mich im Moment , daß ich immer noch nicht weiß warum es in diesem Fall jetzt so funktioniert ( wird sich beim Kunden noch zeigen!) und in einem andern Fall wo das gleiche gemacht wird ohne DBcloseArea() es trotzdem geht. Das bereitet mir Magengeschwüre ! Weil das für mich im Moment ein an allen Ecken und Enden auf Verdacht geändertes Programm ist, das unter Clipper 5 bestens funktioniert hat und das 15 Jahre lang !

Mal abgesehen davon , daß ich jetzt nur durch Versuchen unter Xbase++ es stabil zu kriegen mehr Zeit vergeudet habe als ich unter Clipper gebraucht habe es neu zu schreiben bis es stabil gelaufen ist Das ist einfach frustrierend ! Bezieht sich jetzt aber nur auf Netzwerkanwendungen !

mfg Klaus

[Manfred]

wie schon von mir erwähnt, irgendwas dahinter versteht "SCHREIBEN" nicht. Oder interpretiert es anders. Jeder PC, jeder Server, jede HD hat evtl. einen CAche, der anders eingestellt ist. Und wie man sieht, Wirkt ein DBCommit() oder DbsKip(0) nicht überall gleich.

EndeDerVernunft

[xbaseklaus]

wie schon von mir erwähnt, irgendwas dahinter versteht "SCHREIBEN" nicht. Oder interpretiert es anders. Jeder PC, jeder Server, jede HD hat evtl. einen CAche, der anders eingestellt ist. Und wie man sieht, Wirkt ein DBCommit() oder DbsKip(0) nicht überall gleich.

EndeDerVernunft

Die Frage ist jetzt noch soll ich auf Verdacht jetzt überall DBcloseArea() einpflegen oder schaffe ich mir damit neue Probleme ?

mfg Klaus

[Manfred]

also nochmal, das wird philosophisch. Genauso wie die Frage ob man generell alles in Arrays lesen soll die DBF schließen und dann alles wieder zurückschreiben. Ich würde nur was ändern, wo es eben solche Probleme gibt. Wenn es sich häuft, dann schau auch mal nach, ob die Struktur generell stimmt. Vielleicht muß man auch alte Zöpfe abschneiden und etwas neu und anders programmieren. Insbesondere, wenn man von Clipper nach Xbase++ migriert. Manche Dingen löst man heute anders als damals.

[xbaseklaus]

Ok, Danke erstmal an euch Alle , wie immer ein Super Forum für Hilfesuchende wie mich !

Da ich von Gestern auf Heute durchgemacht habe , gehe ich jetzt erstmal 2 Stunden oder so schlafen

Aber nicht ohne mir vorher ein kühles Weizen zu gönnen , da ich ein Franke bin und in Franken Bier ja sowieso ein Grundnahrungsmittel ist

kann ich mir das nach 11 Uhr zugestehen

Gute Nacht und Prost !

[Jan]

Nach einem Hinweis von Hubert, das DbSkip(0) anscheinend in Xbase++ "wegoptimiert" worden ist, habe ich meine Routine umgeschrieben auf

Code: Alles auswählen

DbGoTo(RecnNo())
DbCommit()

Wichtig ist dabei auch die Reihenfolge der beiden Funktionen!

Und das hilf absolut sicher, seitdem gibt es zumindest auf der Seite keinerlei Probleme mehr.

Jan

[Wolfgang Ciriack]

Welches Bertriebssytem ist auf dem Client ? Ist vielleicht irgendetwas mit Offline-Dateien eingeschaltet ?
Ich hatte dieses Phänomen bisher nur einmal auf einem Windows Vista Client, dass der teilweise andere Daten aus einer Datenbank angezeigt hat, als ein Win7 Client. Habe ich dann den Programmpfad von gemappten Laufwerk auf UNC-Pfad umgestellt (oder umgekehrt) so war wieder alles in Ordnung. Also hatte der Vista Client irgendetwas in einer Art Cache, denn die Daten die er dann unterschiedlich anzeigte, waren immer welche ohne neuere Daten.

[xbaseklaus]

Leider zu früh gefreut - bin immer noch am Testen

replace funktioniert nicht immer trotz DBcloseArea()

Bei 3 Versuchen mit der Vorschlaghammer-Methode ging es bis jetzt:

Code: Alles auswählen

select 2
 *use anzahl1
 dbskip(0)
 netrlock(5)

termnr:=0
? anzahl1->terminnr
termnr:=anzahl1->terminnr
termnr2:=termnr+2

kkundnr:=anzahl1->kundnr
kfarbe:=anzahl1->farbe
kterminnr:=anzahl1->terminnr
kverkaufnr:=anzahl1->verkaufnr

*replace anzahl1->terminnr with anzahl1->terminnr+2

dbdelete()

netappend(5)

replace anzahl1->kundnr with kkundnr
replace anzahl1->farbe with kfarbe
replace anzahl1->terminnr with termnr2
replace anzahl1->verkaufnr with kverkaufnr

dbskip(0)
dbcommit()

? anzahl1->terminnr
wait("")
DBcloseArea()
dbunlock()

Ich lese die Felder von anzahl1 aus und mache dann ein DBdelete() um danach mit netappend(5) die ausgelesenen Felder neu anzulegen und erhöhe die Nummer !

Komischerweise so wird bis jetzt die erhöhte Nummer immer in die Datenbank geschrieben !?!

mfg Klaus

[xbaseklaus]

Also ich wollte jetzt die Datenbank Anzahl1.dbf packen um die Deleted() Sätze loszuwerden

und habe festgestellt die Datenbank läßt sich nicht EXCLUSIVE öffnen und sie ist die einzige wo das nicht geht

das ganze bricht dann mit folgender Fehlermeldung ab

Code: Alles auswählen

Xbase++ version     : Xbase++ (R) Version 1.82.306
Operating system    : Windows  06.01 Build 07601 Service Pack 1
------------------------------------------------------------------------------
oError:args         :
oError:canDefault   : Y
oError:canRetry     : N
oError:canSubstitute: N
oError:cargo        : NIL
oError:description  : Unknown/Invalid symbol for alias
oError:filename     : 
oError:genCode      :         66,00
oError:operation    : DbPack
oError:osCode       :          0,00
oError:severity     :          2,00
oError:subCode      :       8021,00
oError:subSystem    : BASE
oError:thread       :          1,00
oError:tries        :          0,00
------------------------------------------------------------------------------
CALLSTACK:
------------------------------------------------------------------------------
Called from KASSUM(210)
Called from TAGAB(181)
Called from MAIN(570)

Komischerweise auch wenn das Programm auf beiden Rechnern im Hauptmenü steht wo noch keine Datenbank gesperrt ist !?!

[Werner_Bayern]

Servus Klaus,

hast Du meinen Code mal getestet? Hab mir schon was dabei gedacht...

Tritt da der Fehler auch auf, bzw. kommt es zu einem Protokoll-Eintrag?

[xbaseklaus]

@Werner

du meinst folgendes:

Code: Alles auswählen

select anzahl1
if netflock(5)
   dbgobottom()
   termnr := anzahl1->terminnr + 2
   replace anzahl1->terminnr with termnr 
   dbcommit()
   *-------------šberprfung ob erh”ht----------
   if anzahl1->terminnr = termnr - 2
      // kann eigentlich nicht passieren, würde ich in eine Log-Datei schreiben!
      replace terminnr with termnr +2
      dbcommit()
   endif
endif
DbUnlock()

[Werner_Bayern]

yep

[xbaseklaus]

Also ich wollte jetzt die Datenbank Anzahl1.dbf packen um die Deleted() Sätze loszuwerden

und habe festgestellt die Datenbank läßt sich nicht EXCLUSIVE öffnen und sie ist die einzige wo das nicht geht

Der Fehler warum sich die Datenbank nicht EXCLUSIVE öffnen hat lassen habe ich gefunden ... Das Programm hat in speziellen Fällen den
Select Bereich der Datenbank Anzahl1 nicht freigegeben ( durch Verschachtelungen im Source Code habe ich das nicht sofort bemerkt - selber schuld !)

Jetzt kann ich sie wieder EXCLUSIVE öffnen ! Hoffe das wars jetzt !

Um eine Optimierung werde ich wohl nicht rumkommen

Danke an Alle!
mfg Klaus

[Jan]

Klaus,

ich hab das oben schon mal angemerkt - schmeiß dieses unselige Select nnn raus, und nimm stattdessen Use ... New. Damit kannst Du eine ganze Menge Probleme, die durch Unübersichtlichkeiten entstehen, vermeiden.

Jan

[Werner_Bayern]

und habe festgestellt die Datenbank läßt sich nicht EXCLUSIVE öffnen und sie ist die einzige wo das nicht geht

Hättest Du auch gleich mit meinem Code bemerkt und andere hatten Dich auch schon darauf hingewiesen.

Warum sperrst Du eigentlich die gesamte DBF, es reicht doch der eine Satz mit rlock(). Mit flock() kannst übrigens kein pack machen, da muss die DBF exclusive geöffnet werden.

[xbaseklaus]

@Werner

Ich hatte zwischenzeitlich auf netrlock() umgestellt

Trotz der Tatsache daß die DBF nicht gesperrt war und er keinen Fehler gebracht hat bei replace , trotz dbclosearea() etc. , trotz, daß die gleiche Funktionsweise bei der gleichen DBF nur auf ein unterschiedliches Feld problemlos funktionierte - und er trotz "?" Anzeige, daß er die Zahl erhöht hat bzw in die DBF angeblich geschrieben hat - aber dann doch nicht ...

Habe ich das ganze jetzt mit DBappend() und DBpack() gelöst ... was natürlich ein Vorgehen mit der Brechstange ist ... aber es läuft jetzt !!!

Ich denke mal es ist dem Umstand aus der Kombination von Windows 7 und veraltetem Xbase++ 1.82 und DBF Dateien geschuldet.

Jetzt werden viele sagen selber schuld , warum macht er auch kein UPDATE !

Tja, wenn Alaska für das auch schon alte Xbase++ 1.9 SL1 einen vernünftigen Preis machen würde gerne ... d.h. für mich nicht mehr als 500 € , da es
ja auch nicht mehr geupdatet wird !!!

mfg. Klaus

[Rolf Ramacher]

ein Hinweis von mir
ich arbeite unter xbase nicht mehr mit select, commit dbskip(0) - ich lade die Informationen in Arrays - datenbanken werden geschlossen - maske aufgebaut. nach speichern datenbanken öffnen- daten wegschreiben
datenbanken schliessen - ende

Die Datenbanken spreche ich direkt an 123->Name:="xyz"

keinerlei Probleme

wie Manfred schon sagte, "alte Zöpfe abschneiden"

[Wolfgang Ciriack]

ich arbeite unter xbase nicht mehr mit select, commit dbskip(0) - ich lade die Informationen in Arrays - datenbanken werden geschlossen - maske aufgebaut. nach speichern datenbanken öffnen- daten wegschreiben
datenbanken schliessen - ende

Und was machst du, wenn zwischenzeitlich jemand anders die Daten geändert hat ??? Wer zuerst schreibt, hat verloren ???

[Tom]

Nun, bei Web-Applikationen (und bei vielen SQL-Anwendungen) wird's exakt so gehandhabt: Der Cursor (Current Recordset) ist ein Snapshot. Was der Benutzer sieht, muss längst nicht mehr aktuell sein. Im Web geht's oft kaum anders. Inhouse-SQL-Anwendungen sollten dafür sorgen, dass Daten regelmäßig und/oder bei Änderung durch andere aktualisiert werden. Schreibt man dann Änderungen durch, überlässt man es dem Server, die korrekte Aktualisierung vorzunehmen - oder es schlägt eben fehl. Das ist hinzunehmen, wenn man im Netz Tickets fürs Kino kaufen wollte, während möglicherweise zig andere Leute den gleichen Sitzplan vor sich haben, aber es ist nicht hinzunehmen, wenn man mit kritischen Daten arbeitet. Wenn zwei oder mehr Benutzer gleichzeitig dieselben Daten bearbeiten, kann man nicht nach dem "Wer zuletzt schreibt, hatte eben die Datenhoheit"-Prinzip arbeiten. Und dann auch noch mit geschlossenen Tabellen, also ohne Anbindung an die Datenquelle. Das ist der blanke Horror. Es mag sein, dass es auf diese Weise nicht mehr zu Fehlern kommt, aber Datenprobleme anderer Art sind quasi vorprogrammiert, und zwar im schlimmsten Sinne des Wortes. Netzwerkfähig geht anders.

An den entsprechenden Stellen lesen wir auch Daten ein, meistens in Datensatzobjekte - es wird nicht direkt auf den Datenbankfeldern herumgefuhrwerkt. Allerdings werden dann die betroffenen Datensätze auch gesperrt. Die Sperrmechanismen sind verlässlich, und wenn es dennoch zu Problemen kommt, hat man Murks programmiert. Diesem Murks dadurch zu begegnen, dass man alles zumacht und später einfach an der Stelle, die man sich gemerkt hat, wieder den Krempel reinschreibt, das hat mit der "Beseitigung alter Zöpfe" nichts zu tun. Das ist Dynamitprogrammierung. Vorausgesetzt, es geht um eine Systematik, die konkurrierenden Zugriff im Netz erlaubt. Wenn das eine Single-User-Anwendung ist, kann man so arbeiten, aber elegant ist es auch nicht.

Zum Problem, um das es hier geht: Wenn es durch "Brute Force" (DbPack, Reindex, was weiß ich) weggeht, dann hat es keine Ursachen, die im Netz liegen. Sonst wären die Daten auch mit diesen Methoden weg oder niemals vorhanden. Es liegt an falschen oder fehlenden Indexdateien, falsch formulierten Indexbedingungen oder ähnlichem. Hausgemacht jedenfalls. Ganz sicher.

[Rolf Ramacher]

Hi Wolfgang

bei mir ist es so das fast ausschließlich nur ein User auf die Daten zugreift. Aber ich stimme dir zu, soblad mehrere darauf zugreifen muss dies anders gelöst werden.