BDE/Paradox Multiclients unter Vista: Applikation hängt

[schoellm]

Zusammenfassung:
Eine BDE - Applikation (unter D7 entwickelt) wird an mehreren Client Rechnern gestartet, alle Clients greifen auf dieselbe Datenbank zu. Die Datenbank liegt auf einem VISTA-Rechner und die Clients sind ebenfalls Vista Rechner.
Problem: Am ersten Client startet die Applikation normal, am zweiten bleibt die Ausführung an der Stelle unendlich stehen, wo zum ersten mal eine Datenbanktabelle geöffnet werden soll.

Daß man von der BDE weg soll, weiß ich schon.

Hat jemand etwas Ähnliches erlebt, oder Ideen, was man tun kann? Für Hinweise wäre ich sehr dankbar.
Wer weiß, was die BDE auf der PDOXUSRS.NET genau treibt, was für einen Share sie benutzt?

Hier die Details:
* Das Symptom zeigt sich, sobald die Datenbankfiles auf einem Vista Rechner liegen. Getestet habe ich Ultimate, Business (Ordnerfreigabe) und 2008 Server. Das normale Zugreifen auf Dateien im Datenabnkordner per Explorer, (Anlegen, ändern…) funktioniert auf allen Clients problemlos
* Alles läuft problemlos, wenn die Datenbankfiles auf XP oder 2003 Server oder Novell liegen
* Die PDOXUSRS.NET liegt auch in einem zentralen Ordner auf dem Vistarechner, der Pfad ist für alle Clients korrekt und gleich eingestellt
* die bekannten Oplock-Disable Einstellungen (Registry) und Local Share habe ich überall eingestellt, mit bdechecker auch geprüft
* Am ersten Client startet die Applikation normal, am zweiten bleibt die Ausführung an der Stelle stehen, wo zum ersten mal eine Datenbanktabelle geöffnet werden soll (exclusive=False). Beendet man die App am ersten Rechner, läuft nach 1-2 Minuten die App am zweiten normal hoch. Ich konnte es auch in einer kleinen Testapp genauso nachvollziehen
* Vereinzelt sah ich auf einem XP-Client die Fehlermeldung: „Exception. Network initialization failed. Lock Time out. File: PDOXUSRS.NET. Directory: < Der Pfad wo das PDOXUSRS.NET File liegt>“
* Vereinzelt sah ich auf VISTA Clients die Fehlermeldung: „Cannot lock network file. Operating system network error. File: PDOXUSRS.NET. File: < Der komplette Pfad zum PDOXUSRS.NET File>“
* Wer will, dem kann ich auch ein Zip mit einem demoprogramm zur Verfügung stellen. Ich weiß nur nicht, wie man hier im Forum Kontakt aufnehmen kann, ohne daß die Emailadresse offen im Netz steht. Ich poste dann einen Follow Up mit Attachment.

Vermutung: Wenn die BDE versucht, ihre Clients über einen speziellen Share Zugriff auf die pdxousrs.net zu synchronisieren, klappt das nicht, sofern diese Datei auf einem Vista Rechner liegt.

[Bernhard Geyer]

Zitat:

Zitat von schoellm

* Alles läuft problemlos, wenn die Datenbankfiles auf XP oder 2003 Server oder Novell liegen

Dann lass es doch dort liegen. Falls der Rechner nicht mehr richtig vorhanden ist richte eine VM ein und spiel dort ein älteres Windows oder Novell ein.
Die BDE ist nunmal für das Netzwerkverhalten von Novell ausgelegt und mit jeder neuen Windows-Version werden die Problem größer.

Also: Entweder BDE entsorgen oder Daten auf alten Windows-Server/Novell liegen lassen.

[mkinzler]

Kann ich nur zustimmen. Microsoft hat auch den Zugriff von/auf Vista geändert. Ich habe auch Probleme mit anderen Programmen (nicht BDE;Access) beim Zugriff von Vista auf Win2003.

[schoellm]

Zitat:

Zitat von Bernhard Geyer

Zitat:

Zitat von schoellm

* Alles läuft problemlos, wenn die Datenbankfiles auf XP oder 2003 Server oder Novell liegen

Dann lass es doch dort liegen. Falls der Rechner nicht mehr richtig vorhanden ist richte eine VM ein und spiel dort ein älteres Windows oder Novell ein.
Die BDE ist nunmal für das Netzwerkverhalten von Novell ausgelegt und mit jeder neuen Windows-Version werden die Problem größer.

