Datenbank-Applikation: Umstellung ?

[Pudel17]

Hi,

nein, ich bin kein Programmierer - trotzdem hab' ich vor mehr als 20 Jahren eine Branchenlösung entwickelt: ein Mietobjekteverwaltungsprogramm, d.h. relationales Datenbanksystem zur Verwaltung von Kunden, Mietobjekten, die beinhält: Mietobjekteverwaltung, Rechnungsschreibung, automatische Mieterhöhung entsprechend Index, Mieterhöhungsbriefe, .... mehrmandantenfähig, netzwerkfähig ... die Dateien der Datenbank liegen auf einem Linux-Server ... also das volle Programm.

Ich hab' das damals in Foxpro geschrieben (erst unter DOS, später auf VFP 6.0 umgestellt), es hat mich summasummarum sicher 1 MJ gekostet - und die Branchenlösung arbeitet immer noch zur vollsten Zufriedenheit. Sogar auf Win7-Rechnern hab' ich es zum Laufen gebracht. Soweit zur Ausgangsbasis.

----

Ich frag' mich: was nun langfristig? Bei Foxpro bleiben, eventuell auf die letzte Version 9.0 updaten - und alles so lassen, wie es ist? Oder mal in den sauren Apfel zu beißen und auf aktueller SW neu bauen? PostgreSQL auf dem Linux-Server mit irgend einem (welchem?) GUI?

Ich hätt' da natürlich noch eine Idee, die Angelegenheit ein wenig zu erweitern (eine kleine Termin-/Auftragsverwaltung dazu zu bauen) - noch im alten Foxpro (da würd' ich mich schon auskennen)? Oder doch auf neuer Plattform (alles Neuland für mich!!!)? Welcher?

D.h.: welchen Weg geh' ich am besten?

Thx & lG

 

[lynxx]

Never change a running system?

Frag Dich doch erstmal, macht es Sinn die Anwendung auf eine neue Umgebung zu portieren, doch eigentlich nur wenn der Funktionumfang derart erweitert werden soll das dass alte System dazu nicht mehr in der Lage wäre, oder die verwendeten Strukturen zu unflexibel für zukünftige Anforderungen sein werden.

Rechenleistung spielt bei diesem Anwendungsfall wohl keine Rolle, so das es selbst auf einem emuliertem System noch schnell genug wäre.

Was Du tun kannst ist das bestehenden System nochmal durchzugehen und auf eventuelle Fehlerfälle überprüfen und evtl. Dokumentation nachpflegen.

Ich weiss nicht wie gut Du selbst Deine alten Quelltexte lesen kannst, aber 20 Jahre alt wird Dich sicher an einigen Stellen dazu bringen Dich selbst zu fragen warum Du etwas so gelöst hast.

