| Hallo,
ich stehe tatsächlich gerade vor der Technologie Entscheidung.
Bisher war die Anwendung eine reine Access DB aufgeteilt in FE und BE, die seit 1996 gewachsen und zweimal "general"-überholt wurde.
Die neuen Erweiterungen sehen vor, dass zum einen mehr Mitarbeiter als bisher und zum anderen mit sehr stark eingeschränkten Rechten angebunden werden sollen.
Da kein Nutzungsende absehbar ist wollte ich die Gelegenheit nutzen um auf eine SQL Server Version umzusteigen (wir nutzen eh den SBS 2003 - demnächst 2011).
Wenn du aktuell vor einer Technologieentscheidung stehst, waere es besser, in Richtung DAO bzw. ACEDAO zu gehen. Damit umgehst du z.B. das ADO-Compilation-Problem seit Win7/SP1.
Das klingt interessant. Habe gerade bei kurzem googeln gefunden, dass jetzt auch Connections und ODBC Zugriff vorgesehen sind.
ADO wollte ich eigentlich nur nehmen, um verlinkte Tabellen zu vermeiden. Werde die Möglichkeiten per ACEDAO mal weiter verfolgen.
Erfahrungsgemaess hift es, andere Treiber/Provider-Versionen zu verwenden.
Werde ich auch ausprobieren.
Was ich einfach nicht verstehe ist, das der Code grundsätzlich läuft und ich auch die Datensätze im Debug-Fenster angezeigt bekomme.
Sobald ich aber das Recordset des Formulares auf das ADO Recordset zuweise, stürzt ACCESS halt ohne weiteren hinweis ab. Dachte deshalb, dass es nicht am Treiber liegt.
Eine Neuinstallation von ACCESS alleine hat nicht geholfen. Werde wohl auch noch die Radikalkur ausprobieren müssen.
Vielen Dank
Gruß Alex
|