Also: Entweder BDE entsorgen oder Daten auf alten Windows-Server/Novell liegen lassen.

Wenn das eine Option wäre, würde ich es natürlich so machen und niemandem hier im Forum mit BDE Fragen belästigen.
Es ist eine Applikation, die bei beliebigen Kunden auf deren System und auch auf VISTA laufen muß! Die Applikation wird derzeit auf Firebird umgestellt, jedoch geht das nächste Release erst 2009 raus, und ich muss die Zeit bis dahin mit einem Workaround oder einem Fix für das aktuelle Release überbrücken.

[Bernhard Geyer]

Zitat:

Zitat von schoellm

Wenn das eine Option wäre, würde ich es natürlich so machen und niemandem hier im Forum mit BDE Fragen belästigen.
Es ist eine Applikation, die bei beliebigen Kunden auf deren System und auch auf VISTA laufen muß!

Dann mußt du die BDE entsorgen oder der werden über kurz oder lange auf Grund der Probleme mit der BDE die Kunden weglaufen.
Bei der BDE ist schon seit fast 10 Jahren bekannt das sie nicht mehr weiterentwickelt wird. Ab Delphi 2008 wird sie entgültig entsorgt.

[mkinzler]

Dann bleibt dir wohl nur die Option, dich von der BDE zu trennen, denn weder CodeGear noch sonst wär, wird das seit Jahren abgemeldete Produkt anpassen.

[schoellm]

Zitat:

Zitat von mkinzler

Dann bleibt dir wohl nur die Option, dich von der BDE zu trennen, denn weder CodeGear noch sonst wär, wird das seit Jahren abgemeldete Produkt anpassen.

Die Vergangenheit hat gezeigt, dass nicht unbedingt eine Anpassung der BDE nötig ist, um sie auf neueren Windows zum Laufen zu bringen. Oft reicht auch eine Registryeinstellung (siehe EnableOPlocks, usw.)

************************************************** *************************************************
*****BITTE KEINE DIESER WENIG HILFREICHEN VORSCHLAEGE MEHR, SIEHE MEIN ERSTES POSTING!!!!**********
************************************************** *************************************************

[Hansa]

Das da wird nichts, obs dir passt oder nicht. Die Altlasten holen dich jetzt ein. Ca. 5 Jahre nach Einstellung der BDE wurde anscheinend damit ein Projekt angefangen. Nochmals 5 Jahre wurde Zeit verplempert, zu erkennen, dass es immer mehr BDE-Ärger geben wird. Vista macht schon ohne BDE Ärger genug. Aber das auch noch zusammen ? :shock: Wo bleibt da die Strategie ? Auf keinen Fall darf jemand, der das Programm benutzen soll unsicher werden. Sollte ein Workaround dieses Preblem in den Griff kriegen, dann hätte ein anständiger Programmierer wohl immer noch ein mulmiges Gefühl. Nie und nimmer würde ich so ein Programm ausliefern. Schreibe XP vor und warne vor Vista. Das ist sowieso zu lahm und hat Dutzende Fehler. :mrgreen: Statt jetzt in Vista/BDE wieder Zeit zu verschwenden, würde ich diese nutzen, das FB-Programm schnellstens fertigzumachen. Kenne einen einzigen, der war von Vista anfangs begeistert. Was hat der jetzt ? Wieder XP. :mrgreen:

[hoika]

Hallo,

ich habe auch noch die BDE (jaja),
allerdings wurde die DB schon auf FB umgestellt.

EnableOPLocks hatte übrigens bei uns nur teilweise genützt,
die Fehler waren weniger, aber nicht weg.

Die Daten sollten nicht auf der Systemplatte liegen.
Wo liegen die bei dir ?


Heiko

[mkinzler]

[quote]

Zitat:

Zitat von schoellm

Zitat:

Zitat von mkinzler

Dann bleibt dir wohl nur die Option, dich von der BDE zu trennen, denn weder CodeGear noch sonst wär, wird das seit Jahren abgemeldete Produkt anpassen.

Die Vergangenheit hat gezeigt, dass nicht unbedingt eine Anpassung der BDE nötig ist, um sie auf neueren Windows zum Laufen zu bringen. Oft reicht auch eine Registryeinstellung (siehe EnableOPlocks, usw.)

