URALT-Access Datenbank Problem

[SubZero2002]

Hallo zusammen,

hab da einen Kunden, welcher eine makroprogrammierte Access-DB hat, welche mit Access 95(!) erstellt wurde. Der Programmierer dieser ist nicht mehr existent. Diese DB läuft auf einem eigens abkommandierten PC (uralt Hardware mit WinXP mit 512MB RAM und oftmals Macken) im Netzwerk.
Wollte diese DB im Access 2003 aktivieren, geht nicht!
Konvertieren passt nicht usw.
Habe eine Access-Runtime (Trixi) gefunden, installiert, DB gestartet ... siehe da, ein Lichtbick. Access 2003 erlaubt mal das öffnen. Komm auch auf die Startumgebung der DB, jedoch wenn z.b. Datensätze abgefragt werden, bzw. Kalenderdaten, oder Berichte drucken, etc. ... dann kommt sofort eine Fehlermeldung von VBA. Somit Problem!

Meine Frage: ist der VBA-Syntax von Access 95 zu Access 2003 verändert/aktualisiert worden?? Bzw. gibt's eine andere, einigermaßen komfortable Lösung die DB in Access 2003 vollständig zum Laufen zu bringen? Nacharbeiten, Fehlersuchen ist imho unbezahlbar.

Hat jemand von Euch ähnliche Access Probleme in der Vergangenheit gehabt und einen brauchbare Lösung gefunden?

Wenn, dann schon jetzt vielen, vielen Dank im Voraus!!!

cu
Sz2k2

[Atomschwammerl]

wenn du so wenig wie möglich aufwand haben möchtest dann portier das ding in eine VM auf einen neuen server, damit wenigstens die Hardware stabil rennt.
Weil ohne Code debuggen wirst wohl kaum auskommen.
Hab mal ein VBA tool für office 2003 und 2007 geschrieben, da gibts auch schon einige funktionen die nicht in beiden versionen funktionieren.

[wbendl]

Hi!

Konkret kann ich bestätigen, daß der Sprung von Access 95 zu 97 Probleme mit dem Kalendersteuerelement brachte. Der Code mußte angepaßt werden. (Auch bei Excel gabe es Probleme.)

Für mich war das damals der Grund zum Verzicht auf Access. Ich habe zu VB6 gewechselt.

Wenn die Aktualisierung des Codes nicht in Frage kommt, stimme ich Atomschwammerl zu. Eine VM mit Access 95 verwenden.


mfg

WB

[SubZero2002]

Hallo zusammen,

vorerst vielen Dank für Eure Infos!

Zitat von Atomschwammerl

wenn du so wenig wie möglich aufwand haben möchtest dann portier das ding in eine VM auf einen neuen server, damit wenigstens die Hardware stabil rennt.
Weil ohne Code debuggen wirst wohl kaum auskommen.
Hab mal ein VBA tool für office 2003 und 2007 geschrieben, da gibts auch schon einige funktionen die nicht in beiden versionen funktionieren.

Was genau meinst mit VM (VM-Ware?), hab vergessen zu erwähnen, die DB ist ein Frontend/Backend.
VM-Ware auf den Clients installieren, in der VM-Umgebung das Office95 einbinden? JA, Du hast recht mit dem Code debuggen. Das ist unpackbar!

So ich eine akzeptable Lösung find, poste ich's.

cu
Sz2k8

[wbendl]

Hi!

VM muß nicht unbedingt VM-Ware sein. Da gibt es mehrere kostenlose Programme (sogar auch von MS).


mfg

WB

[Atomschwammerl]

Ich versteh nicht wie man auf die Idee kommt aufwändige Datenbank applikationen mit MS Office zu lösen....

Naja es ist passiert, da bleibt wohl nichts anderes übrig als:

a) bei MS Access zu bleiben und und auf eine aktuelle version migrieren Hoher debugg aufwand!! und sicherlich bei nächsten update wieder debuggen

b) einen Programmierer anzuheuern und alles auf z.b. eine Webapplication mit SQL datenbank zu migrieren.

c) Mit allen mitteln versuchen bei Access 95 zu bleiben. Möglicherweise mit "Kompatibilitäts modus von Windows" Oder mittels Virtueller Maschiene in der diese Application läuft

Darfst du vieleicht das Frontend rausgeben?
Würd mir gerne mal ansehen wie aufwändig das ding ist, um abschätzen zu können wieviel aufwand es wäre das zu migrieren oder neu zu schreiben. lg

[SubZero2002]

