dbcommit() -> dbcommitall()

[Manfred]

Hallo,

hat jemand eine Ahnung, ob es einen gefährlichen Unterschied gibt zwischen dbcommit() und dbcommitall() gibt?

Dbcommit() ist doch für die aktuelle, oder eine spezielle DB gedacht und Dbcommitall() ist doch pauschal für alle derzeit geöffneten DB´s gedacht? So habe ich es aus der Doku verstanden und so scheint es auch größtenteils zu klappen

Jetzt muß ich feststellen, das es wohl Situationen geben muß, in denen ein dbcommitall() die Fehlermeldung:

Parameter has a wrong data type

erzeugt.

dbcommit() klappt dann.

Nur kann ich so ad hoc die Situation, bzw. die evtl. vorhandenen Unterschiede nicht feststellen.

[andreas]

Hallo Manfred,

so ein Fehler habe ich noch nicht gehabt, obwohl ich beide Varianten benutze. Meistens versuche ich aber sofort nach dem Replace den DBCommit auszuführen, um möglichst schnell die Indexes zu aktualisieren. Ohne DBCommit hatte ich ständig defekte Indexdateien, was jetzt sehr selten vorkommt. Am besten, wenn du es mit dem Verweis

Code: Alles auswählen

tabelle->(dbcommit())

auf die Tabelle ausführst. Sonst kenne ich keine Unterschiede bei den beiden Befehlen, ausser denen, die du aus der Doku verstanden hast:
dbcommit() - aktuelle Tabelle;
dbcommitall() - alle geöffneten Tabellen.

[Manfred]

Hallo Andreas

nach einem Schreiben in die Tabelle, verwende ich auch einen Dbcommit(). Ich habe es einfach nur noch aus Sicherheitsgründen in die AppQuit() eingebaut.

Ich muß jetzt aber nochmals nachsehen, warum es gerade in diesem pisseligen Programm knallt, denn diese Routine gilt für alle anderen Programme auch.

[andreas]

Hallo Mafred,

kann es vielleicht sein, dass zu dem Zeitpunkt, wo du dbcommitall() aufruffst, keine Datenbank mehr geöffnet ist?

[Tom]

Ich meine zu erinnern, daß es mit DbCommitAll() Probleme gibt, wenn in einzelnen Workareas noch Datensätze gelockt sind.

[Manfred]

Hi Andreas,

das war das 1. was ich geprüft hatte. Es sind zu diesem Zeitpunkt mehrere DB geöffent.

Hi Tom,

gelockt ist auch kein Satz.

Aber jetzt kommt es:

Zuerst hatte ich eine DBE in Verdacht. Also habe ich es nur mit der DBFNTX ausprobiert und die zusätzliche DBFCDX entfernt, aber der Fehler blieb.

Ich habe das Teil einmal im VX Debugger ablaufen lassen und dann bevor der dbcommitall() kommt, in dem Command Fenster .dbcommitall() eingetippt: Es erschien im Ergebnisfenster dieselbe Meldung, wie sie sonst bei dem Aufruf innerhalb des Programmes erscheint. Wenn man jetzt die gleiche Funktion nochmals aufruft, egal ob jetzt über das Programm, oder nochmals im Command Fenster, dann kommt der Rückgabewert NIL, so wie es sein soll. Jetzt gibt es auch keinen Fehler mehr.

Hm, das sieht mir nach mehr aus.....

[Manfred]

@all

ich bin ganz ehrlich, zur Zeit habe ich keine Lust weiter zu suchen.

Lt. Doku erfüllt ein DbCloseAll() den gleichen Zweck. Vorher werden alle Dateipuffer zurückgeschrieben und dann werden alle DB geschlossen.

Da sowieso an dieser Stelle Feierabend ist mit dem Programm und alles beendet werden soll, genügt mir das als Resultat.

[Manfred]

Tirili,

ich habe den Fehler gefunden.

Etwas ganz blödes, was auch eigentlich nur in der Probierphase auftauchen kann/darf/sollte.

Ich habe DB´s geöffnet und dann mit Relationen verbunden.

AAAAber, es gab keinen Index dazu. Da das eine Probe war, ist es mir erst gerade beim Einschalten des Gehirnes aufgefallen.

Relationen entfernt..... Fehler wech.

Auh weiah

PS: Also werde ich mal schnell wieder das DBCOMMITALL() einbauen, weil die Funktion scheint ja dann wohl doch cleverer zu sein als ich..... höhö

[Manfred]

Wenn ich schon mal dabei bin:

Der fehlende Index alleine war es auch nicht. Es liegt auch daran, wenn die RELATION falsch gesetzt wird. In meinem Falle kam noch hinzu, dass ich eine STR() Verbindung angegeben habe, obwohl die Relation auf die RECORD Nummer ging und die ist ja bekanntlich numerisch.

[Pope]

Hey Manfred,

ok - Du hast es ja schon selbst herausgefunden. Ich hatte auch ne ganze Zeitlang ähnliche Symptome - bis ich dann darauf gekommen bin, daß (zumindest bei mir) immer die RELATIONs schuld waren.

Beim "commit all" hast Du ja keine Kontrolle über die Reihenfolge, in der die Dateien geschlossen werden. Und die falsche Reihenfolge sorgt bei Verbindung über Relationen zu diesem Fehler.

Also - entweder sicherstellen, daß KEINE Relationen mehr gesetzt sind vor dem "commit all" - oder Dateien einzeln "commiten"

Gruß
Klaus