Lösen, wie du aber siehst das Problem nicht, sondern Verschieben es u.U. nur bis zum nächsten Windows-Patch.

Zitat:

************************************************** *************************************************
*****BITTE KEINE DIESER WENIG HILFREICHEN VORSCHLAEGE MEHR, SIEHE MEIN ERSTES POSTING!!!!**********
************************************************** *************************************************

Wenn du mit Vollgas auf eine Mauer zurast, aber die Verwendung einer Bremse keine Option für dich ist, kann man dir leider nicht mehr Helfen.

[bluesbear]

Hallo schoellm,

als ich deinen Forenbeitrag las, habe ich erst einmal einen Schrecken bekommen. Wir haben hier in der Firma noch ähnlich antikes Gedöns - sogar noch urzeitlicher: Delphi 3 und Paradox/BDE :stupid:

Zitat:

Zitat von schoellm

(...)Vermutung: Wenn die BDE versucht, ihre Clients über einen speziellen Share Zugriff auf die pdxousrs.net zu synchronisieren, klappt das nicht, sofern diese Datei auf einem Vista Rechner liegt.

Ein Kollege und ich haben eben folgendes mal ausprobiert:
Datenbestand und NetDir auf einen Vista-Rechner gelegt, und von mehreren anderen XP Rechnern gleichzeitig darauf zugegriffen.
Ich weiß nun nicht, ob es für dich nun eine gute oder schlechte Nachricht ist: Es hat auf Anhieb ohne Probleme geklappt. Dumm ist nur, daß ich dir nicht sagen kann, wie und warum, außer "einfach so". :wink:

In welchem Verzeichnis genau liegt dein NetDir? Vielleicht kommt da mit dieser Wirrtualisierungsgeschichte was durcheinander.
Benutzt du UNC-Pfade?

[schoellm]

Zitat:

Zitat von hoika

Hallo,

ich habe auch noch die BDE (jaja),
allerdings wurde die DB schon auf FB umgestellt.

EnableOPLocks hatte übrigens bei uns nur teilweise genützt,
die Fehler waren weniger, aber nicht weg.

Die Daten sollten nicht auf der Systemplatte liegen.
Wo liegen die bei dir ?


Heiko

Sie liegen auf einer zweiten Datenpartition.

[schoellm]

Zitat:

Zitat von bluesbear

Hallo schoellm,

als ich deinen Forenbeitrag las, habe ich erst einmal einen Schrecken bekommen. Wir haben hier in der Firma noch ähnlich antikes Gedöns - sogar noch urzeitlicher: Delphi 3 und Paradox/BDE :stupid:

Zitat:

Zitat von schoellm

(...)Vermutung: Wenn die BDE versucht, ihre Clients über einen speziellen Share Zugriff auf die pdxousrs.net zu synchronisieren, klappt das nicht, sofern diese Datei auf einem Vista Rechner liegt.

Ein Kollege und ich haben eben folgendes mal ausprobiert:
Datenbestand und NetDir auf einen Vista-Rechner gelegt, und von mehreren anderen XP Rechnern gleichzeitig darauf zugegriffen.
Ich weiß nun nicht, ob es für dich nun eine gute oder schlechte Nachricht ist: Es hat auf Anhieb ohne Probleme geklappt. Dumm ist nur, daß ich dir nicht sagen kann, wie und warum, außer "einfach so". :wink:

In welchem Verzeichnis genau liegt dein NetDir? Vielleicht kommt da mit dieser Wirrtualisierungsgeschichte was durcheinander.
Benutzt du UNC-Pfade?

In unserer der reellen App liegt das NetDir auch auf dem Vistarechner, in einem eigenen Ordner (gleich für alle Clients, über UNC Pfade definiert).
Ich habe eine Demoapp als zip (incl Source und db) angefügt.
In den Virtualstore Ordnern wurden keine Daten angelegt.
Ich habe mit und ohne 'User Access control' probiert, es ändert nichts.

[franktron]

Über UNC Pfade mit BDE ist keine gute Idee, das gibt massig Ärger.

[QuickAndDirty]

bei uns geht das.
Ich weiß das zwar auch nur von einem Kunden...
aber ich bin gerne bereit mich an der Lösung zu beteiligen

