Office: (Office 2003) Konvertierung ACCESS 2003 nach 2010

Hallo,

in unserer Firma soll in den nächsten Monaten Office 2010 ausgerollt werden.
Hat schon jemand Erfahrungen mit dieser Problematik und kann mir sagen, was da auch mich zu kommt?
Meine Datenbanken enthalten relativ viel VBA-Code.
Als Backend dient eine SQL-Server 2008-DB.
Die DB wird via einem Link auf unserem Sharepoint von einem Netzlaufwerk und einem Database-Loader gestartet. Das macht ja schon jetzt einige Probleme, wie z.B. das doppelte Öffnen des FE aufgrund dieser dämlichen Sicherheitswarnung, die trotz eines Zertifikats nicht weg zu bekommen ist.

Gruß

cheapy

:)

 

Hallo,
im Code bin bisher auf 3 Probleme gestoßen.
1. Funktion CreateDatabase(..) mit Parameter dbEncrypt verlangt zusätzliche Angabe von dbVersion40

2. Befehle wie CreateObject("Access.Application.11") muss umgestellt werden auf die 14.

3. Application.FileSearch geht nicht mehr. Ersatzcode für Filesearch findest du im Netz.

Wenn du auf SQL-Server umstellst wird es zwingend dass alle Recordset mit den Parametern dbOpenDynaset und dbSeeChanges versehen werden.

Gruß Andreas

 

Hallo Andreas,

die drei von Dir aufgelisteten Punkte dürften mich nicht treffen. Kann mich jedenfalls nicht erinnern so etwas im dem (recht umfangreichen) Code zu haben.
Die Anbindung von SQL-Server als BE ist ja schon lange realisiert.
Was mir Kopfschmerzen bereitet ist, dieses neue Sicherheitsfeature beim Starten einer DB von einem Netzlaufwerk. So wie es jetzt läuft, kann ich die DB nicht einmal starten, weil es mir von MS untersagt wird.
Sicherheit hin- oder her, die DB soll von einem Netzlaufwerk in unserem Firmennetz geöffnet werden, wieso besitzt Microsoft die Frechheit mir das zu untersagen? Nur weil man kostenpflichtige Zertifikate unters Volk bringen will?
Oder gibt es für diesen Unsinn eine Umgehung?

Gruß

cheapy

 

Hallo,
§1: du sollst jedem User ein Frontend geben
Dein Argument kann ich nicht teilen, Microsoft liefert doch eine kostenlose Clientsoftware, die nennt sich "Runtime-Version" *wink.gif*

Gruß Andreas

 

Es ist immer wieder schon zu lesen, woran MS schuld ist. *biggrin.gif*

@cheapy: Welches Sicherheitsfeature meinst du?
Falls du die vertrauenswürdigen Speicherorte meinst: die sollte die IT sogar über die Gruppenrichtlinien für alle betroffenen User einstellen können - falls die IT das nicht will, ist natürlich auch wieder MS daran schuld. *wink.gif*

Warum erstellst du nicht ein kleine .net-Exe, mit der du die DB aus der Html-Seite startest? Dann hättest du vermutlich das Problem mit dem Aufrufen einer DB aus deiner Sharepoint-Seite nicht mehr.

mfg
Josef

 

Hallo Andreas,

es hat jeder User ein Frontend!
Auf dem Netzlaufwerk wird "lediglich" ein Database-Loader gestartet, der überprüft, ob auf dem Netzlaufwerk eine aktuellere Version der Datenbank (FE) liegt.
Ist das der Fall, wird diese zunächst auf den PC des jeweiligen Users geladen und dann wird das FE auf dem PC des Users gestartet.
Ist die Version auf dem User-PC aktuell, wird diese natürlich sofort gestartet.

Die Bedingung ist also erfüllt.
WG. Runtime-Version schaue ich mal. Danke für den Tipp!


Gruß

cheapy

 

Hallo Josef,

zu:

So etwas habe ich noch nie gemacht, wo gibt's ne Anleitung dazu?

... und was die "Schuldfrage" betrifft, mit ACCESS 2003 funktioniert es ja, wer ausser MS hat es denn dann geändert?

 

Ich würde Dir empfehlen, dieses "Version prüfen und neue Version installieren" nicht über eine separate DB zu lösen.
Entweder macht das die DB wirklich selbst oder es gibt einen "Wrapper" der das übernimmt.
Das kann eine kleine *.exe oder ein Script sein.

Für die Scriptlösung habe ich hier 2 Beispiele gezeigt
Diese lieft und läuft für verschiedene DBs problemlos.

Zum Thema "Sicherheitsfeature" kann ich Josef nur zu 100% zustimmen *wink.gif*

 

Es wird ja nicht nur die DB-Version überprüft, es werden auch weitere Dateien auf den USER-PC-Kopiert. Welche das sind, wo die liegen usw. steht in einer Tabelle, deshalb die Lösung via DB.
Wenn es dafür einen besseren Ansatz gibt, immer her damit.

Vielen Dank für die Scripts, leider habe ich beide Programmiersprachen noch nie benutzt.
Da die Datenbank sowohl direkt auf dem User-PC als auch über Terminal-Server (Citrix) laufen können muss und ich im 2. Fall über ein anderes Laufwerk arbeiten muss, hab ich doch leider gewisse Schwierigkeiten mit diesen Scripts zu arbeiten.
Auch wenn Ihr es nicht hören wollt, das Problem gibt es nur, weil MS mir Änderungen aufzwingt!

 

Informationen aus einer Tabelle können z.B. auch in einer Steuerdatei (XML) liegen die wiederum von einer *.exe oder einem Script verarbeitet werden kann.
Auch ist es möglich aus einem Script heraus auf die Tabelle zuzugreifen (Stichwort ADO).

Ohne konkrete Informationen über das wie und was kann ich nur Tipps geben; und die Themen wurden ja schon mehrfach behandelt; ggf. die Forumssuche bemühen.

 

Fehlende Informationen?
Reicht das hier:

• In der Datenbank gibt es eine Tabelle, die die aktuelle Versionsnummer enthält. Die wird durch die "Loader-DB" ausgelesen und mit der Version der DB auf dem Server verglichen.
• Fehlt die DB auf dem User-PC, wird das Zielverzeichnis, wenn nötig erstellt und mit den Dateien und Programmen die in einer Tabelle in der "Loader-DB" eingetragen sind, gefüllt.
• Ist das Verzeichnis vorhanden aber die DB-Version passt nicht, werden nur die Dateien, also auch die DB in das entsprechende Verzeichnis kopiert.
• Default liegt das Verzeichnis auf Laufwerk C: wurde die Loader-DB in der Citrix-Umgebung gestartet muss ein anderes Laufwerk, abhängig von der Konfiguration, gewählt werden.
• Zuletzt wird die DB aus dem jeweils gültigen Verzeichnis (abhängig on lokaler Start oder Citirx) gestartet.

Wie gesagt, ich habe bisher weder php noch diese Scriptsprache genutzt, deshalb auch die Verwendung der "Loader-DB".

 

Ich sehe in Deinen obigen Ausführungen jetzt keine weiteren Informationen die aus der Tabelle ausgelesen werden.

Letztlich machen die oben verlinkten Scripte genau das was Du beschreibst.
Eine LoaderDB sehe ich nach wie vor nicht als notwendig.