Tweet
Hallo geschätzte SE's,
ich habe hier ein Migrationsproblem, zu dem ich Euere Hilfe erhoffe.
Ich erarbeitete vor einigen Jahren eine Client-Server-Lösung mit einer SQL-Server 7 - DB als Backend und Access 2000 - Project (.adp bzw .ade) als Frontend. Die Client-Plattformen waren NT 4.0 WS bzw. W2k (immer mit MDAC 2.5). Alles lief jahrelang "bestens", bis ich mir eines Tages mit einer Dritt-Software hier und da MDAC-Upgrades auf 2.8 einhandelte. Plötzlich wurden Views, die konzeptionell immer editierbar waren, read-only insofern Sie auf mehr als 2 Tabellen fußten. Ich umging das Problem, indem ich das MDAC-Update zurückdrehte (auf NT 4.0 WS, auf W2k ist mir das nicht gelungen).
Nun steht allerdings die Migration der Client-Systeme zu Vista ins Haus, und da kommt eine 2.8-kompatible MDAC-Version 6.irgendwas mit, um die kein "walk-around" herum führt.
Nach tieferem Eindringen in die Materie, stellte sich heraus, das das Problem von in den Tabellen enthaltenen Timestamp-Feldern herrührt. Abhängig von der Position der Tabelle in der Join-Kette gelingt es, nach entfernen nur eines Timestamp-Feldes den beabsichtigten Zustand der Editierbarkeit der View wiederherzustellen.
Recherchen zum Sinn der Timestamp-Felder, die im Zusammenhang der Upsize-Operation von der früheren Access 2.0 - Anwendung her automatisch jeder Tabelle zugefügt wurden, ergaben, dass sie der schnellen und sicheren Erkennung von konkurrierenden Satzänderungen dienen und das ihr Fehlen in Tabellen mit Gleitkommafeldern wegen der differierenden internen Darstellung solcher Datentypen in Access bzw. SQL Probleme der Gestalt hervorrufen kann, dass Access dann immer einen konkurrierenden Netzwerkzugriff diagnostiziert, auch wenn niemand anders an dem Datensatz geändert hat.
Ich würde daher ungern Timestamp-Felder entfernen, da der Umfang der Anwendung schlecht erahnen lässt, welche Probleme mir daraus erwachsen.
Hat jemand Erfahrung mit derart gelagerten Problemen oder sonst hilfreiche Informationen zum Thema?
wom0659
ich habe hier ein Migrationsproblem, zu dem ich Euere Hilfe erhoffe.
Ich erarbeitete vor einigen Jahren eine Client-Server-Lösung mit einer SQL-Server 7 - DB als Backend und Access 2000 - Project (.adp bzw .ade) als Frontend. Die Client-Plattformen waren NT 4.0 WS bzw. W2k (immer mit MDAC 2.5). Alles lief jahrelang "bestens", bis ich mir eines Tages mit einer Dritt-Software hier und da MDAC-Upgrades auf 2.8 einhandelte. Plötzlich wurden Views, die konzeptionell immer editierbar waren, read-only insofern Sie auf mehr als 2 Tabellen fußten. Ich umging das Problem, indem ich das MDAC-Update zurückdrehte (auf NT 4.0 WS, auf W2k ist mir das nicht gelungen).
Nun steht allerdings die Migration der Client-Systeme zu Vista ins Haus, und da kommt eine 2.8-kompatible MDAC-Version 6.irgendwas mit, um die kein "walk-around" herum führt.
Nach tieferem Eindringen in die Materie, stellte sich heraus, das das Problem von in den Tabellen enthaltenen Timestamp-Feldern herrührt. Abhängig von der Position der Tabelle in der Join-Kette gelingt es, nach entfernen nur eines Timestamp-Feldes den beabsichtigten Zustand der Editierbarkeit der View wiederherzustellen.
Recherchen zum Sinn der Timestamp-Felder, die im Zusammenhang der Upsize-Operation von der früheren Access 2.0 - Anwendung her automatisch jeder Tabelle zugefügt wurden, ergaben, dass sie der schnellen und sicheren Erkennung von konkurrierenden Satzänderungen dienen und das ihr Fehlen in Tabellen mit Gleitkommafeldern wegen der differierenden internen Darstellung solcher Datentypen in Access bzw. SQL Probleme der Gestalt hervorrufen kann, dass Access dann immer einen konkurrierenden Netzwerkzugriff diagnostiziert, auch wenn niemand anders an dem Datensatz geändert hat.
Ich würde daher ungern Timestamp-Felder entfernen, da der Umfang der Anwendung schlecht erahnen lässt, welche Probleme mir daraus erwachsen.
Hat jemand Erfahrung mit derart gelagerten Problemen oder sonst hilfreiche Informationen zum Thema?
wom0659