BDE - Kann Dateien nicht exclusiv öffnen.

[diskalle]

Hi,
in einem alten Projekt (netzwerkfähig) welches ich vor vielen Jahren erstellte, muss ich zum Jahresende einige Datenbank Tabellen abschließend bearbeiten. Dies hat in früheren Jahren kein Problem bereitet. Ich versuche vor den benötigten Aktionen einfach die entsprechenden Dateien für den Exklusiv-Zugriff zu öffnen, gelingt dies erfolgen die Änderungen, wenn aber nicht, erfolgt ein Abbruch mit entsprechender Meldung, da die Änderungen den exklusiven Zugriff benötigen.

Obwohl der Anwender mir versichert, dass alle anderen User das Programm beendet haben und alle Rechner aus sind (bis auf seinen PC und den Server natürlich), bleibt er immer an der Meldung hängen. Leider kann ich nicht selbst dort vor Ort sein.

Ich frage mich nun, ob es möglich ist den Zugriff irgendwie zu 'erzwingen'. Soll heißen, dieses Problem zu umgehen. Hat jemand Erfahrungen damit? Kann man dies lösen eventuell durch löschen der Sperrdateien (pdoxusrs.lck) oder der pdoxusrs.net? Oder vielleicht Server neu hochfahren?

Bin für jeden Tip dankbar.

[Bernhard Geyer]

Mein Liebling: Virenscanner deaktiviert?
Bei BDE und Netzwerk wären auch die Probleme mit den optimistischen Sperrverfahren neuere Windows-Versionen ein Tipp die mit jeder Windows-Versionen größere Probleme mit der BDE verursachen.

[diskalle]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1196339)

Mein Liebling: Virenscanner deaktiviert?
Bei BDE und Netzwerk wären auch die Probleme mit den optimistischen Sperrverfahren neuere Windows-Versionen ein Tipp die mit jeder Windows-Versionen größere Probleme mit der BDE verursachen.

Danke. Klingt interessant, da wohl vor einiger Zeit auf Win7 umgestellt wurde.
Sollte ich damit aber nicht weiterkommen, wäre ein 'Hintertürchen' aber schon nicht schlecht... :roll:

[mkinzler]

Auf die Gefahr hin, dass ich nun (virtuelle) Haue kriege, wäre der beste Ausweg, die BDE durch etwas zeitgemässeres abzulösen.

[Bummi]

Ist Weibsvolk anwesend? :wink:

[jobo]

Er war's, er war's!
Sie war's...

[diskalle]

Zitat:

Zitat von mkinzler (Beitrag 1196359)

Auf die Gefahr hin, dass ich nun (virtuelle) Haue kriege, wäre der beste Ausweg, die BDE durch etwas zeitgemässeres abzulösen.

Habe befürchtet das sowas natürlich wieder kommt. Aber wenn das so einfach ginge hätte ich es längst gemacht. Der Aufwand ist halt doch ziemlich hoch und wird nicht billig für den Anwender. Und genau da haperts zur Zeit etwas. Zumal der Kunde es auch nicht hunderdprozentig einsieht, da ja sonst bisher keine Probleme aufgetreten sind. Ausserdem hilft mir das beim aktuellen Problem nicht weiter.

Also bitte noch einmal: Kennt jemand einen Trick um die gesperrten DB Dateien trotzdem exclusiv öffnen zu können?

[jobo]

Ich würde die Meldung wörtlich nehmen und annehmen, dass irgendein Prozess noch zugreift.
Zur Prüfung auf dem Host/Fileserver unter Verwaltung/ComputerVerwaltung/FreigegebenOrdner schauen, was oder wer da rumturnt und ggF. trennen.

[p80286]

[OT]

Zitat:

Zitat von diskalle (Beitrag 1196380)

Zumal der Kunde es auch nicht hunderdprozentig einsieht, da ja sonst bisher keine Probleme aufgetreten sind.

Wetten daß er auch noch einen Mexiko-Käfer fährt?:mrgreen:

Wenn es nicht so traurig wäre, man käme aus dem Lachen nicht mehr heraus.

Gruß
K-H
[/OT]