Wenn du in der Registry unter Borland nachschaust
HKEY_LOCAL_MACHINE\SOFTWARE\Borland\Database Engine\Settings\DRIVERS

Hier sollten über 20 treiber drinn sein, wenn hier nur so 7 Treiber oder so drin sind
dann kommen die von MS OFFICE oder MS SBS oder... MS.*

Wenn die nicht von den Betaversionen dieser Produkte kommen kann man sie über umbennen
des Borland schlüssels und neuinstallieren der BDE wieder zum laufen bringen.
Kommen die von den Betaversionen muss das System neu aufgesetzt werden.


Man kann in Windows die maximale anzahl gleichzeitiger Benutzer auf einer Freigabe einstellen hast du das mal geprüft?


BDE und UNC pfade sind an sich das beste sollt immer klappen wenn die rechte gut vergeben sind "Vollzugriff für jeder"

Geht die test anwendung auch auf 2 Vista rechnern wobei auf einem der Client und die Daten liegen?

[bluesbear]

Moin shoellm,
ich habe deine Demoapp mal getestet:
Gleichzeitiger Zugriff auf die Daten von 3 XP Rechnern funktioniert, Zugriff von einer Vista-VM aus klappt überhaupt nicht, nicht einmal einzeln. Das Programm bleibt beim table.Open hängen.

Bei dem Test mit unserem eitgenen Programm gestern klappte es auch von der Vista-VM aus.
Der einzige Unterschied den ich soweit erkennen kann ist, wir hatten das NetDir vorher über die BDE Verwaltung eingestellt (alle BDE Programme geschlossen, NetDir umgestellt, getestet). Im Programm selber wird das nicht angefasst.

Hossa, mein Kollege ist grad schwer am fluchen. Der darf die Vista-VM neu starten - BDE technisch geht da scheinbar gar nix mehr (hagelt Fehlermeldungen der duiosesten Art) :mrgreen:

EDIT: Wenn man das NetDir vorher umstellt klappt auch deine Testapp. Allerdings nur, wenn keiner der XP-Rechner auf die daten zugreift. Sehr seltsam...

[QuickAndDirty]

Das müst sich doch auch mit unter XP compilierten DLLS erreichen lassen welche dann eben die Dateizugriffe machen.

Es kann doch nur daran liegen das der Dateizugriff auf Vista anders abläuft.

Evtl. must du einen Samba für Vista entwickeln :)

[schoellm]

Zitat:

Zitat von QuickAndDirty

bei uns geht das.
Ich weiß das zwar auch nur von einem Kunden...
aber ich bin gerne bereit mich an der Lösung zu beteiligen

Wenn du in der Registry unter Borland nachschaust
HKEY_LOCAL_MACHINE\SOFTWARE\Borland\Database Engine\Settings\DRIVERS

Hier sollten über 20 treiber drinn sein, wenn hier nur so 7 Treiber oder so drin sind
dann kommen die von MS OFFICE oder MS SBS oder... MS.*

Wenn die nicht von den Betaversionen dieser Produkte kommen kann man sie über umbennen
des Borland schlüssels und neuinstallieren der BDE wieder zum laufen bringen.
Kommen die von den Betaversionen muss das System neu aufgesetzt werden.

Die Rechner auf denen ich teste, sind Neuinstallationen von Vista, wo nichts außer unserer Software und die BDE Installation, die wir verwenden, drauf installiert ist. Es liegt wohl kaum an einer an sich fehlerhaften BDE Installation auf den Client Rechnern, denn wenn ich die Datenbank bei unveränderten Client Rechnern auf einen XP Rechner/2003 Server schiebe, funktioniert alles.
Unter Drivers sind die Ordner paradox, foxpro,dbase, msaccess.

Zitat:

Zitat von QuickAndDirty

Man kann in Windows die maximale anzahl gleichzeitiger Benutzer auf einer Freigabe einstellen hast du das mal geprüft?

Der Wert ist hoch genug, sonst könnte ich ja auch nicht per Explorer auf das Datenverzeichnis zugreifen

Zitat:

Zitat von QuickAndDirty

Geht die test anwendung auch auf 2 Vista rechnern wobei auf einem der Client und die Daten liegen?

