Anwendung löschen Daten in Datenbank

[gmc616]

Hallo DP,

Ich stehe vor einem riesen Problem.
Ich habe für eine kleine Firma ein Tool geschrieben (in D7), welchen Daten aus einer dBase-Clipper Datenbank auswerten kann.
Dafür für benutze ich den ADS LocalServer 7.x.
Die eigentliche Haupt-Anwendung der dBase-DBF ist ein DOS-Programm (mehr als 10 Jahre alt).
Das ganze läuft auf einem WinXP/SP2 Rechner. Mein Prog als Windows-Anwendung und das DOS-Prog in/auf der Console.

Das "angebliche" Problem, welches heute seit ca. 2 Jahren das dritte mal aufgetreten ist (mein Prog ist täglich im Einsatz):
Sobald mein Prog geschlossen wird, werden willkürlich Daten in der Datenbank überschrieben.
"Natürlich" ist mein Programm schuld.

Nun das eigenartige: Es werden nur einzelne Felder in den DBF-Dateien mit 0.0 überschrieben, in Tabellen die mein Programm überhaupt nicht angreift, aber im Augenblick des Beendens, in der DOS-Hauptanwendung geöffnet sind.

Ich schicke keine Nachrichten an das DOS-Prog.
Beim Beenden meines Prog wird lediglich eine DLL entladen, die ADSConnection getrennt, 2 eigene Klassen (ohne ADS) freigeben und das Mutex-Handle geschlossen.

Könnt ihr euch eine Konstellation vorstellen, wie so etwas passieren kann?
Kann es sein, dass mein Prog irgendwie den Speicher des DOS-Progs überschreibt?
Laufen DOS-Progs nicht sowieso in einem eigenen geschützten Speicherbereich?
Wie stehen die Chancen, dass tatsächlich mein Programm diesen Mist baut?
Könnte es sein, das ADS irgendwo einen Bug hat? Wisst ihr was? ... oder evtl. WinXP bezüglich dBase??

Reproduzieren lässt sich der Fehler natürlich nicht. (wäre ja zu schön)

Bittend um Hilfe und verzweifelte Grüße

gmc

[shmia]

Zitat von gmc616:

Ich habe für eine kleine Firma ein Tool geschrieben (in D7), welchen Daten aus einer dBase-Clipper Datenbank auswerten kann.

Bedeutet das, dass dein Programm grundsätzlich nur lesend zugreift ??
Falls ja, gäbe es eine einfache Möglichkeit:
Die Tabellen müssen in einem NTFS-Verzeichnis liegen und der Benutzer darf keine Schreibrechte haben.

[RavenIV]

Also ich stelle hier mal eine These auf.

Vermutlich kommt das DOS-Programm durcheinander, wenn Dein Programm die Verbindung zur DB schliesst.
Dann werden vom DOS-Programm die Felder auf 0.0 (Initialwert) gesetzt.

Zu Deinen Fragen:
Es kann nicht sein, dass Dein Programm den Speicher des DOS-Programms überschreibt.
Dein Programm macht den Mist nicht, ist aber vermutlich der Auslöser dafür (s.o.).

Bei ADO gibt es doch sicher auch einen Logger, der alles protokoliert, was zur DB geschickt wird.
Somit kann man dann herausfinden, welches Stück Software dafür verantwortlich ist.

[Bernhard Geyer]

Wer halt immer noch mit solchen mittlerweilen fragilen DB's arbeitet.

Was spricht dagegen das du die DB physikalisch kopierst und dann mit der Kopier arbeitest. Dann kannst du definitiv nichts mehr verschulden.

[s-off]

Zitat von Bernhard Geyer:

Wer halt immer noch mit solchen mittlerweilen fragilen DB's arbeitet.

Ich kann das gut nachvollziehen.
Es gibt halt Anwendungen (welche zugegebenermaßen recht speziell sind), die sich in ihrem Bereich bewährt haben, und zu denen es bis heute keine Alternativen, welche 'modernere' Datenbanksysteme einsetzen, gibt. Zumindest keine Alternative, die mit der bewährten Lösung konkurrieren könnte.