[stahli]

[auch OT]
Wenn Deine Waschmaschine nur noch mit 600 Umdrehungen läuft, Deine Wäsche aber trotzdem sauber wird und Du kein Geld für eine neue ausgeben willst/kannst, lacht sich doch auch keiner über Dich kaputt.
Es wird hier wohl kein ernst zu nehmender Entwickler ein neues und größeres Projekt mit der BDE aufbauen. Insofern ist es eine Abwägung von Aufwand und Nutzen, wann und wie man Altprojekte portiert bzw. neu aufbaut.

Vermutlich können einem übrigens auch mal andere Datenbanken um die Ohren fliegen...

Edit: Oh, ich sehe gerade: Nutzt Du noch D7 Pers??? ;-)
[/auch OT]

[haentschman]

Zitat:

Wenn Deine Waschmaschine nur noch mit 600 Umdrehungen läuft

...dann soll er aber die Waschmaschine mit 600 Umdrehungen weiter benutzen, nicht einen Motor mit 1000 einbauen und sich dann wundern daß die Kiste durch das Zimmer läuft... :roll:

Worüber diskutieren wir eigentlich ? :roll:

[diskalle]

Zitat:

Zitat von jobo (Beitrag 1196383)

Ich würde die Meldung wörtlich nehmen und annehmen, dass irgendein Prozess noch zugreift.
Zur Prüfung auf dem Host/Fileserver unter Verwaltung/ComputerVerwaltung/FreigegebenOrdner schauen, was oder wer da rumturnt und ggF. trennen.

Guter Tipp - Danke!

[hoika]

Hallo,

Team-Viewer nehmen und nachsehen.


Heiko

[mschaefer]

Moin zusammen,

handelt sich offensichtlich um eine Paradoxdatenbank. Würde mir Vollzugriff auf das Verzeichnis geben lassen, alle Tabellendateien auf lokalen Rechner kopieren, ändern und wieder uploaden. Wenn der lokale Rechner noch ein XP hat vereinfacht das die Aktion deutlich.

Grüße // Martin

[Bernhard Geyer]

Zitat:

Zitat von mschaefer (Beitrag 1196449)

... alle Tabellendateien auf lokalen Rechner kopieren, ...

Damit sollte das problem des optimistischen Sperrverfahrens entschäft werden.

[Medium]

So gewaltig ist ein Port auf z.B. MySQL o.ä. doch gar nicht :gruebel:. Klar, man muss die Tabellen halt neu erstellen *, aber die Inhalte sind mit einem kleinen 20-Zeilen Tool schnell rüber geschafft, und praktisch alle Methoden, die die BDE relevanten Komponenten bieten, sind nahezu funktional unverändert auch in aktuellen DB Kompos für "richtige" DBMS vorhanden, womit das weitestgehend ein Suchen/Ersetzen-Trip in den *.dfm und *.pas wird. So lange man ein sogar nur halbwegs ordentlich geschriebenes Programm hat, würde ich den Aufwand nahezu unabhängig von der Projektgröße auf 1-3 Tage schätzen. Wenn einem Kunden das unter dem Stichwort "Bestandsschutz" nicht wert ist, wäre fast eine Sonderberatungsstunde fällig. Vor allem dann, wenn das Projekt so groß ist, dass man eine DBMS Änderung fürchtet. Das ist auch kein hochnäsiges Gelaber, wie es wie mir scheint ab und an hier aufgenommen wird, sondern oftmals einfach die Summe an Erfahrungen in einen bestens gemeinten Rat (für Kunden und Entwickler) zusammengefasst.

*) Selbst das wäre bei ggf. extremer Anzahl an Tabellen/Spalten noch über ein eigenes Minitool sehr fix gemacht.


Wir hatten selbst bei unseren sparsamsten Kunden bislang keinerlei Probleme unsere Upgrades von Paradox auf MySQL/MariaDB bzw. MSSQL zu verkaufen. Sogar Kaufleute verstehen in der Regel, dass die Technik nicht stehen bleibt, und ein bestehendes laufendes System aktuell zu halten am Ende weit günstiger kommt, als in geringfügig größeren Abständen ein komplettes Rewrite zu ordern.