[/quote]
In diesem Fall ist es so: Starte ich die App auf dem Client ohne Daten (Rechner1) zuerst und dann auf dem zweiten mit Daten (Rechner2) , geht es. Ich vermute, weil dieser ja die Daten auf der Maschine hat und daher 'besser' und ohne Netzwerk auf diese pdoxusrs.lck zugreifen kann
In der umgekehrten Reihenfolge läuft das Programm auf Rechner2 normal und, wenn man es dann noch auf dem Rechner1 startet, hängt es dort

[schoellm]

Zitat:

Zitat von QuickAndDirty

Das müst sich doch auch mit unter XP compilierten DLLS erreichen lassen welche dann eben die Dateizugriffe machen.

Die Dateizugriff mache doch nicht ich, sondern die BDE. Da habe ich keine Kontrolle. Ich mach nur table.open

[QuickAndDirty]

ich meine um es nach zustellen.
Müste man DLL unter XP Compilieren welche datei zugriffe ausführen.

Die müsten dann ja den selben Fehler reproduzieren können.
Dann kann man ja auch Rausfinden was der Scheiß soll und wieso es passiert.

Es muss doch irgendwie an CreateFile Liegen oder?
Und das Problem müste dann auch mit normalen Dateien auftreten. Es sei den es gibt

Code:

if (cmpstr(filename,'paradox.net')==0){
  dostupidaction();
}

Abschnitte.

Das gab es ja auch schon mal in MS-Office damit das nicht auf einer MSDos kompatiblen Dos Alternative
läuft.

[hoika]

Hallo,

prüfe mal, was für Datei-Rechte die .lck (im db Verzeichnis)
und die pdoxusrs.net (net dir) haben.

Dazu muss des 1. Programm gestartet sein.


Heiko

[schoellm]

Zitat:

Zitat von hoika

prüfe mal, was für Datei-Rechte die .lck (im db Verzeichnis)
und die pdoxusrs.net (net dir) haben.

Dazu muss des 1. Programm gestartet sein.
Heiko

Ich habe den Dateizugriff auf dem Ordner, wo die lck, .net und .db Dateien liegen, so eingestellt:
Die Benutzer 'Jeder', 'Autorisierte Benutzer', 'User1' (den benutze ich bei beiden Clients zum Anmelden auf dem Server), administrator
haben alle
Vollzugriff, lesen-ausführen, schreiben, Ändern, Erstellen, und was es sonst noch für Häkchen gibt (außer "Spezielle Berechtigungen")
Die Berechtigungen werden auf alle Dateien darunter vererbt.
Wenn gerade das Programm nicht offen ist, kann ich auch die Dateien beliebig im explorer/Editor erstellen, ändern, löschen.
Wenn es offen ist, kann ich das nicht (aber das ist normal, auch mit Datenbank auf einem 2003 Server nicht anders)

Wie ich ganz oben schrieb, die BDE verwaltet die Sperrungen auf Tabellen/Datensätze bei parallelem Zugriff meines Wissens über die .lck Datei. Ich denke, die BDE wird an allen Clients versuchen, die Datei in einem speziellen 'Share' Modus öffnen, so daß alle ihre Sperren reinschreiben können und sich dadurch synchronisieren.

[schoellm]

Zitat:

Zitat von QuickAndDirty

ich meine um es nach zustellen.
Müste man DLL unter XP Compilieren welche datei zugriffe ausführen.

Die müsten dann ja den selben Fehler reproduzieren können.
Dann kann man ja auch Rausfinden was der Scheiß soll und wieso es passiert.

Es muss doch irgendwie an CreateFile Liegen oder?
Und das Problem müste dann auch mit normalen Dateien auftreten. Es sei den es gibt

Code:

if (cmpstr(filename,'paradox.net')==0){
  dostupidaction();
}

Abschnitte.

Wie ich ganz oben schrieb, die BDE verwaltet die Sperrungen auf Tabellen/Datensätze bei parallelem Zugriff meines Wissens über die .lck Datei. Spekulation: die BDE versucht, an allen Clients die Datei in einem 'Share' Modus öffnen (OF_SHARE_DENY_NONE, FILE_SHARE_WRITE ...), so daß alle ihre Sperren reinschreiben können und sich dadurch synchronisieren.

Wo man es compiliert, ist egal. Problem ist, daß ich nicht weiß, welcher Öffnungsmodus von der BDE verwendet wird.