Und die Kundschaft trennt sich nur ungern von Bewährtem.

[borncrush]

Hiho,

nur mal eine kurze Zwischenfrage.
Wird hier zufällig mit der "TES"-Software gearbeitet?

[Bernhard Geyer]

Zitat von s-off:

Es gibt halt Anwendungen (welche zugegebenermaßen recht speziell sind), die sich in ihrem Bereich bewährt haben, und zu denen es bis heute keine Alternativen, welche 'modernere' Datenbanksysteme einsetzen, gibt. Zumindest keine Alternative, die mit der bewährten Lösung konkurrieren könnte.

Dann sollte man aber nicht alles mögliche "Ranhängen" bzw. als Entwickler entsprechende Vorkehrungen treffen (hier: Kopieren der DB) um nicht dann alls Löser für alle Problemfälle herhalten zu müssen (Seit ihrer neuen SW geht das und das nicht mehr - auch wenn mittels Windows-Updates das halbe Betriebssystem ausgetausch wurde).

[gmc616]

Zitat von shima:

Bedeutet das, dass dein Programm grundsätzlich nur lesend zugreift ??

Nein. Es werden u.U. Datensätze upgedated. Aber wie schon gesagt, ihn anderen Tabellen.

Zitat von shmia:

Die Tabellen müssen in einem NTFS-Verzeichnis liegen und der Benutzer darf keine Schreibrechte haben.

Das geht nicht, da die DOS-Anwendung schreibend zugreifen können muss.

Zitat von RavenIV:

Bei ADO gibt es doch sicher auch einen Logger, der alles protokoliert, was zur DB geschickt wird.

ADO habe ich probiert. Allerdings kann ADO nicht mit den Clipper Index-Dateien (*.CDX) umgehen, was aber dringend benötigt wird.
ADS ist die einzigste Komponente, die ich (damals) gefunden habe, die das kann/konnte.

Zitat von Bernhard Geyer:

Wer halt immer noch mit solchen mittlerweilen fragilen DB's arbeitet.

Kann ich leider nix dran ändern. Siehe Antwort von s-off

Zitat von Bernhard Geyer:

Was spricht dagegen das du die DB physikalisch kopierst und dann mit der Kopier arbeitest. Dann kannst du definitiv nichts mehr verschulden.

1,5 GigaByte an Daten
und Änderungen die mit dem DOS-Prog gemacht wurden müssen sofort im meinen Tool verarbeitet werden können
und Rechner + OS aus dem letzten Jahr Tausend.

Zitat von borncrush:

Wird hier zufällig mit der "TES"-Software gearbeitet?

Nein. Mit Veridis. TES kenne ich nicht.

Danke euch für das Kopfzerbrechen

gmc

[HeiztecSupport]

Hallo,

schreibende Zugriffe mit zwei verschiedenen ADS-Versionen oder/und DOS-Treiber und ADS-Treiber (DBFCDX) erzeugen zum Teil inkompatible Indizes.
Schreiboperationen können bei defekten Indizierungen zu ungewünschten Nebeneffekten führen. Dieses Phänomen konnten wir schon mehrfach beobachten.
Insbesondere in Multiuser-Environments wo das unterschiedliche Lockingverhalten der jeweiligen Treiber zu Schreibkollisionen führen kann.
ByteZero wird unterschiedlich benutzt.

Und noch etwas: der Name der unserer Software lautet HEIZTEC/2 und nicht Veridis...

Grüße
HeiztecSupport

[Bernhard Geyer]

Zitat von gmc616:

Zitat von Bernhard Geyer:

Was spricht dagegen das du die DB physikalisch kopierst und dann mit der Kopier arbeitest. Dann kannst du definitiv nichts mehr verschulden.

1,5 GigaByte an Daten

Dann solltest du froh sein das du nicht wöchentlich zerschossene Tabellen mit Datenverlust hast.
Ansonsten Tipps von HeiztecSupport verwenden und das tägliche Stoßgebet bringen das nicht irgendein Windows-Update die Sache irgendwann mal komplett lahm legt.