Die BDE mag in vielen Fällen noch ausreichend erscheinen, aber mit ein wenig Sinn für Weitblick sollte schnell klar werden, dass man sich und seine Kunden damit am Ende eigentlich ein wenig betrügt. Vor allem, wenn dann ggf. auf ein Mal Erweiterungswünsche aufkommen (z.B. in Richtung Web) oder komplexere Statistiken/Auswertungen: Dann kommt zu denen am Ende wohl noch der Port hinzu, und dann gilt es zwei Änderungen als eine zu verkaufen (=billiger als zwei), und wo man letztlich doch noch ein paar Stunden Lernaufwand investieren muss, die die Deadline für die neuen eigentlichen Features gefährden. Ich würde mich daher lieber an einem ruhigen Wochenende an die Umsetzung auf ein aktuelles DBMS begeben, und wenn es der Kunde partout nicht einsieht dafür Geld auszugeben, dann bekommt er es halt gratis. Mittelfristig macht es dein Leben als Entwickler später einfacher, und ein wenig lassen sich solche (sogar recht geringen) Kosten auf Folgeprojekte und andere Serviceleistungen verteilen.
Die Chance bei der Abkehr von der BDE etwas zu verlieren ist einfach viel zu gering es nicht zu versuchen.

[dummzeuch]

Zitat:

Zitat von Medium (Beitrag 1196459)

So gewaltig ist ein Port auf z.B. MySQL o.ä. doch gar nicht :gruebel:.

Ich empfehle vorher allerdings einen Blick in die Lizenzbedingungen von MySQL.

Aber diese Diskussion ist hier müßig. Es geht darum, ein konkretes Problem zu loesen.

Ich kann mich den bisher geäußerten Vorschlägen nur anschließen:

* mittels der Server-Tools nachsehen, ob die Datei vielleicht wirklich noch im Zugriff ist und von wem und wo
* Virenscanner ausschalten
* Dateien lokal kopieren, bearbeiten und nachher wieder zurueck

Wenn nichts davon hilft, muss der Kunde wohl in den sauren Apfel beißen und Remotezugriff erlauben oder schlimmstenfalls Reisekosten und Stundenlohn bezahlen.

[diskalle]

Vielen Dank an alle für eure Meinungen und Tipps zum Thema.
Leider hat alles nicht wirklich weitergeholfen und ich habe die Dateien manuell bearbeiten müssen.

Da wir nun auf Grund dieser Erfahrung die Anwendung aktualisieren wollen, bitte ich um Hinweise welche Datenbanken ihr aktuell empfehlen könntet. (@Moderator: falls das hier OT ist, bitte verschieben.)

Da ich in den letzten jahren nur noch mit Webprogrammierung zu tun hatte, bin ich nicht auf dem aktuellen Stand.
Habe schon nach einer Vergleichs-, Übersichts-, oder Testseite für solche Datenbanken gesucht aber bisher leider nichts wirklich aktuelles finden können bisher.

Als Server wird Windows Server Standard 2007 (mit SP2) eingesetzt. Etwa 10 bis 15 clients.
Was wichtig wäre:
- leichte Installation (für server und client)
- wenig Wartungsaufwand vor Ort
- kostengünstig - Open Source oder für 'kleines Geld' max. 500€
- Support und Weiterentwicklung sollte für die nächsten Jahre gesichert sein (na ja, relativ sicher halt)

Habe schon vor langer Zeit mal einiges über Absolute Database gelesen. Sind schon lange auf dem Markt aber in DE wohl nicht so bekannt oder in Gebrauch? Hat da jemand Erfahrung mit?

Bekannt ist mir sonst natürlich MySQL. Ein wenig bekannt SQLite, TurboDB, ADO, Interbase/Firebird, die alt bekannten halt.

Danke euch! :)

Edit:
Habe gerade doch noch eine interessante Aufstellung gefunden. Trotzdem wären mir eure persönlichen Erfahrungen wichtig.

[DeddyH]