[Manfred]

Hi Klaus,

ok - Du hast es ja schon selbst herausgefunden. Ich hatte auch ne ganze Zeitlang ähnliche Symptome - bis ich dann darauf gekommen bin, daß (zumindest bei mir) immer die RELATIONs schuld waren.

Beim "commit all" hast Du ja keine Kontrolle über die Reihenfolge, in der die Dateien geschlossen werden. Und die falsche Reihenfolge sorgt bei Verbindung über Relationen zu diesem Fehler.

Also - entweder sicherstellen, daß KEINE Relationen mehr gesetzt sind vor dem "commit all" - oder Dateien einzeln "commiten"

Gruß
Klaus

Ich glaube da verwechselst Du jetzt etwas, bei einem committ all werden die DB nicht geschlossen, sondern nur ALLE Buffer ALLER offenen DB zurückgeschrieben. Ansonsten wäre es ja vollkommen überflüssig, diese Funktion zu nutzen. Auch bei einem DBCLOSEALL() werden erst ALLE Buffer zurückgeschrieben und dann erst geschlossen. Und da könnte ich mir vorstellen, dass es in der Reihenfolge der Selectbereiche gemacht wird.

[Pope]

Hi Manfred,

Du hast recht - ich hab mich da blöd ausgedrückt. Natürlich wird beim "commit" nix geschlossen, sondern nur die Puffer geschrieben - aber grundsätzlich bleibe ich bei meiner Aussage

Ich hatte am Ende eines Threads immer einen dbCommitAll() gefolgt von einem dbCloseAll() stehen - nach dem Motto "sicher ist sicher".

Bei vielen Kunden hatte ich ich dann über Monate den von Dir beschriebenenen Fehler "falscher Parameter" in der Commit-Zeile.

Daraufhin habe ich mal den CommitAll entfernt und nur den CloseAll stehen lassen. Dann trat genau dieselbe Fehlermeldung (Betriebssystemfehler - falscher Parameter) in der CloseAll-Zeile auf.

Also frag mich nicht wieso - aber das Ganze ist selbst heute für mich rekonstruierbar (xBase 1.82) Je nachdem welche Relationen zu diesem Zeitpunkt bestehen, tritt der Fehler mal auf - und mal nicht.

Wenn ich aber sicherstelle, daß alle Relationen getrennt werden vor CommitAll oder CommitAll+CloseAll - dann tritt der Fehler NIE auf !

Gruß
Klaus

[Manfred]

Hi Klaus,
ich werde das mal im Hinterkopf halten und darauf achten. Bisher hatte ich damit noch nie ein Problem gehabt, wenn alles ordnungsgemäß war.

Mal schauen, was die Zukunft bringt.....

[Manfred]

Noch ein kleiner Hinweis:

Ich hatte bis gerade das Problem das bei einem DBcommitAll() ein Fehler generiert wurde. Ich schätze mal, das es mit der Textdatei zusammenhängt, die ich in dem Zusammenhang über die DBE DELDBE auf hatte.

Das scheint die DBE wohl nicht gerne zu sehen...

Nur mal so, bevor sich ein anderer an die Suche macht bei einem gleichen Problem. Es reicht wenn ich allein nach dem Aha Effekt wie doof suche

[brandelh]

Beim "commit all" hast Du ja keine Kontrolle über die Reihenfolge, in der die Dateien geschlossen werden.

Hallo,

also commit all schließt sicher keine Dateien.

Die Frage ist aber warum soll ein commit all durchgeführt werden, wenn doch nur eine Area Daten verändert hat ? Das kann möglicherweise von der DBE abgefangen werden (keine Änderungen, nix schreiben) aber warum nicht selbst darauf achten und nur da wo nötig DBSKIP(0) aufrufen !

[Manfred]

Moin Hubert,

Es geht bei mir um das Programmende. Ich meine irgendwoe gelesen zu haben, das Xbase++ im Vergleich zu Clipper bei einfachem Quit nicht die Puffer zurückschreibt. Oder so ähnlich.

Auf jeden Fall steht irgendwo in dem Handbuch (ich finde es mal wieder nicht) das es empfehlenswert ist.

PS: Ich nehme alles zurück. Gerade habe ich unter Quit gelesen, dass alles ordnungsgemäß gemacht wird.

(Hm, woher habe ich das denn dann nur? Oder war das in den älteren Versionen)

[brandelh]

Hallo Manfred,

also spätestens wenn ein close ausgeführt wird, wird alles weggeschrieben.
Ich meine auch, dass Xbase++ bei Dateizugriffen sicherer ist als es Clipper war, aber das ist wohl auch nur Spekulation

[wsoftie]

Hi Folks,

habe für einen Kunden eine xBase++ 1.8 Anwendung mit obigem Treiber erstellt. Bei der Übernahme der Artikeldaten ( pur ASCII mit CRLF ) und geöffneter Datenbank mit allen Indices habe ich folgendes festgestellt :

- Schreiben der Records mit abschliessendem dbCommitAll(), Dauer des Programmes ca. 2.5 - 3.0 Stunden

- Schreiben der Records mit abschliessendem dbCommit(), Dauer des Programmes ca. 15 Minuten !

Als Betriebssystem kommt Windows XP SP 2 zum Einsatz. Habe auch von NOVELL-Administratoren gehört, das man auf dbCommitAll() verzichten soll, da der Server - sowie teilweise der Client ( abhängig von der Version ) - auch "cachen" soll und damit die Performance leidet.

Ciao
Werner