Wannimmer nach ADO und ODBC im Internet gesucht wird, stößt man auf die gleichen Fragen und die gleichen Beispiele. Zumeist möchte dann jemand auf eine Access-Datenbank zugreifen. Derweil ist es so einfach, wie der Artikel im MSDN zeigt. Der Zugriff erfolgt (im Gegensatz zu DAO) nicht direkt, sondern über einen OLE DB-Treiber, der sich dann mit dem ODBC-Treiber unterhält. Klingt kompliziert, ist es aber nicht: Der einfachst mögliche ConnectionString ist “Provider=MSDASQL;DSN=MeinDSNName”

Es war ein Problem zu lösen: ein Softwaretool, das dem User individuelle Such-/Anzeige- und Massenbearbeitungsfunktionen bietet, erstreckt sich über knapp 50 Tabellen im SQL-Server 2005 (die genaue Erklärung würde hier zu weit führen). Der User kann sich nach Gutdünken seine eigenen Such-, Anzeige- und Sortierparameter quer über alle(!) Tabellen selbst zusammenstellen. Nun muss sich aber das Programm möglichst effizient durch die Tabellen handeln (JOIN). Weil ich keine Lust hatte, alle möglichen Beziehungen aufzudröseln und abzulegen, dachte ich an eine Art “Datenbank-Navigationssystem”, das mir den kürzesten (=effizientesten) Weg vonTabelle A (über Tabelle C und O) zu Tabelle K zeigt (das Bild ist nur ein Beispiel!). (weiterlesen…)

Wenn Sie Datenbanken aus früheren Access-Versionen auf das neue mit Access 2007 eingeführte ACCDB-Format umstellen möchten, sind nach der Konvertierung unter Umständen Anpassungen der VBA-Routinen notwendig. Das Objektmodell wurde in vielen Punkten geändert, so dass zum Beispiel “DoCmd.RunCommand”-Anweisungen oder verschiedene Eigenschaften und Auflistungen nicht mehr genutzt werden können oder für Funktionen wie zum Beispiel “OpenDatabase” zusätzliche Parameter zur Verfügung stehen. Die nicht mehr unterstützen Anweisungen, Eigenschaften oder Auflistungen lassen sich notfalls noch in der VBA-Entwicklungsumgebung per “Debuggen-Kompilieren” einzeln lokalisieren und umsetzen, neue Möglichkeiten, die verschiedene Aufgaben unter Umständen drastisch vereinfachen, finden Sie auf diesem Weg jedoch nicht. Die MSDN-Spezialisten haben sich deshalb die Mühe gemacht und sämtliche Änderungen in Übersichten zusammengefasst. Dabei werden die Änderungen im Vergleich zu einzelnen Access-Versionen aufgelistet, so dass Sie zum Beispiel bei Umstellung einer Access 2000-Datenbank exakt auf die Punkte hingewiesen werden, die sich im Vergleich zu Access 2007 geändert haben. Sie finden die Übersichten je nach Access-Version unter den folgenden Adressen:

Änderungen seit Access 97

Änderungen seit Access 2000

Änderungen seit Access 2002/XP

Änderungen seit Access 2003

via SmartTools

Folgende Ausgangssituation:

Es ist eine Baumstruktur (Vereichnisstruktur, Kategoriestruktur…) in einer Datenbank abgelegt. Die Struktur besteht aus

• RecordID: eindeutige Kennzeichung des Eintrages
• ParentRecordID: auf welches übergordnete Element bezieht sich dieser Eintrag (hat aber auch einen eigene eindeutige RecordID!)
• Description: Bezeichung des Eintrages

Es soll nun die Ausgabe des “Pfades” für ein gegebene ID ermöglicht werden. Dazu müssen sie die Bezeichungen “von” oben nach “unten” (von der Parents zu den Childs) nebeneinander stehen. Es gibt mehrere Möglichkeiten:

• eine wäre ein Script zu schreiben, das die Parameter einer gegebenen RecordID ausliest und sich solange durch den Baum hangelt, bis es am Root-Element ist (geht, is klar verständlich aber langsam und kompliziert für andere Aktione weiterzuverwenden)
• eine Andere (die Bessere): den SQL-Server dies selbst erledigen zu lassen. Seit der Version 2005 ist dies relativ einfach zu bewerkstelligen, die Funtkionen WITH der Common Table Extensions helfen hier weiter.

Robb Morris hat mit diesen einige sehr einfache und gut verständliche Beispiele geschaffen. Für eine weitere Verwendung sollten diese noch so erweitert werden, dass von anderen Skripten/Prozessen damit weitergarbeitet werden kann. (weiterlesen…)

Also, nach vielen Recherchen und noch mehr Tests habe ich leider feststellen müssen, dass ADP-Projekte in MS Access nur mit dem SQLOLEDB-Treiber funktionieren, spriche auf max. SQL-Server 2000 festgelegt sind. Betroffen sind alle Versionen von MS Access, die ADP untersützen, Office 2007 nicht mehr, da hier die ADPs offiziell wieder abgeschafft wurden (lt. Auskunft MSCT).

Das einzige, was funktioniert ist, Access die Verbindung über den SQLOLEDB machen zu lassen, ungeachtet dessen aber mit einer eigenen ADO-Connection zum Datenbankserver zu arbeiten (dem man dann auch den SQLNCLI zuweisen kann) und alle Zuweisungen an Formulare und Controls an Recordsets zu binden und diese zuzuweisen.

Microsofts Rat zu dem Problem:

You have connected to a version of SQL Server later than SQL Server 2000.
To correct this error: Delete the data connection to the newer SQL Server, and connect only to SQL Server 2000 or earlier versions.
siehe MSDN

Hier läßt sich einer darüber aus und ich finde, er hat Recht:
MS is a bunch of friggin drunk retards for not giving us a realworld
option for using ADP 2003 against SQL 2005.
I mean; the product manager than made that decision should be shot on
live television.
I mean.. Server-based Crosstab Query Wizard, anybody?
HELLO IS THERE ANYBODY IN REDMOND WITH A CLUE??
i mean-- what better way to force adoption of Office 2003??

siehe wiredbox

Für Wissbegierige gibt es auch den Access Team Blog bei Microsoft.

[Update] :

Von Mary Chipman (Microsoft) gibt es dazu das folgendes Statement:
"You will not be able to use any of the designers with SQLS 2005 databases, whether it's SQL Express or the Developer edition. IOW, you won't be able to create databases, tables, views or any other database objects from an ADP. The only support that is envisioned is that you will be able to connect an Access front-end to a SQLS 2005 back end if it is running in SQLS 2000 compatibility mode, so your forms, reports and other local Access objects should still run. There is no service pack or quick fix being planned as far as I know because of the amount of work it would entail. If you stop to think about it, it's pretty hard to see how accomodating new Yukon features like CLR assemblies and complex data types in the ADP designers could be achieved without a complete rewrite.
That said, with Access 2003, I was able to connect up to an instance of SQL 2005 (not in 2000 compatibility mode) and work with data with SQL2000 compatible data types. I was also able to stick XML into an XML-typed (but not strongly-typed) column and have it work as expected.
The bottom line here seems to be that ADPs aren't worth investing new work into today if you plan to go to SQL Server 2005 with them. However, my limited testing of Access 2003 as the Frontend and SQL Server 2005 as backend using linked tables seems to be okay. Time will tell, of course."
siehe hier