Vielleicht könnte man in "perfmon" oder einem anderen Windows-Diagnoseprogramm auf dem Server irgendwie rauskriegen, welche Dateien wie geöffnet werden, oder wo das Problem liegt. Aber spontan fand ich unter den unzähligen 'Leistungsindikatoren' nichts Brauchbares. In den eventlogs stand auch nichts Auffälliges.
Vielleicht weiß jemand, wie man auf dem 2008 Server irgendwie 'geblockte' Dateianfragen sehen kann. Bei 'Geöffnete Dateien verwalten' war ich, dort zeigt der Server für die .lck Dateien folgendes an:
* 'geöffnet durch' = der Benutzer, der das Programm zuerst gestartet hat
* 'Anzahl Sperren' = 0
* 'Öffnungsmodus' = Lesen, Schreiben

[QuickAndDirty]

Kann es nicht sein das Spiezielleberechtigung auch gesetzt sein sollte?

[schoellm]

Endlich habe ich in einem anderen Forum einen vernünftigen Hinweis erhalten. Es handelt sich nicht um ein BDE Problem sondern um einen Vistabug, der Microsoft schon bekannt ist. Betroffen ist nicht nur BDE, sondern alle "Nicht-Client-Serverdatenbanken", die auf einem Shareordner unter Vista liegen (auch z.B. Access).
Anscheinend in Vista SP1 behoben.
http://www.delphipages.com/threads/t...95262&G=195217

Hier ein freundlicher Gruß an alle Besserwisser, die unkonstruktive Ratschläge gegeben haben: ist doch mal wieder Microsoft schuld, und hat sich auch noch selbst ins Knie geschossen.

[bluesbear]

Zitat:

Zitat von schoellm

(...)Anscheinend in Vista SP1 behoben.(...)

Gut zu wissen. Da wär isch im Lääbe net druff gekomme! :stupid:

[mkinzler]

Deshalb also weiter auf die BDE setzen, bis die Wand da ist. :zwinker:

[Bernhard Geyer]

Zitat:

Zitat von mkinzler

Deshalb also weiter auf die BDE setzen, bis die Wand da ist. :zwinker:

Lassen wir ihn. Er hatt jetzt Glück gehabt das sein Programm "nur" ca. 4 Monate (Vista-Releas Dezember 2007, Bugfix-Release April 2008) nicht lauffähig war und es keiner gemerkt hat. Beim nächsten Vista-Bug welcher nur die BDE betrifft wird MS nix machen und er kann sich dann über MS ärgern.

Ach ja: Wieviel Stunden hatt die Fehlersuche gedauert? Wieviel Prozent des Programmes wären damit umgestellt gewesen?

[bluesbear]

Zitat:

Zitat von Bernhard Geyer

(...) Wieviel Prozent des Programmes wären damit umgestellt gewesen?

Bei mir wären es nicht mal annähernd Promille.
Wieso geht ihr eigentlich davon aus, das sich jemand heutzutage noch *freiwillig mit der BDE rumschlägt?
Diese Vorstellung ist absurd.
Die Zeitbombe ist einmal mehr entschärft worden, für ne Weile. :zwinker:

[Bernhard Geyer]

Zitat:

Zitat von bluesbear

Zitat:

Zitat von Bernhard Geyer

(...) Wieviel Prozent des Programmes wären damit umgestellt gewesen?

Bei mir wären es nicht mal annähernd Promille.

Dannn sollte man sich überlegen ob die Architektur der SW passend ist. Stichwörter sind hier Kapslung des DB-Zugriffs.
Ich habe schon mal in 2-3 Tagen den DB-Zugriff auf MySQL von BDE auf native Komponenten umgestellt. War aber auch einfach da der DBMS-Spezifische Teil eh schon in einer Unit gekapselt ist.

Zitat:

Zitat von bluesbear

Wieso geht ihr eigentlich davon aus, das sich jemand heutzutage noch *freiwillig mit der BDE rumschlägt?
Diese Vorstellung ist absurd.

Also sollte man etwas dagegen machen und auch Überzeugungsarbeit auf Chefebene leisten. Denn falls du das nicht machst (bzw. machst aber nicht eindeutig Protokollierst) so wirdst du der Schuldige sein der für die Katastrophe verantwortlich ist wenn z.B. mit XP SP3 es keinen Ausweg mehr gibt.

[hoika]

Hallo,

ich würde zuerst mal die Datenbank umstellen,
und nein, die BDE ist keine Datenbank.

