Mein Daddy hat mir vor langer Zeit erklärt, man könne Scotch nicht mit Bourbon mixen. Wissen Sie was? Er hatte recht. Und im gleichen Sinn (oder Geist? <s>) gibt es etwas anderes, das man nicht mischen kann: Jet-Versionen, wenn es um replizierte Anwendungen geht.
Viele Leute gehen in einer durchaus traditionellen Weise vor, wenn Sie auf eine neue Access-Version umsteigen: Sie belassen das Backend noch für einige Zeit in der alten Version, damit das Frontend nicht überall sofort in die neue Version konvertiert werden muss. Dabei kann man das Backend sogar in einer 2.x-Version von Jet belassen, während das Frontend bei einigen Anwendern mit Jet 3.x läuft.
Wenn Sie jedoch von Jet 3.x /3.5x auf Jet 4.x wechseln, wird das nicht funktionieren, falls das Backend ein Replikat ist.
Warum nicht? Denken Sie daran, dass alles, was Sie in einer replizierten DB machen, durch den Jet Tracking Layer "überwacht" wird, der dafür sorgt, dass jede Änderung, die Sie vornehmen, bei der Synchronisierung richtig an andere Replikate weitergegeben wird. Dieser Tracking Layer liest die Schemata aus den Replikations-Systemtabellen und weiß, was er zu tun hat, um Änderungen mitzuführen.
Der Tracking Layer merkt sich jedoch nicht vollständig alle Versionen und wie die Änderungen weiterzugeben sind. Er macht das nur für die aktuelle Version. Deshalb kann eine Anwendung, die Jet 4.0 verwendet (wie Access 2000, DAO 3.6 oder der Jet OLE-DB Provider 4.0) keine Datenänderungen in einem Jet 3.x- oder Jet 3.5x-Replikat vornehmen; Wenn sie das täte, würde sich die replizierte Anwendung immer stärker von der Replikatgruppe unterscheiden, weil immer mehr vorgenommene Änderungen nicht an andere Replikate weitergegeben werden könnten.
Wenn man mit DAO versucht, Daten zu ändern, hinzuzufügen oder zu löschen bringt das den Laufzeitfehler 3703: "Vorgang wird für replizierbare Datenbanken, die nicht in die aktuelle Version konvertiert wurden, nicht unterstützt."
Versuchen Sie z.B. den folgenden Code auf einer Maschine laufen zu lassen, auf der es sowohl Jet 3.5 als auch Jet 4.0 gibt:
Sub foo()
Dim dbe As Object
Dim db As Object
Dim tdf As Object
Dim fld As Object
Dim prp As Object
Dim rs As Object
Set dbe = CreateObject("DAO.DBEngine.35")
Set db = dbe.CreateDatabase("c:\temp\test.mdb", _
";LANGID=0x0409;CP=1252;COUNTRY=0")
Set tdf = db.CreateTableDef("Table1")
Set fld = tdf.CreateField("Field1", 10, 255)
tdf.Fields.Append fld
db.TableDefs.Append tdf
Set prp = db.CreateProperty("Replicable", 10, "T")
db.Properties.Append prp
db.Close
Set db = Nothing
Set dbe = Nothing
Set dbe = CreateObject("DAO.DBEngine.36")
Set db = dbe.OpenDatabase("c:\temp\test.mdb")
Set rs = db.OpenRecordset("Table1")
rs.AddNew
rs!Field1 = "test data"
rs.Update
rs.Close
Set rs = Nothing
db.Close
Set db = Nothing
Set dbe = Nothing
End Sub
Sie werden den Laufzeitfehler beim rs.AddNew erhalten. Das gleiche passiert bei Edit oder Delete, oder beim Versuch Aktionsabfragen auszuführen etc. Die Daten sind grundsätzlich schreibgeschützt.
Daher können Sie aus drei Varianten wählen:
1) Führen Sie mit dem Backend einen Upgrade nach Jet 4.0 durch.
2) Belassen Sie es in 3.5, aber führen Sie alle Arbeiten, für das Update der DB per Programmierung durch, entweder mit DAO 3.5 (unter Verwendung von CreateObject wie o.a.) oder mit dem 3.5 Jet OLE DB Provider (dabei haben Sie noch den Bonus, dass Sie Formular-Recordsets verwenden können, weil sie Jet OLE DB Recordsets akzeptieren, sogar vom 3.5 Provider).
3) Machen Sie keinen Upgrade, weder mit Frontend noch Backend.