13
dBase DOS Programm / Datenbank nach Access Migrieren / Konvertieren
Hallo,
im Grunde genommen habe ich das selbe Problem wie der Autor dieses Beitrags:
Programme aus dBase nach was auch immer...
ich muss eine dBase Datenbank sammt der Dos Aplikation nach MS Access Migrieren!
Wie kann ich da am besten rann gehen? Gibt es dBase -> Access Konverter / Migratoren?
vll. kennt sich ja jemand aus
Ich freue mich auf sämtliche antworten
mit freundlichen Grüßen
Dave
im Grunde genommen habe ich das selbe Problem wie der Autor dieses Beitrags:
Programme aus dBase nach was auch immer...
ich muss eine dBase Datenbank sammt der Dos Aplikation nach MS Access Migrieren!
Wie kann ich da am besten rann gehen? Gibt es dBase -> Access Konverter / Migratoren?
vll. kennt sich ja jemand aus
Ich freue mich auf sämtliche antworten
mit freundlichen Grüßen
Dave
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 48726
Url: https://administrator.de/contentid/48726
Ausgedruckt am: 24.11.2024 um 12:11 Uhr
13 Kommentare
Neuester Kommentar
Moin daveChristopher,
das ist eine Frage, bei der man/frau etwas weiter ausholen müsste.
Und sich vorsichtig ausdrücken muss, um sich keine Unterlassungsklagen wegen übler Nachrede einzufangen.
Meine Kurzfassung [Meinung, nicht Lösungsskizze]:
- Ja, es gab und gibt Migrationswerkzeuge, die dBaseIII/Clipper-Applikationen nach Access (oder VB+SQL-Server oder sogar Delphi) portieren bzw. wort-wörtlich übersetzen.
- Nein, das Ergebnis kannst Du niemandem anbieten.
Je nachdem wie professionell die jetzige vorhandene xBase-Logik ist, hast Du letzten Endes drei Alternativen:
1) ein Tool wie Clip4Win (falls es die noch gibt?) einsetzen.
Dann wird aus der bestehenden unter dBase laufenden Applikation eine eigenständige Win32.exe. Die 25-Zeilen x 80-Spalten-DOS-Darstellung bleibt, wie sie ist.
Die DOS-Meldungen werden auf Wunsch zu Windows-Messageboxen aufgepeppt und die Applikation läuft in einem Fenster statt im Vollbildmodus.
Ergebnis: die jagen Dich vom Hof.
2) DBF-Dateien in eine Access-*.mdb importieren und Programmlogik der *.prg-Dateien unter VBA oder mit den Formularassistenten neu schreiben.
3) DBF-Dateien in eine beliebige SQL-Datenbank Access importieren und Programmlogik der *.prg-Dateien mit irgendeinem Client/Frontend-Tool ( Java, PHP, .NET, VB...) neu schreiben.
Ob Variante 2 oder 3 hängt davon ab, ob das ganze perspektivisch als einzelne Insel-Lösung standalone auf einem Rechner oder bedient von mehreren Mitarbeitern parallel in einem Netzwerk oder irgendwann als Client/Server-3-Tier-Applikation laufen soll.
Wenn es eine nur noch eine befristet laufende Applikation zum Lesen/Auswertungen von Alt-Daten, zum Beispiel eine "alte" Artikel/Auftragsverwaltung sein sollte, dann gibt es auch noch Möglichkeit:
4) Lass die Applikation wie sie ist auf einem Rechner im DOS-Kompat-Modus laufen oder schlimmstenfalls auf einem separaten PC.
Was ich bei Bedarf anbieten kann: ich kann Dir nach Sichtung der bestehenden xBase-Applikation sagen, ob sich eine Migration (=1:1 Übernahme von Algorithmen/Prozessimplementierung und Programmlogik) lohnt oder ob ihr diesen Aufwand lieber in die Lasten-/Pflichtenheft-Erstellung für eine Neu-Entwicklung stecken solltet.
Bei Bedarf PN senden.
Genau dasselbe hätte ich auch Psycho Dad geantwortet, wenn ich seinen Beitrag vorher gesehen hätte.
Gruß
Biber
das ist eine Frage, bei der man/frau etwas weiter ausholen müsste.
Und sich vorsichtig ausdrücken muss, um sich keine Unterlassungsklagen wegen übler Nachrede einzufangen.
Meine Kurzfassung [Meinung, nicht Lösungsskizze]:
- Ja, es gab und gibt Migrationswerkzeuge, die dBaseIII/Clipper-Applikationen nach Access (oder VB+SQL-Server oder sogar Delphi) portieren bzw. wort-wörtlich übersetzen.
- Nein, das Ergebnis kannst Du niemandem anbieten.
Je nachdem wie professionell die jetzige vorhandene xBase-Logik ist, hast Du letzten Endes drei Alternativen:
1) ein Tool wie Clip4Win (falls es die noch gibt?) einsetzen.
Dann wird aus der bestehenden unter dBase laufenden Applikation eine eigenständige Win32.exe. Die 25-Zeilen x 80-Spalten-DOS-Darstellung bleibt, wie sie ist.
Die DOS-Meldungen werden auf Wunsch zu Windows-Messageboxen aufgepeppt und die Applikation läuft in einem Fenster statt im Vollbildmodus.
Ergebnis: die jagen Dich vom Hof.
2) DBF-Dateien in eine Access-*.mdb importieren und Programmlogik der *.prg-Dateien unter VBA oder mit den Formularassistenten neu schreiben.
3) DBF-Dateien in eine beliebige SQL-Datenbank Access importieren und Programmlogik der *.prg-Dateien mit irgendeinem Client/Frontend-Tool ( Java, PHP, .NET, VB...) neu schreiben.
Ob Variante 2 oder 3 hängt davon ab, ob das ganze perspektivisch als einzelne Insel-Lösung standalone auf einem Rechner oder bedient von mehreren Mitarbeitern parallel in einem Netzwerk oder irgendwann als Client/Server-3-Tier-Applikation laufen soll.
Wenn es eine nur noch eine befristet laufende Applikation zum Lesen/Auswertungen von Alt-Daten, zum Beispiel eine "alte" Artikel/Auftragsverwaltung sein sollte, dann gibt es auch noch Möglichkeit:
4) Lass die Applikation wie sie ist auf einem Rechner im DOS-Kompat-Modus laufen oder schlimmstenfalls auf einem separaten PC.
Was ich bei Bedarf anbieten kann: ich kann Dir nach Sichtung der bestehenden xBase-Applikation sagen, ob sich eine Migration (=1:1 Übernahme von Algorithmen/Prozessimplementierung und Programmlogik) lohnt oder ob ihr diesen Aufwand lieber in die Lasten-/Pflichtenheft-Erstellung für eine Neu-Entwicklung stecken solltet.
Bei Bedarf PN senden.
Genau dasselbe hätte ich auch Psycho Dad geantwortet, wenn ich seinen Beitrag vorher gesehen hätte.
Gruß
Biber
Hallo,
wahnsinn danke für deine antwort!
"2) DBF-Dateien in eine Access-*.mdb importieren und Programmlogik der *.prg-Dateien unter VBA oder mit den Formularassistenten neu schreiben."
so habe ich mir das auch gedacht... Aber in wie weit muss das "neu geschrieben" werden? Ich kenne mich mit VBA (noch) nicht gut aus! Und den Code Konvertieren in VBA geht wahrscheinlich auch nicht so einfach oder?
Oder wie hätte diese Lösung im Detail für dich ausgeschaut?
"Was ich bei Bedarf anbieten kann: ich kann Dir nach Sichtung der bestehenden xBase-Applikation sagen, ob sich eine Migration (=1:1 Übernahme von Algorithmen/Prozessimplementierung und Programmlogik) lohnt oder ob ihr diesen Aufwand lieber in die Lasten-/Pflichtenheft-Erstellung für eine Neu-Entwicklung stecken solltet.
Bei Bedarf PN senden."
mit 1:1 Übernahme meinst du dann wahrscheinlich die benutzung eines Migrationstools oder?
Ich bin gerade nicht im Geschäft versuche aber so bald wie möglich dir die Applikation (ohne Datenbankdateien ^^) zu senden!
Ich danke dir für deine Hilfe nämlich ich muss zugeben das es schon eine schwierigere Aufgabe ist!
Viele Grüße
Dave
wahnsinn danke für deine antwort!
"2) DBF-Dateien in eine Access-*.mdb importieren und Programmlogik der *.prg-Dateien unter VBA oder mit den Formularassistenten neu schreiben."
so habe ich mir das auch gedacht... Aber in wie weit muss das "neu geschrieben" werden? Ich kenne mich mit VBA (noch) nicht gut aus! Und den Code Konvertieren in VBA geht wahrscheinlich auch nicht so einfach oder?
Oder wie hätte diese Lösung im Detail für dich ausgeschaut?
"Was ich bei Bedarf anbieten kann: ich kann Dir nach Sichtung der bestehenden xBase-Applikation sagen, ob sich eine Migration (=1:1 Übernahme von Algorithmen/Prozessimplementierung und Programmlogik) lohnt oder ob ihr diesen Aufwand lieber in die Lasten-/Pflichtenheft-Erstellung für eine Neu-Entwicklung stecken solltet.
Bei Bedarf PN senden."
mit 1:1 Übernahme meinst du dann wahrscheinlich die benutzung eines Migrationstools oder?
Ich bin gerade nicht im Geschäft versuche aber so bald wie möglich dir die Applikation (ohne Datenbankdateien ^^) zu senden!
Ich danke dir für deine Hilfe nämlich ich muss zugeben das es schon eine schwierigere Aufgabe ist!
Viele Grüße
Dave
Hallo,
Du hast Dir da aber wirklich was aufgebürdet!
Die Daten nach Access zu bekommen geht ja noch so halbwegs. Wobei einige der dbf-Feldtypen in Access detaillierter unterschieden werden (z. B. ein dbf-Feld "N" kann in Access Integer, Long Integer, Double, etc. sein).
Aber den Code zu übersetzen ist eine andere Sache. Denn das einzig Gemeinsame ist bei den beiden Sprachen, daß sie mit Daten umgehen. Der Lösungsansatz ist jedoch ein komplett anderer. Das fängt beim Datezugriff an und hört bei der Objektorientierung von Access-Code nicht auf. Und wenn Du noch nie mit Access gearbeitet hast, wie Du sagst: Ich hoffe, Du kannst wenigstens OOP! Aus eigener leidvoller Erfahrung als ursprünglicher dBase- und Clipper-Programmierer kann ich Dich ansonsten nämlich von ganzem Herzen nur bemittleiden.
Aber warum muss es denn unbedingt Access sein? Geht nicht auch eine andere Windows-Datenbank? Es gibt genügend Programme, wo Du den dbase-Code mehr oder weniger 1:1 übernehmen kannst. Und Du Dich in die Tiefen der Windows-Programmierung nachträglich einarbeiten kannst. Als da wären dBASE Plus, Xbase++, Visual Foxpro, um nur die wichtigsten zu nennen.
Jan
Du hast Dir da aber wirklich was aufgebürdet!
Die Daten nach Access zu bekommen geht ja noch so halbwegs. Wobei einige der dbf-Feldtypen in Access detaillierter unterschieden werden (z. B. ein dbf-Feld "N" kann in Access Integer, Long Integer, Double, etc. sein).
Aber den Code zu übersetzen ist eine andere Sache. Denn das einzig Gemeinsame ist bei den beiden Sprachen, daß sie mit Daten umgehen. Der Lösungsansatz ist jedoch ein komplett anderer. Das fängt beim Datezugriff an und hört bei der Objektorientierung von Access-Code nicht auf. Und wenn Du noch nie mit Access gearbeitet hast, wie Du sagst: Ich hoffe, Du kannst wenigstens OOP! Aus eigener leidvoller Erfahrung als ursprünglicher dBase- und Clipper-Programmierer kann ich Dich ansonsten nämlich von ganzem Herzen nur bemittleiden.
Aber warum muss es denn unbedingt Access sein? Geht nicht auch eine andere Windows-Datenbank? Es gibt genügend Programme, wo Du den dbase-Code mehr oder weniger 1:1 übernehmen kannst. Und Du Dich in die Tiefen der Windows-Programmierung nachträglich einarbeiten kannst. Als da wären dBASE Plus, Xbase++, Visual Foxpro, um nur die wichtigsten zu nennen.
Jan
Ohhhhh ja da habe ich mir wirklich was aufgehalzt... 
Wäre denn eine migration in eine andere Windows Datenbank einfacher? Wie sieht es mit einer SQL Datenbank aus?
Was gibt es für Konventierungstools für dbase nach dBASE Plus, Xbase++, Visual Foxpro?
Welche Methode - möglichst die einfachste ^^ - würdest du mir raten?
Viele Grüße
David
Wäre denn eine migration in eine andere Windows Datenbank einfacher? Wie sieht es mit einer SQL Datenbank aus?
Was gibt es für Konventierungstools für dbase nach dBASE Plus, Xbase++, Visual Foxpro?
Welche Methode - möglichst die einfachste ^^ - würdest du mir raten?
Viele Grüße
David
Hallo David,
die Datenübernahme ist einfach. Alle drei Programme können nämlich Deine Daten "einfach so" lesen. Ohne Konvertierung. Auch wenn sie andere, verbesserte Formate auch unterstützen.
dBASE Plus ist leider nur auf englisch erhältlich, könnte also eventuell ein Problem sein. VFP und Xbase++ gibt es auch auf deutsch, mit jeweils einer starken deutschen Community. Wo man auch mal ohne dumm aufzufallen Newbie-Fragen stellen kann. Xbase++ ist ein deutsches Programm, infos unter www.alaska-software.com. Das (inoffizielle) deutsche Forum findest Du unter www.xbaseforum.de, daneben gibt es stapelweise Newsgroups, eine davon auch auf deutsch. Infos über VFP gibt es hier: www.dfpug.de (das steht für Deutsche VoxPro UserGroup). Offiziell ist Foxpro vom Microsoft. Ich habe aber so das Gefühl, daß die damit seit einigen Jahren nicht mehr viel zu tun haben möchten. Ich glaube, der treibende Motor sind die Usergroups, wobei die deutsche anscheinend federführend ist.
SQL ist sowohl mit Xbase++ als auch mit VFP möglich. Allerdings kann ich sagen, daß zumindest Xbase++ auch im Netz sehr gut ohne SQL klarkommt, sehr schnell und sicher. Wobei natürlich SQL ganz klare Vorteile bietet. Die aber nicht jeder wirklich braucht. Xbase++ bietet außerdem eine sehr gute Unterstützung von ADS von Advantage, was eine sehr günstige Alternative ist gegenüber den kommerziellen und üblicherweise sehr teuren SQL-Datenbanken.
Ich selber arbeite übrigens (neben Access) mit Xbase++.
Jan
die Datenübernahme ist einfach. Alle drei Programme können nämlich Deine Daten "einfach so" lesen. Ohne Konvertierung. Auch wenn sie andere, verbesserte Formate auch unterstützen.
dBASE Plus ist leider nur auf englisch erhältlich, könnte also eventuell ein Problem sein. VFP und Xbase++ gibt es auch auf deutsch, mit jeweils einer starken deutschen Community. Wo man auch mal ohne dumm aufzufallen Newbie-Fragen stellen kann. Xbase++ ist ein deutsches Programm, infos unter www.alaska-software.com. Das (inoffizielle) deutsche Forum findest Du unter www.xbaseforum.de, daneben gibt es stapelweise Newsgroups, eine davon auch auf deutsch. Infos über VFP gibt es hier: www.dfpug.de (das steht für Deutsche VoxPro UserGroup). Offiziell ist Foxpro vom Microsoft. Ich habe aber so das Gefühl, daß die damit seit einigen Jahren nicht mehr viel zu tun haben möchten. Ich glaube, der treibende Motor sind die Usergroups, wobei die deutsche anscheinend federführend ist.
SQL ist sowohl mit Xbase++ als auch mit VFP möglich. Allerdings kann ich sagen, daß zumindest Xbase++ auch im Netz sehr gut ohne SQL klarkommt, sehr schnell und sicher. Wobei natürlich SQL ganz klare Vorteile bietet. Die aber nicht jeder wirklich braucht. Xbase++ bietet außerdem eine sehr gute Unterstützung von ADS von Advantage, was eine sehr günstige Alternative ist gegenüber den kommerziellen und üblicherweise sehr teuren SQL-Datenbanken.
Ich selber arbeite übrigens (neben Access) mit Xbase++.
Jan
@JanX
Es gibt Tage, da wünsche ich mir die Bewertungsfunktion zurück...--> Klasse Antwort!
Nur ergänzend dazu meine (sicherlich subjektiven) Fussnoten:
@David:
Ist-Zustand der (ja vielleicht 20 Jahre alten !!!) DOS-Applikation prüfen - was leistet diese Applikation?
100% Zufriedenheit? Eher 70%? Oder nur: "Haben wir schon immer so gemacht..."?
Inwieweit sind die Anforderungen denn tatsächlich dieselben wie vor 20 Jahren?
Und wenn genau diese Anforderungen haargenau so wie damals immer noch existieren - nachschauen, ob ihr in irgendeine Zeitschleife geraten seid (siehe "Und täglich grüßt das Murmeltier..").
Die Einschätzung zu Visual Fox teile ich - ist ein ungeliebtes Kind und wird nicht strategisch positioniert.
Deshalb: Wenn Du merkst, dass Du ein totes Pferd reitest: Steig ab.
Aber auch xBase++ ist ein Exot (auch wenn man/frau nur Gutes über alaska-software sagen kann).
Da mit hoher Wahrscheinlichkeit zu erwarten ist, dass die vorhandenen (und künftig erfassten) Daten auch weiterhin verarbeitet/ausgetauscht/exportiert werden sollen, wäre schon ein Killer-Kriterium die vorhandene/fehlende Programmunabhängigkeit der Daten.
Oder anders ausgedrückt: hat denn normalerweise jedes handelsübliche SQL-Client einen Treiber für das künftige DB-Format dabei/kann ich die Daten OHNE dazugehörige Applikation problemlos lesen?
Die reizvollen Features mit "starker deutschsprachiger Community" etc. sind in Deinem Fall offensichtlich absolut untergeordnet, da das Erstellen einer Applikation wohl ein einmaliger Kraftakt werden wird: eine laufende Pflege und Weiterentwicklung Eurer Applikation stand jahrzehntelang auf keinem Zettel.
Dann wird die nächsten Jahre auch kein massiver Knowhow-Aufbau zur Applikationsentwicklung nötig sein.
Ein vorgegebenes DB-System ins Lastenheft schreiben, Angebote einholen, Auftrag für die Umstellung inklusive Datenmigration/-konvertierung zum Festpreis und Festtermin vergeben,
fertig.
Eine Eigenentwicklung auf Deinen Schultern ist IMHO unkalkulierbar, wenn Du weder Erfahrungen in Clipper/dBASE noch in M$-Access und auch nicht mit SQL hast.
Gruss Biber
Es gibt Tage, da wünsche ich mir die Bewertungsfunktion zurück...--> Klasse Antwort!
Nur ergänzend dazu meine (sicherlich subjektiven) Fussnoten:
@David:
Welche Methode - möglichst die einfachste ^^ - würdest du mir raten?
> Redesign. Bedarf ermitteln. Und nur bei vorhandenem Bedarf umstellen.Ist-Zustand der (ja vielleicht 20 Jahre alten !!!) DOS-Applikation prüfen - was leistet diese Applikation?
100% Zufriedenheit? Eher 70%? Oder nur: "Haben wir schon immer so gemacht..."?
Inwieweit sind die Anforderungen denn tatsächlich dieselben wie vor 20 Jahren?
Und wenn genau diese Anforderungen haargenau so wie damals immer noch existieren - nachschauen, ob ihr in irgendeine Zeitschleife geraten seid (siehe "Und täglich grüßt das Murmeltier..").
Die Einschätzung zu Visual Fox teile ich - ist ein ungeliebtes Kind und wird nicht strategisch positioniert.
Deshalb: Wenn Du merkst, dass Du ein totes Pferd reitest: Steig ab.
Aber auch xBase++ ist ein Exot (auch wenn man/frau nur Gutes über alaska-software sagen kann).
Da mit hoher Wahrscheinlichkeit zu erwarten ist, dass die vorhandenen (und künftig erfassten) Daten auch weiterhin verarbeitet/ausgetauscht/exportiert werden sollen, wäre schon ein Killer-Kriterium die vorhandene/fehlende Programmunabhängigkeit der Daten.
Oder anders ausgedrückt: hat denn normalerweise jedes handelsübliche SQL-Client einen Treiber für das künftige DB-Format dabei/kann ich die Daten OHNE dazugehörige Applikation problemlos lesen?
Die reizvollen Features mit "starker deutschsprachiger Community" etc. sind in Deinem Fall offensichtlich absolut untergeordnet, da das Erstellen einer Applikation wohl ein einmaliger Kraftakt werden wird: eine laufende Pflege und Weiterentwicklung Eurer Applikation stand jahrzehntelang auf keinem Zettel.
Dann wird die nächsten Jahre auch kein massiver Knowhow-Aufbau zur Applikationsentwicklung nötig sein.
Ein vorgegebenes DB-System ins Lastenheft schreiben, Angebote einholen, Auftrag für die Umstellung inklusive Datenmigration/-konvertierung zum Festpreis und Festtermin vergeben,
fertig.
Eine Eigenentwicklung auf Deinen Schultern ist IMHO unkalkulierbar, wenn Du weder Erfahrungen in Clipper/dBASE noch in M$-Access und auch nicht mit SQL hast.
Gruss Biber
Hallo Biber,
danke für die Blumen
Ich muß mich übrigens korrigieren: dBASE plus gibt es doch auf deutsch.
Bei dem "Feature" starke deutsche Community muß ich Dir aber widersprechen (jedenfalls aus meiner Sicht): WENN man schon eine mehr oder weniger neue Sprache lernt, dann doch meist nicht nur mal für ein Projekt. Und selbst wenn das so wäre, dann ist eine gute Unterstützung wichtig, um überhaupt einen guten Einstieg zu finden.
Bei den Einschätzungen zu VFP und xBase++ muß ich Dir recht geben, auch wenn ich wie erwähnt selber mit xBase++ arbeite; es ist in der Tat ungerechtfertigterweise ein Nischenprodukt. Der von Dir angesprochene Punkt war letztendlich auch der Grund, warum das in die letzte Auswahl gekommene VFP bei mir doch nicht zum Zuge gekommen ist.
Und die beiden letzten Sätze/Absätze kann ich nur unterschreiben. Absolut korrekt. Wenn David das nicht als Herausforderung sehen sollte, auf diesem Weg etwas tolles Neues zu lernen. Dazu darf das Projekt aber als Einstiegsaufgabe hierzu nicht zu groß sein. Sonst ist der Frustfaktor schnell und groß.
Jan
danke für die Blumen
Ich muß mich übrigens korrigieren: dBASE plus gibt es doch auf deutsch.
Bei dem "Feature" starke deutsche Community muß ich Dir aber widersprechen (jedenfalls aus meiner Sicht): WENN man schon eine mehr oder weniger neue Sprache lernt, dann doch meist nicht nur mal für ein Projekt. Und selbst wenn das so wäre, dann ist eine gute Unterstützung wichtig, um überhaupt einen guten Einstieg zu finden.
Bei den Einschätzungen zu VFP und xBase++ muß ich Dir recht geben, auch wenn ich wie erwähnt selber mit xBase++ arbeite; es ist in der Tat ungerechtfertigterweise ein Nischenprodukt. Der von Dir angesprochene Punkt war letztendlich auch der Grund, warum das in die letzte Auswahl gekommene VFP bei mir doch nicht zum Zuge gekommen ist.
Und die beiden letzten Sätze/Absätze kann ich nur unterschreiben. Absolut korrekt. Wenn David das nicht als Herausforderung sehen sollte, auf diesem Weg etwas tolles Neues zu lernen. Dazu darf das Projekt aber als Einstiegsaufgabe hierzu nicht zu groß sein. Sonst ist der Frustfaktor schnell und groß.
Jan
Hallo,
ich danke euch für die antworten!!!
also ich MUSS diese Migration machen... komme was wolle!
Um das ganze mal auf den Punkt zu bringen:
Wie soll ich jetzt vorgehen um das Programm (das in seinen Funktionen so bleiben soll) in ein aktuelles Format zu bekommen?
Sprich:
- Welche Migrationstools soll ich verwenden?
- Wie soll ich diese verwenden?
- Welche Datenbank soll ich verwenden?
- Worunter soll die Applikation nun laufen?
Viele Grüße und tausend Dank
David
ich danke euch für die antworten!!!
also ich MUSS diese Migration machen... komme was wolle!
Um das ganze mal auf den Punkt zu bringen:
Wie soll ich jetzt vorgehen um das Programm (das in seinen Funktionen so bleiben soll) in ein aktuelles Format zu bekommen?
Sprich:
- Welche Migrationstools soll ich verwenden?
- Wie soll ich diese verwenden?
- Welche Datenbank soll ich verwenden?
- Worunter soll die Applikation nun laufen?
Viele Grüße und tausend Dank
David
Moin David,
was für Voraussetzungen hast Du denn? Hast Du Access? Wenn Du nicht nach Access umsteigen kannst/willst: Wie groß ist Dein Budget für eine neue Software?
Du hast gesagt daß Du kein VBA kannst. Kannst Du denn dBase? Darüber hast Du noch garnichts gesagt.
Was für einen Zeitrahmen hast Du?
Wie groß ist das ganze Projekt (Codezeilen, Datenbanken, Netzwerk, Fremdtools, etc.)?
Ohne diese Infos ist Deine Frage nicht so ganz einfach zu beantworten.
Jan
was für Voraussetzungen hast Du denn? Hast Du Access? Wenn Du nicht nach Access umsteigen kannst/willst: Wie groß ist Dein Budget für eine neue Software?
Du hast gesagt daß Du kein VBA kannst. Kannst Du denn dBase? Darüber hast Du noch garnichts gesagt.
Was für einen Zeitrahmen hast Du?
Wie groß ist das ganze Projekt (Codezeilen, Datenbanken, Netzwerk, Fremdtools, etc.)?
Ohne diese Infos ist Deine Frage nicht so ganz einfach zu beantworten.
Jan
VBA ist begrenzt vorhanden! Ich habe Access! Budget gibt es bis jetzt keines!
Zeitrahmen ist etwa bis ende sommer!
Codezeilen - Kann ich leider noch nichts zu sagen! Da ich mit dem Projekt erst mitte des Jahres anfange und ich erst in der "Vorbereitung" bin
Datenbanken - dBase
Netzerk - so viel ich weiß läuft das programm nur lokal
Framdtools - keine!
Ich hätte mir vorgestellt das es vll. ein einfaches Migrationstool gebe, wo man das alte dBase programm einfach auf eine aktuelle Plattform migrieren kann! Es muss ja erstmal nicht alles 100ig klappen aber halt das man erstmal eine Grundlage zum "weiterarbeiten" hat! ;)
Viele Grüße
David
Zeitrahmen ist etwa bis ende sommer!
Codezeilen - Kann ich leider noch nichts zu sagen! Da ich mit dem Projekt erst mitte des Jahres anfange und ich erst in der "Vorbereitung" bin
Datenbanken - dBase
Netzerk - so viel ich weiß läuft das programm nur lokal
Framdtools - keine!
Ich hätte mir vorgestellt das es vll. ein einfaches Migrationstool gebe, wo man das alte dBase programm einfach auf eine aktuelle Plattform migrieren kann! Es muss ja erstmal nicht alles 100ig klappen aber halt das man erstmal eine Grundlage zum "weiterarbeiten" hat! ;)
Viele Grüße
David
Hallo David,
ach du Schande! Ende Sommer fertig, den Code bekommst Du erst Mitte des Jahres? Vergiss es!!! Das funktioniert nie im Leben!
Wie Biber ganz am anfang schon gesagt hat: Vergiss jegliche Art von Migrationstools. Das gibt nur Müll. Das Problem liegt darin, das Access nicht einfach nur Codebasiert ist. Es gibt Formulare, da kannst Du Dir mit der Mauis die Bildschirme zusammenstellen und noch mit Code verfeinern. Es gibt berichte, das sind die Ausdrucke. Ebenfalls mit der Maus zusammenstellen und mit Code verfeinerbar. Dazu gibt es dann Module, das ist Code pur, der ganz allgemein für das Projekt notwendig ist. Und wenn alle Stricke reißen muß Du noch Abfragen erstellen.
Und all das ist in dBase anders. Du musst also das ganze Teil von Grund auf neu schreiben. Kannst Dich zwar an der alten Logik orientieren um die Vorgenesweise der Datenzusammenstellung nicht noch einmal zu erfinden. Must aber, wenn die Datenzugriffe halbwegs ordentlich und flott gehen sollen, SQL lernen. Zumindest rudimentär.
Das Du die dBase-Datenbanken in Access ünbermehmen kannst ist dabei nicht das große Problem. Wobei Du die Indizee von Hand erstellen musst, aber auch das ist kein großes Problem.
Wobei Du die Frage mit den Datenbanken falsch verstanden hattest Es ist klar, daß das dBase ist. Ich wollte wissen, wie umfangreich und wie viele.
Aber um zum Anschluß zu kommen: Wer immer Dir das Projekt aufs Auge gedrückt hat: Sag ihm, daß das unter diesen Bedingungen nicht geht!
Wobei es immer auch darauf ankommt, was Ihr damit erreichen wollt. Geht es einfach nur um 32 Bit? Oder soll da eine GUI eingebaut werden? Braucht Ihr eine exe? Wenn Ihr einfach nur 32 Bit braucht: Kauft Euch dBASE Plus. Da laufen die alten dBase-Programme ohne jedes Umschreiben drucnter, Und Ihr könnt Euch nachher überlegen, wie Ihr das auf Windos GUI umschreibt. Kostet in der 1Platz-Version inkl. DOS-Unterstützung 730 € netto (www.dbase-systems.de). Deswegen die Frage nach dem Budget.
Jan
ach du Schande! Ende Sommer fertig, den Code bekommst Du erst Mitte des Jahres? Vergiss es!!! Das funktioniert nie im Leben!
Wie Biber ganz am anfang schon gesagt hat: Vergiss jegliche Art von Migrationstools. Das gibt nur Müll. Das Problem liegt darin, das Access nicht einfach nur Codebasiert ist. Es gibt Formulare, da kannst Du Dir mit der Mauis die Bildschirme zusammenstellen und noch mit Code verfeinern. Es gibt berichte, das sind die Ausdrucke. Ebenfalls mit der Maus zusammenstellen und mit Code verfeinerbar. Dazu gibt es dann Module, das ist Code pur, der ganz allgemein für das Projekt notwendig ist. Und wenn alle Stricke reißen muß Du noch Abfragen erstellen.
Und all das ist in dBase anders. Du musst also das ganze Teil von Grund auf neu schreiben. Kannst Dich zwar an der alten Logik orientieren um die Vorgenesweise der Datenzusammenstellung nicht noch einmal zu erfinden. Must aber, wenn die Datenzugriffe halbwegs ordentlich und flott gehen sollen, SQL lernen. Zumindest rudimentär.
Das Du die dBase-Datenbanken in Access ünbermehmen kannst ist dabei nicht das große Problem. Wobei Du die Indizee von Hand erstellen musst, aber auch das ist kein großes Problem.
Wobei Du die Frage mit den Datenbanken falsch verstanden hattest
Es ist klar, daß das dBase ist. Ich wollte wissen, wie umfangreich und wie viele.Aber um zum Anschluß zu kommen: Wer immer Dir das Projekt aufs Auge gedrückt hat: Sag ihm, daß das unter diesen Bedingungen nicht geht!
Wobei es immer auch darauf ankommt, was Ihr damit erreichen wollt. Geht es einfach nur um 32 Bit? Oder soll da eine GUI eingebaut werden? Braucht Ihr eine exe? Wenn Ihr einfach nur 32 Bit braucht: Kauft Euch dBASE Plus. Da laufen die alten dBase-Programme ohne jedes Umschreiben drucnter, Und Ihr könnt Euch nachher überlegen, wie Ihr das auf Windos GUI umschreibt. Kostet in der 1Platz-Version inkl. DOS-Unterstützung 730 € netto (www.dbase-systems.de). Deswegen die Frage nach dem Budget.
Jan
...und nur als winzige Ergänzung:
Lasst jemand draufgucken, der etwas von der Sache versteht!
Also der dBase/Clipper mindestens fliessend lesen kann und der auch (meinetwegen mt Access, wenn ihr keine richtige Datenbank braucht) schon mal mehr als als eine Schallplattensammlungs- oder Weinkeller-Verwaltung zusammengeschrotet hat.
Im Zweifelsfall: www.gelbeseiten.de
[Ist weder gehässig noch sarkastisch gemeint].
Gruss
Biber
Lasst jemand draufgucken, der etwas von der Sache versteht!
Also der dBase/Clipper mindestens fliessend lesen kann und der auch (meinetwegen mt Access, wenn ihr keine richtige Datenbank braucht) schon mal mehr als als eine Schallplattensammlungs- oder Weinkeller-Verwaltung zusammengeschrotet hat.
Im Zweifelsfall: www.gelbeseiten.de
[Ist weder gehässig noch sarkastisch gemeint].
Gruss
Biber
Hallo Biber,
den Vorschlag hätte ich auch gemacht (ich würde mich dafür auch anbieten, hattest Du ja auch schon gemacht). Nur, wenn David das ganze erst im Sommer bekommt, dann ist jede Diskussion in diese Richtung im Moment rein philosophisch.
Aber prinzipiell ist das natürlich korrekt. Ohne gesehen zu haben, was da auf David zukommt, ist jede Aussage vage. Deswegen hatte ich ja auch nach Details gefragt. Die David aber nun einmal leider noch nicht hat.
Jan
den Vorschlag hätte ich auch gemacht (ich würde mich dafür auch anbieten, hattest Du ja auch schon gemacht). Nur, wenn David das ganze erst im Sommer bekommt, dann ist jede Diskussion in diese Richtung im Moment rein philosophisch.
Aber prinzipiell ist das natürlich korrekt. Ohne gesehen zu haben, was da auf David zukommt, ist jede Aussage vage. Deswegen hatte ich ja auch nach Details gefragt. Die David aber nun einmal leider noch nicht hat.
Jan