Ich persönlich habe mich seit Jahren auf Firebird eingeschossen. Das erfüllt alle Deine Bedingungen, ist völlig uneingeschränkt, kostet nichts, ist nicht an Windows gebunden, lässt sich sowohl als C/S als auch Embedded betreiben und verfügt über einige nette Features wie eine RETURNING-Klausel für künstliche PKs. Administrieren lässt es sich z.B. mit IBExpert, Zugriffskomponenten gibt es sowohl kostenfreie wie UIB als auch recht kostengünstige wie IBDAC (willkürliche Auswahl). Von MySQL würde ich aufgrund der undurchsichtigen Lizenz abraten und da eher auf MariaDB setzen. Aber letztendlich musst Du natürlich selbst entscheiden.

[stahli]

Dem schließe ich mich an.

In Delphi XE3(Enterprise) wird Firebird auch offiziell von DBExpress unterstützt (wer das denn will).

[diskalle]

@ Bernhard Geyer:
Ich habe deine Infos hier mit großem Interesse gelesen. Ebenso deine Tests bezüglich Geschwindigkeit.

Daher würde ich auch lieber auf Firebird verzichten und es eventuell mit der Absolute Database versuchen wollen. Einzig dein Hinweis mit dem Indexfehler macht mich jetzt etwas unsicher. Kannst du mir dazu eventuell noch eine Info geben wie es damals dazu kam? Hast du so etwas noch einmal erlebt oder von gehört?

Habe zwischenzeitlich auch fast alles hier im Forum bezüglich Absolute Database gelesen und konnte eigentlich sonst nichts wirklich negatives finden...

[hoika]

Hallo,

der Test ist reichlich kurz ausgefallen
und damit für mich nicht ausreichend.
Wie wurden die 20.000 Datensätze eingetragen,
welche Komponenten wurden verwendet?

Wenn etwas 100 mal langsamer ist,
ist doch meistens am Code was falsch.

Code, more Code ...


Heiko

[Bernhard Geyer]

Zitat:

Zitat von diskalle (Beitrag 1197005)

@ Bernhard Geyer:
Ich habe deine Infos hier mit großem Interesse gelesen. Ebenso deine Tests bezüglich Geschwindigkeit.

Daher würde ich auch lieber auf Firebird verzichten und es eventuell mit der Absolute Database versuchen wollen. Einzig dein Hinweis mit dem Indexfehler macht mich jetzt etwas unsicher. Kannst du mir dazu eventuell noch eine Info geben wie es damals dazu kam? Hast du so etwas noch einmal erlebt oder von gehört?

Wie gesagt: Unicodefehler. D.h. der Index wurde mit Unicode(Chinesisch/Arabisch/..)-Zeichen gefüllt. Kann natürlich jetzt mit den ganzen Unicode-Delphi-Versionen gelöst sein.

[diskalle]

Zitat:

Wie gesagt: Unicodefehler. D.h. der Index wurde mit Unicode(Chinesisch/Arabisch/..)-Zeichen gefüllt. Kann natürlich jetzt mit den ganzen Unicode-Delphi-Versionen gelöst sein.

Danke, habe die Entwickler diesbezüglich angeschrieben.

[Bernhard Geyer]

Zitat:

Zitat von diskalle (Beitrag 1197132)

Zitat:

Wie gesagt: Unicodefehler. D.h. der Index wurde mit Unicode(Chinesisch/Arabisch/..)-Zeichen gefüllt. Kann natürlich jetzt mit den ganzen Unicode-Delphi-Versionen gelöst sein.

Danke, habe die Entwickler diesbezüglich angeschrieben.

Da musst du schon selbst testen. Hatte schon erlebt das eigentlich behoben Fehler immer noch vorhanden waren.
Nichts geht hier über einen entsprechende Testbasis die man mit jeder neuen Version einfach durchlaufen lassen kann.

[diskalle]

Zitat:

Da musst du schon selbst testen. Hatte schon erlebt das eigentlich behoben Fehler immer noch vorhanden waren.
Nichts geht hier über einen entsprechende Testbasis die man mit jeder neuen Version einfach durchlaufen lassen kann.

Hm... das wäre natürlich das Beste, da hast du wohl Recht. Okay, ich schau dann mal...