Zitat von Atomschwammerl

Ich versteh nicht wie man auf die Idee kommt aufwändige Datenbank applikationen mit MS Office zu lösen....

Naja es ist passiert, da bleibt wohl nichts anderes übrig als:

a) bei MS Access zu bleiben und und auf eine aktuelle version migrieren Hoher debugg aufwand!! und sicherlich bei nächsten update wieder debuggen

b) einen Programmierer anzuheuern und alles auf z.b. eine Webapplication mit SQL datenbank zu migrieren.

c) Mit allen mitteln versuchen bei Access 95 zu bleiben. Möglicherweise mit "Kompatibilitäts modus von Windows" Oder mittels Virtueller Maschiene in der diese Application läuft

Darfst du vieleicht das Frontend rausgeben?
Würd mir gerne mal ansehen wie aufwändig das ding ist, um abschätzen zu können wieviel aufwand es wäre das zu migrieren oder neu zu schreiben. lg

Hallo Atomschwammerl,

ich bin mit Dir einer Meinung, im Bezug auf Access (95).Datenbanken mit ca. 2000 Akten (Datensätze) sind für Access nicht mal privat tauglich.
Bitte sei nicht enttäuscht, wenn ich das Frontend (nützt dir ohne Backend nix, geht nicht auf) nicht schick, da wir uns nicht kennen, Datenschutz usw.
Ich les des öfteren im Forum, dein Synonym ist mir aufgefallen, hast gute Lösungsansätze für das eine oder andere Problemchen parat.
Auf der DB sind Klienten-Daten eines RA.

Wie man auf die Idee kam sowas mal mit Access zu "basteln" ... weiß ich nicht, SQL z.b. gibt's auch schon a paar Tage.
Hab versucht mit einem Konverter (access zu sql) konvertieren ... bricht irgendwann mit einem fehler (genau welchen weiß ich adhoc nicht) ab ...
Montag bin ich wieder vor Ort, versprochen hab ich nix. Muss mit dem Chef mal ein ernstes Gespräch führen ;-)

Vielen Dank für deine Tipps und Deine Zeit

cu

[wbendl]

Hi!

Ich würde schon versuchen, die Fehler zu beheben. Nach meiner Einschätzung dürfte es nicht allzu viele Änderungen geben.

Noch ein Nachtrag zu meinem 1. Beitrag:
Die damals von 95 auf 97 aktualisierte Anwendung funktioniert problemlos mit 2003.

Die angesprochene Lösung mit den VMs funktioniert sicher. Allerdings gibt es eine kleinen Haken: Jede VM braucht eine eigene Lizenz (Win + Office). Das wird mit der Zahl der Clients eventuell nicht realisierbar.

Langfristig sollte das Frontend auf jeden Fall ohne Access auskommen. Das Backend könnte wohl bleiben, ist aber leicht aufe eine andere Plattform zu bringen.


mfg

WB

[FranzK]

Zitat von SubZero2002

...
ich bin mit Dir einer Meinung, im Bezug auf Access (95). Datenbanken mit ca. 2000 Akten (Datensätze) sind für Access nicht mal privat tauglich.

Also bitte. Das halte ich für äußerst übertrieben. Bei 200.000 Datensätzen würde ich dir vielleicht schon zustimmen...

Wie man auf die Idee kam sowas mal mit Access zu "basteln" ... weiß ich nicht, SQL z.b. gibt's auch schon a paar Tage.

Solche Dinge sind oft gewachsene Lösungen. Und ca. 1995 war die Auswahl an Windows-fähigen Datenbanksystemen noch verhältnismäßig klein und relativ kostspielig (und einige davon sind in der zwischenzeit wieder vom Markt verschwunden).
Und was soll die Bemerkung mit SQL? Eine ordentlich programmierte Access-Anwendung wird auch nichts anderes verwenden...

[FranzK]

Zitat von wbendl

....
Langfristig sollte das Frontend auf jeden Fall ohne Access auskommen. Das Backend könnte wohl bleiben, ist aber leicht aufe eine andere Plattform zu bringen.
...

Das sehe ich eigentlich umgekehrt. Es wird kaum wirklich schwierig sein, das Projekt auf eine neuere Access-Platform zu übertragen. Danach kann man das Backend auf SQL-Server-Express wechseln und noch lange mit Access als Frontend leben...

Das Frontend tauschen und mit der Jet-Engine weiter arbeiten vereinigt nur den größeren Aufwand beim Wechsel mit den bestehenden Nachteilen der Datenbank...