37414
23.09.2015, aktualisiert um 10:36:05 Uhr
3282
36
0
Spezialist für Delphi und Paradox 5 gesucht gegen Bezahlung
Hallo,
wie ja schon in mehreren Threads beschrieben, haben wir mit einem eigens für uns erstellten Programm immer wieder Probleme.
Der damalige Programmierer hat seine Arbeit für uns schon vor Jahren eingestellt.
Das Programm basiert auf Delphi / Paradox 5
Da die Probleme (Programmabstürze, Datenverluste in Datenbanken, Verluste von Texten etc.) unsere Arbeit erheblich erschweren und fast unmöglich machen, hat unser Vorstand nun entschieden, einen externen Spezialisten zu suchen, der uns ggf. weiterhelfen kann. Natürlich muss dieser Spezialist sich mit Delphi / Paradox 5 auskennen.
Wir sind ansässig in Bonn (Innenstadt) und wären froh, wenn sich hier über dieses Forum Jemand finden würde, der uns weiterhelfen kann.
Das diese Hilfe gegen Bezahlung erfolgt, dürfte sich von selbst verstehen...
Freue mich auf Eure Antworten.
Danke & schöne Grüße,
imebro
wie ja schon in mehreren Threads beschrieben, haben wir mit einem eigens für uns erstellten Programm immer wieder Probleme.
Der damalige Programmierer hat seine Arbeit für uns schon vor Jahren eingestellt.
Das Programm basiert auf Delphi / Paradox 5
Da die Probleme (Programmabstürze, Datenverluste in Datenbanken, Verluste von Texten etc.) unsere Arbeit erheblich erschweren und fast unmöglich machen, hat unser Vorstand nun entschieden, einen externen Spezialisten zu suchen, der uns ggf. weiterhelfen kann. Natürlich muss dieser Spezialist sich mit Delphi / Paradox 5 auskennen.
Wir sind ansässig in Bonn (Innenstadt) und wären froh, wenn sich hier über dieses Forum Jemand finden würde, der uns weiterhelfen kann.
Das diese Hilfe gegen Bezahlung erfolgt, dürfte sich von selbst verstehen...
Freue mich auf Eure Antworten.
Danke & schöne Grüße,
imebro
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 283668
Url: https://administrator.de/contentid/283668
Ausgedruckt am: 22.11.2024 um 15:11 Uhr
36 Kommentare
Neuester Kommentar
Ich kenne mich zwar weder mit dem einen, noch mit dem anderen aus, aber ich denke, das eine genauere Beschreibung nicht blöd wäre.
Was macht das Programm so im allgemeinen ( Ist es eine WaWi ? Ein Spiel? Videoplayer ? )
Umfang des Programms, was für eine DB wird eingesetzt etc.
So ein paar Randinfos, um abschätzen zu können, mit was man es denn da zu tun hat und ob man dafür der Richtige ist
Was macht das Programm so im allgemeinen ( Ist es eine WaWi ? Ein Spiel? Videoplayer ? )
Umfang des Programms, was für eine DB wird eingesetzt etc.
So ein paar Randinfos, um abschätzen zu können, mit was man es denn da zu tun hat und ob man dafür der Richtige ist
Zitat von @SeaStorm:
Ich kenne mich zwar weder mit dem einen, noch mit dem anderen aus, aber ich denke, das eine genauere Beschreibung nicht blöd wäre.
Was macht das Programm so im allgemeinen ( Ist es eine WaWi ? Ein Spiel? Videoplayer ? )
Umfang des Programms, was für eine DB wird eingesetzt etc.
Ich kenne mich zwar weder mit dem einen, noch mit dem anderen aus, aber ich denke, das eine genauere Beschreibung nicht blöd wäre.
Was macht das Programm so im allgemeinen ( Ist es eine WaWi ? Ein Spiel? Videoplayer ? )
Umfang des Programms, was für eine DB wird eingesetzt etc.
Moin,
wegen der Datenbank steht es doch im Beitrag drin. Es handelt sich um Paradox 5. Paradox war ursprünglich eine Datenbank von Borland.
Wenn ich es verstehe, ist die Anwendung in der Programmiersprache Delphi entwickelt worden, und nutzt Paradox 5 als Daternbank.
Gruss Penny.
Moin,
entscheidend ist vor allem: Liegt der Quellcode inkl. der ggf. genutzten "externen" VCL-Komponenten vor? Vielleicht sogar die Komplette Entwicklungsumgebung? Dies ist die Grundvoraussetzung, um überhaupt die Möglichkeit zu haben, Fehler in der derzeit genutzten Programmversion zu beseitigen. Anderenfalls ist das beinahe aussichtslos...
In welcher Delphi-Version wurde denn überhaupt programmiert? Wenn da noch eine Paradox-DB genutzt wurde tippe ich mal so in Richtung Delphi 5...?
Gruß
NetSonic
entscheidend ist vor allem: Liegt der Quellcode inkl. der ggf. genutzten "externen" VCL-Komponenten vor? Vielleicht sogar die Komplette Entwicklungsumgebung? Dies ist die Grundvoraussetzung, um überhaupt die Möglichkeit zu haben, Fehler in der derzeit genutzten Programmversion zu beseitigen. Anderenfalls ist das beinahe aussichtslos...
In welcher Delphi-Version wurde denn überhaupt programmiert? Wenn da noch eine Paradox-DB genutzt wurde tippe ich mal so in Richtung Delphi 5...?
Gruß
NetSonic
Hey imebro,
wenn Ihr eh den Quellcode nicht besitzt, dann ist es auch nicht möglich, am Programm selbst noch etwas zu verändern.
In dem Fall bleibt Euch doch nur, das Programm neu entwickeln zu lassen. Und dafür benötigt Ihr einen Programmierer. Dabei ist es dann unerheblich, ob der nun Delphi bzw. Object Pascal beherrscht oder C#, VB.net o.ä...
Man kann sicherlich die Paradox-Daten noch portieren, aber das ganze Frontend inkl. Funktionalität muss von Grund auf neu erstellt werden.
Gruß
NetSonic
wenn Ihr eh den Quellcode nicht besitzt, dann ist es auch nicht möglich, am Programm selbst noch etwas zu verändern.
In dem Fall bleibt Euch doch nur, das Programm neu entwickeln zu lassen. Und dafür benötigt Ihr einen Programmierer. Dabei ist es dann unerheblich, ob der nun Delphi bzw. Object Pascal beherrscht oder C#, VB.net o.ä...
Man kann sicherlich die Paradox-Daten noch portieren, aber das ganze Frontend inkl. Funktionalität muss von Grund auf neu erstellt werden.
Gruß
NetSonic
Fehler im Programm lassen sich ohne Quellcode niemals korrigieren. Egal in welcher Sprache.
Bei der Datenbank sieht das anders aus. Aber Paradox auf einem Terminalserver ist schon mal ziemlich übel. Dafür ist das ganze Konstrukt mit BDE-Datenbanktreiber usw. viel zu alt. Der Server ist dazu auch noch 64bit?! Kein Wunder, dass es da Probleme gibt.
Wie viele User greifen denn gleichzeitig auf die Datenbank zu und welchen Umfang hat die Paradox-DB mittlerweile?
Statt zu versuchen, da jetzt einem "sterbenden" bzw. eigentlich schon "toten" Gaul wieder Leben einzuhauchen, ist es wirklich besser, sich nach einer neuen Lösung umzusehen die auch zukunftsfähig ist.
Bei der Datenbank sieht das anders aus. Aber Paradox auf einem Terminalserver ist schon mal ziemlich übel. Dafür ist das ganze Konstrukt mit BDE-Datenbanktreiber usw. viel zu alt. Der Server ist dazu auch noch 64bit?! Kein Wunder, dass es da Probleme gibt.
Wie viele User greifen denn gleichzeitig auf die Datenbank zu und welchen Umfang hat die Paradox-DB mittlerweile?
Statt zu versuchen, da jetzt einem "sterbenden" bzw. eigentlich schon "toten" Gaul wieder Leben einzuhauchen, ist es wirklich besser, sich nach einer neuen Lösung umzusehen die auch zukunftsfähig ist.
Moin,
Für Delphi gibt es zwar sehr gute Code-Decompiler, aber trotzdem bleibt das eine Herausforderung die bestimmt nicht mehr rentabel und sehr kostenintensiv wäre.
Macht einen sauberen Cut das ist allemal besser und vor allem billiger.
Gruß grexit
Zitat von @37414:
Wir dachten halt, dass man auch ohne Quellcode eine Möglichkeit hätte, die Fehler zu beheben,
Nearly impossible ... gerade wenn es sehr komplex programmiert ist.Wir dachten halt, dass man auch ohne Quellcode eine Möglichkeit hätte, die Fehler zu beheben,
Für Delphi gibt es zwar sehr gute Code-Decompiler, aber trotzdem bleibt das eine Herausforderung die bestimmt nicht mehr rentabel und sehr kostenintensiv wäre.
Macht einen sauberen Cut das ist allemal besser und vor allem billiger.
Gruß grexit
Zitat von @37414:
Könnte man sagen, dass es nicht klug - oder gar ein Fehler war, dieses Programm auf dem Terminalserver laufen zu lassen?
Absolut, gerade wenn es nicht für den gleichzeitigen Zugriff ausgelegt wurde. Dann kann das sehr schnell zu Inkonsistenzen durch konkurenten Zugriff auf dem TS führen.Könnte man sagen, dass es nicht klug - oder gar ein Fehler war, dieses Programm auf dem Terminalserver laufen zu lassen?
Die Datenbanken liegen jedoch in einem Verzeichnis auf einem anderen Server (Fileserver).
Das macht keinen Unterschied, außer das bei einem Netzausfall die Datenbanken zusätzlichen gefährdet sind, wofür sie vermutlich auch nicht ausgelegt worden sind.
Da kann ich grexit nur in allen Punkten zustimmen.
Habt Ihr wenigstens schon mal so Standard-Dinge ausprobiert, wie z.B. Virenscanner zu deaktivieren bzw. Ausnahmeregeln für die entsprechenden Verzeichnisse zu definieren? Alternativ gibt es da noch Registry-Einträge für "OpLocks" meine ich. Da musst Du mal googeln nach "Paradox BDE OpLocks" oder so ähnlich. Vielleicht ist da noch ein Tipp dabei. Aber bitte, denkt wirklich darüber nach eine andere Lösung zu suchen. Irgendwann fährt das Ding nämlich komplett vor die Wand und dann ist es zu spät...
Habt Ihr wenigstens schon mal so Standard-Dinge ausprobiert, wie z.B. Virenscanner zu deaktivieren bzw. Ausnahmeregeln für die entsprechenden Verzeichnisse zu definieren? Alternativ gibt es da noch Registry-Einträge für "OpLocks" meine ich. Da musst Du mal googeln nach "Paradox BDE OpLocks" oder so ähnlich. Vielleicht ist da noch ein Tipp dabei. Aber bitte, denkt wirklich darüber nach eine andere Lösung zu suchen. Irgendwann fährt das Ding nämlich komplett vor die Wand und dann ist es zu spät...
So ein altes Programm lässt man auch nicht auf einem x64 System zudem noch Terminal Server laufen.
Ich würde an eurer Stelle evtl. auch mal darüber nachdenken, den IT-Leiter zu wechseln, wenn er solch eine Software ohne Support vom Hersteller von Einzelplatz Lösungen zu einer TS-Lösung umbastelt.
Wenn du pech hast, läuft das ganze natürlich nicht auf Win7 sondern nur unter XP, worauf es vermutlich entwickelt wurde.
Hier könntest du im Notfall einen älteren XP-Rechner hinstellen, um die Software darauf laufen zu lassen oder Testweise mal im XP-Modus unter Win7.
Lg Pago
Ich würde an eurer Stelle evtl. auch mal darüber nachdenken, den IT-Leiter zu wechseln, wenn er solch eine Software ohne Support vom Hersteller von Einzelplatz Lösungen zu einer TS-Lösung umbastelt.
Wenn du pech hast, läuft das ganze natürlich nicht auf Win7 sondern nur unter XP, worauf es vermutlich entwickelt wurde.
Hier könntest du im Notfall einen älteren XP-Rechner hinstellen, um die Software darauf laufen zu lassen oder Testweise mal im XP-Modus unter Win7.
Lg Pago
@NetSonic Da ja schon die neue Programmierung in Auftrag gegeben ist, wollte ich diese Lösungen (Workarounds) noch schnell erwähnen, da dies bei einer mehr Monatigen Software Programmierung doch noch einige Probleme zu erwarten sind
Hallo,
Ob allerdings selbst ein TS auf Server 2003 da noch die Applikation sauber laufen lässt ist trotzdem höchst fraglich.
Gruß,
Peter
Prüfen ob die Hardware es tut
http://www.microsoft.com/en-us/download/details.aspx?id=592
XP Modus herunterladen
http://www.microsoft.com/de-de/download/details.aspx?id=8002
Wie es alles geht
http://windows.microsoft.com/de-de/windows7/install-and-use-windows-xp- ...
Zitat von @37414:
Programmierung fertig ist.
Und dann muss sich in den darauf folgenden Monaten erst zeigen was alles läuft oder eben noch nicht. Da wirst du wohl noch ein Jahr mit deiner jetzigen Lösung herhalten müssen.Programmierung fertig ist.
Wir haben einen IT-Leiter, der das Programm auf dem Terminalserver erstmals installiert hatte.
Es war wohl seine Schwärzeste Entscheidung oder will euch kaputt machen Vorher lief es bei jedem Mitarbeiter lokal auf dem Rechner (damals noch mit Win XP). Da gab es keine Probleme.
Dann solltest du dir überlegen ob nicht der XP Mode bei euren Windows 7 Büchsen dir helfen kann. XP Mode ist Kostenlos erhältlich - bei MS direkt - inkl. XP Lizenz dazu. Das dürfte 1000 mal (geschätzt ) stabiler laufen als deine jetzige Frickelei und vor allem euren Daten zugute kommen. Evtl. würde ein TS ala Server 2003 (32 Bit) hier schon helfen, ein RDS auf Basis eines Server 2008 und dann Delphi / Borland BDE...... Da gibt es nicht die Frage ob Probleme auftreten können, da stellt sich nur die Frage wann und wie oft.Nun arbeiten hier alle mit Win 7
XP Mode von MS inkl. der XP Lizenz, oder sind das alles nur Win 7 Home.....Ob allerdings selbst ein TS auf Server 2003 da noch die Applikation sauber laufen lässt ist trotzdem höchst fraglich.
Gruß,
Peter
Prüfen ob die Hardware es tut
http://www.microsoft.com/en-us/download/details.aspx?id=592
XP Modus herunterladen
http://www.microsoft.com/de-de/download/details.aspx?id=8002
Wie es alles geht
http://windows.microsoft.com/de-de/windows7/install-and-use-windows-xp- ...
Würde es denn funktionieren, diesen XP-Rechner so ins Netzwerk einzubinden, dass er (quasi wie ein kleiner Server) den Zugriff von 5 - 7 Personen auf das Programm zuläßt?
Kann man, aber da stößt du vermutlich zu 99 % auf die gleichen Probleme wenn die Anwendung nicht für den gleichzetigen Zugriff auf die DB-Files ausgelegt wurden. Das ist sehr wahrscheinlich auch der Grund warum euch die DBs immer wieder um die Ohren fliegen ...
Hallo,
Meinst du allerdings das deine Benutzer auf den XP (Server) die GUI laufen lassen mit 5-7 Personen gleichzeitig? nein, XP kann auch per RDP nur immer eine Sitzung sprich einen Benutzer (Änderungen der Reg oder Hacks hier nicht angenommen). Da ist es doch effizienter wenn die GUI (Delphi) in einer Virtuellen XP Sitzung auf jeden Client (W7) läuft. Damit sollte deine GUI (Anwendung) sauber wieder arbeiten und deine Borland DBs sollten es auch.
Du kannst ja das XP (XP Mode) im Seamless Betrieb nutzen. Ist dann für die Benutzer transparent.
http://www.winfuture-forum.de/index.php?showtopic=189526
https://technet.microsoft.com/de-de/magazine/ff626489.aspx
http://blogs.technet.com/b/germanvirtualizationblog/archive/2009/10/07/ ...
http://blogs.technet.com/b/windows_vpc/archive/2009/08/27/three-modes-o ...
http://consciousvibes.com/wp/windows-7-xp-mode-creating-a-seamless-shor ...
Nutze deine Anwendung im klassischen Stil und deine Probleme dürften verschwinden...
Gruß,
Peter
Zitat von @37414:
Würde es denn funktionieren, diesen XP-Rechner so ins Netzwerk einzubinden, dass er (quasi wie ein kleiner Server) den Zugriff von 5 - 7 Personen auf das Programm zuläßt?
Wie meinst du dies? das 5-7 Benutzer dort auf die Borland DBs zugreifen von ihren eigenen Clients aus? Das geht sofern nicht mehr als 10 Connections aufgebaut werden welche der XP (Daten Server) dann bedienen muss. Ob deine Anwendung mit nur einer Verbindung pro Client auskommt, kann dir nur der Quellcode zeigen. Ich würd es nicht tun. Da ist ein Server OS oder selbst ein W7 besser. Server OS unbegrenzte Connections, W7 25 Connections. Ob deine Borland DBs allerdings mit den W7 klarkommt.... W7 ungleich XP, da sind doch etliche Änderungen die dort deine Borland DBs himmeln können. Daher auch XP oder Server 2003.Würde es denn funktionieren, diesen XP-Rechner so ins Netzwerk einzubinden, dass er (quasi wie ein kleiner Server) den Zugriff von 5 - 7 Personen auf das Programm zuläßt?
Meinst du allerdings das deine Benutzer auf den XP (Server) die GUI laufen lassen mit 5-7 Personen gleichzeitig? nein, XP kann auch per RDP nur immer eine Sitzung sprich einen Benutzer (Änderungen der Reg oder Hacks hier nicht angenommen). Da ist es doch effizienter wenn die GUI (Delphi) in einer Virtuellen XP Sitzung auf jeden Client (W7) läuft. Damit sollte deine GUI (Anwendung) sauber wieder arbeiten und deine Borland DBs sollten es auch.
Du kannst ja das XP (XP Mode) im Seamless Betrieb nutzen. Ist dann für die Benutzer transparent.
http://www.winfuture-forum.de/index.php?showtopic=189526
https://technet.microsoft.com/de-de/magazine/ff626489.aspx
http://blogs.technet.com/b/germanvirtualizationblog/archive/2009/10/07/ ...
http://blogs.technet.com/b/windows_vpc/archive/2009/08/27/three-modes-o ...
http://consciousvibes.com/wp/windows-7-xp-mode-creating-a-seamless-shor ...
Und... würde das auch mit einer Virtuellen Maschine funktionieren (also eine VM einfach auf einem unserer Server installieren mit XP)?
Klar kannst du eine VM mit XP installieren, nur der Benutzer muss dann per RDP oder VNC oder... darauf zugreifen um seinen Anwendung nutzen zu können, und du brauchst pro Anwender eine eigene VM (XP ungleich Multiuser).Nutze deine Anwendung im klassischen Stil und deine Probleme dürften verschwinden...
Gruß,
Peter
Hallo,
Und da gehen wird dann doch davon aus das deine Borland DBs auch dort auf einen Zentralen Server (FS) zu finden waren. (Klassisch halt)
Ob deine Borland DBs auf was anderes als XP/Server 2003 sauber laufen ist von vornherein nicht zu sagen. Dazu sind die Änderungen im OS zwischen Server 2003(R2) zu 2008/2012(R2) oder XP zu Win7 / Win8 / Win 10 einfach zu groß. Da hilft nur testen, tunen, testen, tunen, testen.....
An dem Verhalten deiner Anwendung (GUI) sowie der Borland DBs kannst du ohne Quellcode nichts ändern, also musst du eine Umgebung dafür schaffen. genau hierfür hat MS ja den XP Mode gemacht und auch dafür gesorgt das wer eine Win7 Prof. etc. hat auch eine Kostenlose XP Lizenz mit dem XP Mode (Vorinstalliert und Aktiviert) bekommt.
Gruß,
Peter
Zitat von @37414:
Bedeutet das, dass wir auf allen 5 oder 7 PC´s mit Windows 7 also den XP-Modus installieren sollten und dass dann in dieser virtuellen?? XP-Sitzung das Programm läuft? Die Datenbanken würden aber weiterhin (wie jetzt) auf dem Serverlaufwerk liegen... also auf unserem File-Server?
Ja, natürlich. Dann hast du das Konzept welches mit Delphi und der Borland DBs wieder hergestellt und damit sollten deine Probleme vom Tisch sein. Du hast ja selbst geschriebenBedeutet das, dass wir auf allen 5 oder 7 PC´s mit Windows 7 also den XP-Modus installieren sollten und dass dann in dieser virtuellen?? XP-Sitzung das Programm läuft? Die Datenbanken würden aber weiterhin (wie jetzt) auf dem Serverlaufwerk liegen... also auf unserem File-Server?
Vorher lief es bei jedem Mitarbeiter lokal auf dem Rechner (damals noch mit Win XP). Da gab es keine Probleme
Ob deine Borland DBs auf was anderes als XP/Server 2003 sauber laufen ist von vornherein nicht zu sagen. Dazu sind die Änderungen im OS zwischen Server 2003(R2) zu 2008/2012(R2) oder XP zu Win7 / Win8 / Win 10 einfach zu groß. Da hilft nur testen, tunen, testen, tunen, testen.....
An dem Verhalten deiner Anwendung (GUI) sowie der Borland DBs kannst du ohne Quellcode nichts ändern, also musst du eine Umgebung dafür schaffen. genau hierfür hat MS ja den XP Mode gemacht und auch dafür gesorgt das wer eine Win7 Prof. etc. hat auch eine Kostenlose XP Lizenz mit dem XP Mode (Vorinstalliert und Aktiviert) bekommt.
Gruß,
Peter
Hallo,
Auf dem System nach alten Logs und Protokollen suchen?
War es eine Inplace Migration dann kannst du vielleicht noch Ereignis Protokolle und Dateien / Ordner mit alten Zeit Stempel, MSInfo kann dir vielleicht das ursprünglichen Installationsdatum anzeigen (MSInfo | find /i "install date")
War es eine Migration auf neues Blech wird davon nichts zu finden sein.
Eventuell ist im AD noch was zu finden (ADSIEdit).....
Gruß,
Peter
Zitat von @37414:
Der IT-ler sagt, dass er nicht denkt, dass es am Terminalserver liegt, denn es habe darauf ja ca. 1,5 Jahre funktioniert (mit kaum Fehlern).
Was denn nun? Kaum Fehler oder wie von dir berichtet massive Fehler? Kaum Fehler = nicht weiter beachten, kommt mal vor oder wie von dir "unser System ist absolut instabil und unerträglich"?Der IT-ler sagt, dass er nicht denkt, dass es am Terminalserver liegt, denn es habe darauf ja ca. 1,5 Jahre funktioniert (mit kaum Fehlern).
wie kann ich das feststellen?
Eure Dokumentationen?Auf dem System nach alten Logs und Protokollen suchen?
War es eine Inplace Migration dann kannst du vielleicht noch Ereignis Protokolle und Dateien / Ordner mit alten Zeit Stempel, MSInfo kann dir vielleicht das ursprünglichen Installationsdatum anzeigen (MSInfo | find /i "install date")
War es eine Migration auf neues Blech wird davon nichts zu finden sein.
Eventuell ist im AD noch was zu finden (ADSIEdit).....
Gruß,
Peter
Moin zusammen,
den Fehler hier zu finden mit dem geringen Informationsumfang wird wohl kaum Erfolg bringen.
Da muss ein Debugger wie http://www.ollydbg.de/ zum Einsatz kommen mit dem man überprüft ob der Fehler nun am Programm selbst oder im Zusammenspiel mit dem OS herrührt (Assembler-Kenntnisse zwingend erforderlich).
Ansonsten bleibt dir nur Trial & Error und das Ausschlussprinzip.
Gruß jodel32
den Fehler hier zu finden mit dem geringen Informationsumfang wird wohl kaum Erfolg bringen.
Da muss ein Debugger wie http://www.ollydbg.de/ zum Einsatz kommen mit dem man überprüft ob der Fehler nun am Programm selbst oder im Zusammenspiel mit dem OS herrührt (Assembler-Kenntnisse zwingend erforderlich).
Ansonsten bleibt dir nur Trial & Error und das Ausschlussprinzip.
Gruß jodel32
Seit wann habt Ihr denn jetzt die Probleme?
Wurde etwas an der Konfiguration zu diesem Zeitpunkt geändert, an dem die Probleme auftraten?
Andere Hardware / Software / Updates......?
Habt Ihr evtl Einträge in der Ereignisanzeige?
Am einfachsten wäre es, wenn sich das jemand vor Ort mal anschauen könnte.
Lg Pago
Wurde etwas an der Konfiguration zu diesem Zeitpunkt geändert, an dem die Probleme auftraten?
Andere Hardware / Software / Updates......?
Habt Ihr evtl Einträge in der Ereignisanzeige?
Am einfachsten wäre es, wenn sich das jemand vor Ort mal anschauen könnte.
Lg Pago
Hallo,
Vermutlich sind eure Daten (die Borland DBs) mittlerweile so mit Fehlern verseucht das euer Programm (GUI) nicht mehr damit klarkommt und als folge dann Abstürze, Datenverlust usw. zum Tagesgeschäft werden.
Gruß,
Peter
Zitat von @37414:
Irgendwann fingen die Probleme dann an...
JoaIrgendwann fingen die Probleme dann an...
Mittlerweile haben wir häufig Probleme
Auch Joa.Vermutlich sind eure Daten (die Borland DBs) mittlerweile so mit Fehlern verseucht das euer Programm (GUI) nicht mehr damit klarkommt und als folge dann Abstürze, Datenverlust usw. zum Tagesgeschäft werden.
oder die Datenbanken reparieren
Wobei nichts Repariert werden kann wenn nichts kaputt ist. Wenn nur falsche Daten (auch Hieroglyphen) falsch sind kann und wird es euer Konstrukt Schreddern. Eine Datenbank Reparatur kann zwar Fehler beheben, aber nicht zwingend alle Daten auf Korrektheit prüfen und korrigieren.wobei oft unsere Memofelder (Textfelder im Programm) verloren gehen.
Es hat schon Gründe warum wir froh sind das die Borland DBs (BDE) nicht mehr so oft anzutreffen sind Gruß,
Peter
Hi!
Wenn man Paradox richtig konfiguriert, kann man es sehr wohl in Multiuserumgebungen verwenden. Bei älteren Delphi Versionen geschieht der Zugriff der Delphi Anwendung auf die Paradox Tabellen über die BDE (Borland Database Engine), wie es der Kollege oben schon erwähnt hat. Die BDE wurde standardmässig von Borland immer mit einem Konfigtool geliefert, mit der man den Multiuserbetrieb (idapi32.cfg) einstellen kann. Dazu wird für alle User ein gemeinsamer Pfad eingerichtet in dem die BDE dann eine Steuerdatei (paradoxusers.net) anlegt über die sie dann den Zugriff der einzelnen User auf die Tabellen regelt und z.B. offene bzw. in Bearbeitung befindliche Datensätze dann für alle anderen User sperrt. Wird diese Pfadeinstellung nicht vorgenommen sind Probleme quasi vorprogrammiert und zumeist werden die Paradox Tabellen im Endeffekt langfristig dadurch zerstört.
Da die BDE mit Datenbank-Aliasen arbeitet, könnte man theoretisch versuchen die Anfragen der Delphianwendung auf einen Datenbankserver (z.B. Interbase) umzuleiten aber ohne Quellcode ist das sicherlich zum Scheitern verurteilt.... ;-(
mrtux
Wenn man Paradox richtig konfiguriert, kann man es sehr wohl in Multiuserumgebungen verwenden. Bei älteren Delphi Versionen geschieht der Zugriff der Delphi Anwendung auf die Paradox Tabellen über die BDE (Borland Database Engine), wie es der Kollege oben schon erwähnt hat. Die BDE wurde standardmässig von Borland immer mit einem Konfigtool geliefert, mit der man den Multiuserbetrieb (idapi32.cfg) einstellen kann. Dazu wird für alle User ein gemeinsamer Pfad eingerichtet in dem die BDE dann eine Steuerdatei (paradoxusers.net) anlegt über die sie dann den Zugriff der einzelnen User auf die Tabellen regelt und z.B. offene bzw. in Bearbeitung befindliche Datensätze dann für alle anderen User sperrt. Wird diese Pfadeinstellung nicht vorgenommen sind Probleme quasi vorprogrammiert und zumeist werden die Paradox Tabellen im Endeffekt langfristig dadurch zerstört.
Da die BDE mit Datenbank-Aliasen arbeitet, könnte man theoretisch versuchen die Anfragen der Delphianwendung auf einen Datenbankserver (z.B. Interbase) umzuleiten aber ohne Quellcode ist das sicherlich zum Scheitern verurteilt.... ;-(
mrtux
mrtux hat recht, das duerfte kein Thema sein
desweiteren ist der xp mode fuer diese problematik wohl die beste loesung fuer den user ohne groessere veraenderungen an der it vornehmen zu muessen. bereits erfolgreich fuer aenliche probleme uebergangsweise eingesetzt. natuerlich sollte es etwas zentralisiert angegangen werden und die xp vms sollten keinen internetzugang erlauben
wg terminalserver wuerde ich eine testumgebung installieren der vielleicht eine frische 2008er umgebung ohne patches ist ist, um zu sehen ob man die fehler hier repeouzieren kann. bei multiuser betrieb natuerlich eher etwas schwierig
zu guter letzt gibt es ggf die moeichkeit des reverse engeneerings um die delphi anwendung wieder in quellcode umzuwandeln, und es ggf dann auf eine neuere delphi version zu portieren, ich habe damit keine schlechten erfahrungen gemacht, steht und faellt allerdings mit der komplexitaet des codes und ob fremdanbieter komponenten verwendet wurden.
herzl. gruss
alexander uhde
info@amc-it-services.de
desweiteren ist der xp mode fuer diese problematik wohl die beste loesung fuer den user ohne groessere veraenderungen an der it vornehmen zu muessen. bereits erfolgreich fuer aenliche probleme uebergangsweise eingesetzt. natuerlich sollte es etwas zentralisiert angegangen werden und die xp vms sollten keinen internetzugang erlauben
wg terminalserver wuerde ich eine testumgebung installieren der vielleicht eine frische 2008er umgebung ohne patches ist ist, um zu sehen ob man die fehler hier repeouzieren kann. bei multiuser betrieb natuerlich eher etwas schwierig
zu guter letzt gibt es ggf die moeichkeit des reverse engeneerings um die delphi anwendung wieder in quellcode umzuwandeln, und es ggf dann auf eine neuere delphi version zu portieren, ich habe damit keine schlechten erfahrungen gemacht, steht und faellt allerdings mit der komplexitaet des codes und ob fremdanbieter komponenten verwendet wurden.
herzl. gruss
alexander uhde
info@amc-it-services.de
Hi!
wie ich oben schon angemerkt hatte, ist auch das ohne den Quellcode quasi zum Scheitern verurteilt.
Es hängt weitest gehend davon ab wie der damalige Entwickler vorgegangen ist. Hat er seine Applikation so gestaltet, dass alle Datenbankobjekte (Abfragen, Tabellen, Felder) dynamisch, also erst zu Laufzeit generiert werden, besteht zumindest eine geringe Chance der Applikation über den BDE Alias eine neue Datenbank "unterzuschieben", denn dann werden auch Abweichungen in der Struktur quasi dynamisch übernommen. Allerdings muss dann die Datenbank-/Tabellen- Struktur offen sein, also z.B. nicht Passwort geschützt oder gar verschlüsselt in der Datenbank abgelegt sein, damit man die Struktur z.B. auf einen Datenbankserver "umziehen" könnte.
Hat der Entwickler jedoch die Datenbankobjekte zur Designzeit erstellt (leider meist die wahrscheinlichere Variante, da die Delphi-IDE das dann quasi automatisch selbst macht und der Entwickler sich viel Arbeit und Zeit spart) ist es quasi unmöglich der Applikation eine andere Datenbank unter zujubeln. Man würde beim Start der Applikation für jedes falsche Datenbankfeld einen Ausnahmefehler (Exception) bekommen. Des weiteren führen die meisten Entwickler beim Start der Applikation eine Prüfung der Datenbank bzw. Tabellenstruktur durch und vergleichen Abweichungen von der, bei der Entwicklung, festgelegten Struktur, die meist in der Form einer Version vorliegt und in der Applikation, in einer Konfigdatei oder in der Windows Registry bei der ersten Installation der Applikation hinterlegt wurde...
Also nochmal, meiner Ansicht nach wird das ohne Quellcode nicht klappen und wenn die Paradox Tabellen Passwort geschützt sind, kannst Du es gleich vergessen....
mrtux
wie ich oben schon angemerkt hatte, ist auch das ohne den Quellcode quasi zum Scheitern verurteilt.
Es hängt weitest gehend davon ab wie der damalige Entwickler vorgegangen ist. Hat er seine Applikation so gestaltet, dass alle Datenbankobjekte (Abfragen, Tabellen, Felder) dynamisch, also erst zu Laufzeit generiert werden, besteht zumindest eine geringe Chance der Applikation über den BDE Alias eine neue Datenbank "unterzuschieben", denn dann werden auch Abweichungen in der Struktur quasi dynamisch übernommen. Allerdings muss dann die Datenbank-/Tabellen- Struktur offen sein, also z.B. nicht Passwort geschützt oder gar verschlüsselt in der Datenbank abgelegt sein, damit man die Struktur z.B. auf einen Datenbankserver "umziehen" könnte.
Hat der Entwickler jedoch die Datenbankobjekte zur Designzeit erstellt (leider meist die wahrscheinlichere Variante, da die Delphi-IDE das dann quasi automatisch selbst macht und der Entwickler sich viel Arbeit und Zeit spart) ist es quasi unmöglich der Applikation eine andere Datenbank unter zujubeln. Man würde beim Start der Applikation für jedes falsche Datenbankfeld einen Ausnahmefehler (Exception) bekommen. Des weiteren führen die meisten Entwickler beim Start der Applikation eine Prüfung der Datenbank bzw. Tabellenstruktur durch und vergleichen Abweichungen von der, bei der Entwicklung, festgelegten Struktur, die meist in der Form einer Version vorliegt und in der Applikation, in einer Konfigdatei oder in der Windows Registry bei der ersten Installation der Applikation hinterlegt wurde...
Also nochmal, meiner Ansicht nach wird das ohne Quellcode nicht klappen und wenn die Paradox Tabellen Passwort geschützt sind, kannst Du es gleich vergessen....
mrtux
Hi!
mrtux
Zitat von @37414:
Ein erster Test eines Kollegen und von mir selbst verlief ohne Probleme.
Aber prüfe zur Absicherung nochmals die Einstellungen der BDE, denn wenn ihr dann von mehreren virtuellen Maschinen (XP-Modes) auf den selben Datenbestand zugreifen wollt, sollte zumindest der Parameter bezüglich der paradoxusers.net stimmen und auf allen VMs gleich sein, sonst wird es bald wieder Probleme geben....Ein erster Test eines Kollegen und von mir selbst verlief ohne Probleme.
mrtux