Ich habe Access 2003 verwendet, um ein Frontend für eine SQL Server-Datenbank zu entwickeln. Da das System verschiedene Schemas zum Partitionieren der Tabellendaten verwenden sollte, funktionierte ein Access-Projekt nicht. Stattdessen muss ich das Verbindungsmanagement für den Zugriff übernehmen - ich pflege ein globales Verbindungsobjekt und weise Recordsets Forms statt Recordsources zu.Zugriff - Datenprovider nicht initialisiert?
Ein Problem, das verursacht - immer wenn jemand versucht, integrierte Zugriffsfunktionalität zu verwenden, die mit dem Re-Cord-Set interagiert, funktioniert die Operation nicht, und ein Dialogfeld wird angezeigt mit der Meldung "Datenprovider konnte nicht initialisiert werden". Ich habe einige Nachforschungen angestellt und konnte keine relevante Ursache dafür finden, aber ich vermute, dass es darauf zurückzuführen ist, dass Access erwartet, dass ein Formular eine richtige Recordsource-Eigenschaft hat und nicht wirklich mit zugewiesenen Recordsets arbeitet.
Wer kann noch mehr Licht auf dieses Licht werfen? Gibt es eine Möglichkeit, selbstverwaltete Recordsets zu verwenden UND integrierte Funktionalität zu nutzen? Kann jemand bestätigen, dass dies ein Access-Fehler ist?
Welche Art von Recordset weisen Sie dem Formular zu: ADO oder DAO? Wenn ADO, welchen Provider verwenden Sie? Was ist der Typ des Recordsets, seine Optionen (z. B. dynamisch, statisch, nur Vorwärts usw.)? – ewbi
Warum Access bekämpfen? Erstellen Sie einfach ODBC-verknüpfte Tabellen und arbeiten Sie mit denen, die sehr zuverlässig sind. Sicher, es gibt einige Fälle, in denen sie ineffizient sein werden. In diesem Fall umgehen Sie das Problem, indem Sie Passthroughs verwenden oder die logische Server-Seite verschieben. Der Versuch, die ungebundene Route zu gehen, macht keinen Sinn, wenn ODBC so einfach ist. Es ist in der Tat MS derzeit empfohlene Best Practice für die Entwicklung von Frontends gegen SQL Server ausgeführt werden. –
Recordsets sind ADO, die den MS SQL Server-Anbieter (SQL 2005) verwenden. Optionen sind clientseitige Cursor, Keysets, schreibgeschützt. Warum nicht verknüpfte Tabellen? Der Designer hat mich ausdrücklich gebeten, nicht - die Benutzer sollen aus Sicherheitsgründen und aus Gründen der Praktikabilität keinen direkten Zugang zu den Tischen haben ... natürlich wurde dies erst NACH der Einführung von Access aufgedeckt (dieses Projekt sollte wirklich sein in VB.net, nicht Access, aber wir sind mit Access jetzt fest). – YogoZuno