dBase III + TcxGrid und damit rechnen ?

[terra]

Zitat:

Du scheinsrt dich aber so auf Access eingeschossen zu haben, dass du dich mit den Alternativen nicht wirklich beschäftigen willst.

Das ist so nicht ganz richtig. Mir fehlt aber im Moment die Zeit dazu. Und jetzt nochmal das ganze Projekt zu überarbeiten, damit es auf Firebird läuft wäre zu Zeitaufwändig.

Ich lasse mich gerne eines besseren belehren. Garkeine Frage! Nur muss ich mich auch damit erst beschäftigen und wissen, wie man damit arbeitet. Bei Access habe ich ja jetzt meine Erfahrungen gemacht und kann damit einigermaßen mit umgehen. Auch, wenn ich dabei noch nicht alles verstehe aber es geht vorran.

Zumal kommt das Problem mit der Datenbankübername hinzu. Wir haben Kunden, die z.B. gerne ein altes Programm, das sie benutzt haben - neu haben möchten. Wie z.B. mein aktuelles Projekt für ein Optiker. Die haben bis jetzt mit einem Uralt Programm gearbeitet das an die guten alten DOS Zeiten erinnert. :D Das einzige Programm, was schnell und anständig die alte dBase DB übernommen hat war halt Access (ich weiß, Excel öffnet es auch). Darum bin ich halt darauf hengen geblieben. Zumal möchte ich auch die aktuelle DB Passwort schützen, damit da kein Kunde rumfummeln kann. Hatte es schon erlebt, das jemand darin rumgemacht hat und danach natürlich garnichts mehr ging.

Wie gesagt. Ich bin nicht stur auf etwas ausgerichtet und lasse mir nichts sagen. Nur für eine Umstellung brauche ich einen triftigen Grund und natürlich auch Zeit um ein Programm zu entwickeln.

Terra

[mkinzler]

Mit einer entsprechender DataPump bekommst du dBase Daten in jedes DBMS. Aber das ist imho schon der erste Fehler, denn dBase Daten aus alten Programmen haben selten eine richtig normalisierte Struktur.
Übernimmst man diese Daten 1:1 übernimmt man auch diese "Fehler". Ich würde in einem solchen Fall die Struktur analysieren und diese dann optimieren und an die neue Features neuerer DBMS anpassen und dann eine Übernhameroutine schreiben, mit der ich die Datn in die neue Struktur bekomme.

Diesen Aufwand würde ich auch treiben, denn so äuft das Programm später mit großer Wahrscheinlichkeit besser.

[terra]

Zitat:

Ich würde in einem solchen Fall die Struktur analysieren und diese dann optimieren...

Das böse Access 2007 hat mir da schon sehr geholfen. :-D
Ne, im ernst. Also sowas mache ich grundsätzlich vorher, da alle Daten natürlich auch zuletzt wieder passen müssen. Habe ja gesehen das es bei dBase anscheinend keine AutoID gab. Zumindest war nichts davon in dem aktuellen Projekt zu sehen. Macht ja nichts, es war ja jetzt außerdem mein erstes Projekt was mit dBase gearbeitet hat. Schlimmer noch ist, das das alte Optiker Programm mit sagenhaften 50 einzelnen Datenbank-Dateien gearbeitet hat, die jetzt schön in einer einzigen Access DB eingepflegt wurden. ;)

Terra

[mkinzler]

Dass spricht aber für eine vorhandene Normalisierung

[p80286]

[QUOTE=terra;1045165]

Zitat:

..Das einzige Programm, was schnell und anständig die alte dBase DB übernommen hat war halt Access (ich weiß, Excel öffnet es auch)...

Aus eigener leidvoller Erfahrung, solange Access sich mit kleinen (ca 65000 Datensätzen) Datenbeständen beschäftigt ist es durchaus brauchbar, wenn man sich einen Überblick verschaffen will. Sollen die Ergebnisse zuverlässig sein, kann ich nur von ACCESS abraten. (Sortierung unvollständig / nicht alle Datensätze aus Abfrage ausgegeben etc.) Langfristig lohnt sich die Einarbeitung in FB oder ein anderes "echtes" DBMS.

Gruß
K-H