Ich hatte damals ne Woche gebraucht,
um eine alte Paradox-App umzustellen
auf Interbase. Es wurde/wird aber immer noch die BDE benutzt.

Das Programm ist schon RAD-mäßig erstellt,
also TTable aufs Form packen und Table.Open im FormCreate.

Der Aufwand ist extrem, jetzt hier die BDE zu eretzen,
ich bin aber fleissig dabei.

Probleme unter Vista gibt es nicht,
aber weg will ich trotzdem.

Hierbei benutze ich das bridge pattern,
um später (sehr viel später ;) ) auch andere
DB's unterstützen zu können.
Ausserdem läuft das Programm so mal "native" BDE,
mal "native" FIBPlus.

Das Hauptproblem bei der Umstellung sind Fehler,
die sich durch Umstellung von TTable auf TQuery ergeben.

-> dUnit


Heiko

[bluesbear]

Hallo Bernhard,
selbstverständlich gebe ich dir recht.
Das war in der Tat reines Glück, daß kein Kunde auf Vista ungestellt hat, bevor SP1 rauskam. Ich bin heilfroh, daß dieser Kelch auch an mir vorüber ging.

Ich möchte hier jedoch spasseshalber auch mal Überzeugungsarbeit auf Forumsebene leisten. :zwinker:

Zitat:

Zitat von Bernhard Geyer

(...)Dannn sollte man sich überlegen ob die Architektur der SW passend ist.(...)

Bei einem über zehn Jahre entwickelten und mit Hilfe immer neuer Kundenwünsche - ich sag mal - "ausgereiften" <g> Programm kann man nur noch von Architektur sprechen, wenn man Heißkleber als Baustoff akzeptiert. :mrgreen:

Das Programm muss beim Kunden laufen, bis die nächste, dann hoffentlich architektonisch saubere, ich tu mein Bestes, Version fertig ist. Bei hunderten von Tabellen und vielen hunderttausend Zeilen Code kann das ne Weile dauern.
Wenn es da Probleme gibt, müssen sie gelöst werden. BDE-Bashing ist da wenig hilfreich, so gerne ich mich auch daran beteiligt hätte. :angel2:

Wer sich heute noch mit der BDE herumschlagen muss, verdient in meinen Augen Mitleid, und nicht auch noch eins auf die Mütze <g>. :zwinker:

Panta rhei.

[Bernhard Geyer]

Zitat:

Zitat von bluesbear

Das Programm muss beim Kunden laufen, bis die nächste, dann hoffentlich architektonisch saubere, ich tu mein Bestes, Version fertig ist. Bei hunderten von Tabellen und vielen hunderttausend Zeilen Code kann das ne Weile dauern.
Wenn es da Probleme gibt, müssen sie gelöst werden. BDE-Bashing ist da wenig hilfreich, so gerne ich mich auch daran beteiligt hätte. :angel2:

Wenn man ja drüber ist hier etwas zu machen, aber aktuell noch mit BDE-belasteten Code arbeiten muss so hilft man gerne (soweit man überhaupt noch BDE-Wissen hat). Wenn jedoch gar nichts gemacht wird und der Spruch der Art kommt: "Wieso was machen, es läuft doch und die Fehler hab ich immer noch (mit wieviel Tagen aufwand :gruebel:) immer noch lösen können." dann stört das mich und mit Sicherheit andere auch. Es wird der Tag kommen das das hinauszögern dieser Entscheidung dazu führen wird das das Produkt eingestampft wird ("Oh, die Konkurrenz ist ja viel besser, da lohnt es sich nicht mehr irgendwas zu mache. Suchen sie sich am besten einen Neuen Job, wir Melken nur noch unsere Bestandskunden"). Bei meiner früheren Firma ist sowas im Bereich MFC/16-Bit passiert. Jahrelang wurde vermieden mal eine größere Renovierung der SW durchzuführen und irgendwann war der PC-Basierte Teil der Lösung ein KO-Kriterium für potentielle neue Kunden.

[schoellm]

Ich habe den woanders gefundenen Hinweis getestet, und nach dem Installieren des Hotfixes von MS funktioniert alles wieder.
Ich sehe das Problem als gelöst an (habe aber keinen entsprechenden Button in dieser Forumsoftware gefunden) und kann mich jetzt weiter der ohnehin schon begonnenen DB-Umstellung widmen.

Danke für die rege Beteiligung.