Ein komplettes neuschreiben in einer modernen Umgebung und Sprache (z.B Java, C#) würde ich vom Aufwand nicht unterschätzen, es würde die Erweiterbarkeit/Portierung aber deutlich vereinfachen und zudem eine frische GUI verpassen.

Andere Entwickler gehen aber eher den Weg bestehendes nicht zu ändern, so basieren z.B die von Brokat entwickelten Online-Banking-Applikationen im Kern immer noch auf BTX !

 

[AlbertLast]

Naja ich kenne nicht FoxPro,
beschäftige mich im rahmen meiner Bachelorarbeit mit PostgreSQL.

Auf frontend ebene hast du dort ansich die freiewahl,
gibt bestimmt auch anwender gui um das man auch leute die sich mit datenbank nicht auskennen
dransetzen kann, nur ist mir keiner bekannt.
Prinzipel hast du als Schnittstellen wie jdbc möglichkeit java programme ran zu hängen,
über odbc kannst du excel und word usw mit postgresql verbinden und jede
andere programmier sprache bietet auch irgendeine verbindungsmöglichkeit.

Auf der db Seite kann man mächtige sachen machen wenn man es braucht nur ist dafür fachwissen von nöten.
Also man kann mehr als nur in Postgresql die daten ablegen (Fk,Check Constraint,Unique, Proceduren usw).

 

[2fastHunter]

Naja eine einfache GUI für unerfahrene Anwender und für keine all zu große DB bietet auch Access. Als Programmierer rate ich aber davon ab ^^
Normalerweise sieht eine normale DB-Anwendung heute so aus: DB->OR-Mapper->Anwendungslogik->GUI
Ein aktueller OR-Mapper wie z.B. Hibernate kann mit quasi jeder SQL-DB. Da ist es dann der Fantasie und des Geldbeutels des Kunden überlassen welches System er sich zulegt. Hibernate gibt es derzeit für mindestens Java und .Net. Dann kann man in Java oder C# z.B. eine Desktopanwendung bauen oder man nimmt sich für Java den Tomcat oder C# den IIS und baut gleich eine Webanwendung draus.
Bücher und Tutorials gibt es zu hauf. Das kostet aber eine Menge Zeit. Ob das sinnvoll ist kann dir wohl keiner so genau sagen

 

[Pudel17]

Never change a running system? Frag Dich doch erstmal, macht es Sinn die Anwendung auf eine neue Umgebung zu portieren, doch eigentlich nur wenn der Funktionumfang derart erweitert werden soll das dass alte System dazu nicht mehr in der Lage wäre, oder die verwendeten Strukturen zu unflexibel für zukünftige Anforderungen sein werden....

Tja - genau das frag' ich mich. Laufen tut's gut. Ich mach' mir halt da noch folgende Gedanken: ich bin z.Z. der einzige Mensch weit und breit, der in der Lage ist, kleine Änderungen in der Anwendung durchzuführen, d.h. sie zu warten. Und die App. soll mal meinem Nachwuchs helfen, das Geschäft weiter zu führen.

Nur: wer wartet das Ding dann, wenn mir mal ein Stein am Kopf fällt?

Ich kann nicht abschätzen, wofür mein Nachwuchs in xx Jahren notfalls leichter jemand findet, der da eine Kleinigkeit anpasst:

• für die Foxpro-App. einen Foxpro-Kundigen (ev. über die Foxpro-Usergroup)
• oder einen, der sich in der App. auskennt, wenn PostgreSQL + Hibernate + Java oder C# verwendet werden.

Zu diesem Thema hab' ich noch gefunden: >Forumsbeitrag im Foxpro-Forum, Antwort #3<. Wenn - wie der Autor dort schreibt - die App. so lange läuft, wie auch 32-Bit-Systeme von M$ unterstützt werden, dann seh' ich z.Z. wenig Grund, alles umzustellen. Vor allem bin ich mir nicht sicher, ob sich notfalls ein Fremder dann dann besser auskennen würde.

Oder vielleicht hat mein Nachwuchs mehr Chancen sich notfalls in Foxpro einzuarbeiten (weil da nur 1 Programmiersprache mitspielt) als den Durchblick in PostgreSQL + Hibernate + Java oder C# zu erhalten.

Thx

 

[AlbertLast]

Wie ich schon oben geschrieben, muss du beim db wechsle,
denn du überlegst vorzunehmen, nicht unbedingt gleich mit der keule
alles machbaren zuschlagen.

So ist es auch möglich über odbc auch die vorhanden ms produkte an die db
anzuschließen wozu auch access gehört womit formular einfach basteln kannst.

 

[Pudel17]

Also nach reiflicher Überlegung glaub' ich jetzt doch, dass es gescheiter ist, beim alten FoxPro zu bleiben bzw. es auf die letzte Version zu portieren - wenn das Ding läuft, dann läuft es. Und zwar von der Datenbank über die SQL-Abfragen bis zum Rechnungsdruck - und das alles in einem Programm. Mittlerweile sehe ich es als Vorteil, dass zur gesamten Applikation nur ein Programm notwendig ist.

Anders ausgedrückt: wenn man mehrere Werkzeuge (PostgreSQL, Hybernate, ...) für eine Applikation verwendet, so fürchte ich, dass die Sache komplizierter und fehleranfälliger wird.

Ich denke, ich werde mir für die langen Winternächte die letzte FoxPro-Version besorgen, portieren, Fehler ausbessern und nachdokumentieren.

Thx