Office: (Office 2007) ODBCDirect-Workspace in Acc2007 nicht mehr möglich

Hallo Zusammen,

da unser Office auf 2007 umgestellt wurde, funktionieren einige Datenbanken nicht mehr.

Spätestens beim "Laufzeitfehler 3847: ODBCDirect wird nicht mehr unterstützt. Schreiben Sie den Code auf die Verwendung von ADO anstelle von DAO um" musste ich das Handtuch schmeissen.*mad.gif*

Kann mir jemand sagen, wie der u.a. Code heissen sollte:
Code:

Vielen Dank schon mal für Eure Hilfe!!*frown.gif*

:)

 

Du könntest auch auf Pass-Through-Abfragen ausweichen.

Aber erstmal eine Frage, damit ich den Code nicht falsch verstehe:
Wie hängen "execute spCheckTrWerteAlleFirmen" und das Formular "Trockengehalte_Quoten zusammen?

 

Hallo Josef,

das Script spCheckTrWerteAlleFirmen ist ein SQL-ServerScript, durch das Berechnungen durchgeführt werden.

 

Wenn die SP nur ausgeführt werden muss, dann ist es vermutlich am einfachsten dies per Execute-Methode einer ADODB-Connection auszuführen.

2 Hilfsfunktionen zu Vereinfacheung von ADODB-Methoden:
Code:

Aufruf deiner SP:
Code:

falls du einmal eine DAO-Recordset einer PT-Abfrage (ersetzt die ODBCDirekt-Recordsets) benötigst:
Code:

 

Hallo Josef,

tut mir leid wenn ich mich jetzt erst wieder melde. Bin nicht dazu gekommen, dies weiter zu verfolgen.

Leider habe ich von dieser Materie überhaupt keine Ahnung. Diese alte DB wurde von einem Support-Unternehmen gebastelt. Nur nach der Umstellung bräuchten wir sie jetzt wieder.

Könntest Du mir zeigen, wie ich es in meine Function einbauen muss und wie dieser danach aussehen sollte.

 

Es bringt meiner Meinung nach nichts, wenn ich dir jetzt die Funktion Daten_gesamt() anpasse und du nicht weißt, wie
Code:

einzubauen ist. Denn es wird bestimmt nicht die einzige Prozedur sein, die nachgearbeitet werden muss und diese sieht dann bestimmt wieder anders aus.

Daher: beschreib doch erstmal, wo du nicht weiterkommst bzw. welchen Code-Teil du nicht verstehst.

BTW: möglicherweise wäre es sogar kostensparender, wenn die Anpassung vom Support-Unternehmen geändert wird.

 

Als Workaround, solange das alles noch nicht auf ADO umgestellt ist, würde IMHO auch gehen, weiterhin DAO zu erwenden: Man kann DAO-Objekte auch per late binding erstellen.
Etwa:
Code:

Zumindest für Aktionsabfragen und SPs sollte das gehen.

Ciao, Sascha

 

Hallo Sascha,

im Code erscheint bei

oEng.CreateWorkspace({ODBCDirect})

"Fehler beim kompilieren - Syntaxfehler"

 

Du sollst da auch das Gleiche reinschreiben, wie oben in deinem Code, {ODBCDirect} war ein Platzhalter!
In deinem Code verwendest du DBEngine.CreateWorkspace(..., dbUseODBC)
Das (dbUseODBC) funktioniert mit der ACE von A2007 nicht mehr.
Deshalb muss eine DBEngine her, die das unterstützt. Und mit CreateObject("DAO.DBEngine.36") wird eine solche erstellt.
Es muss im Code also nur überall DBEngine durch oEng ersetzt und die anderen 2 Zeilen von mir im Prozedurkopf eingefügt werden.
BTW. Getestet hab ich das nicht, wüsste aber nicht, warum es nicht laufen sollte.

Ciao, Sascha

 

Sorry! Habe es umgestellt und erhalte bei der Codezeile
Code:

anhängende Fehlermeldung.

 

Set oEng = CreateObject("DAO.DBEngine.36")
steht da oben! *mad.gif*

Ciao, Sascha

 

\@Sascha: Gute Idee!
Würde dann das Umstellen des DAO-Verweises auf DAO 3.6 nicht auch ausreichen?

 

Ja, Josef, unter der Voraussetzung, dass keine Recordset2-Specials verwendet werden, geht das.
Ich hatte dazu vor einiger Zeit mal einen Test gemacht:
- Neue ACCDB, nur mit DAO36-Verweis
- Ein paar Tabellen importiert
- Ein Formular auf Grundlage einer Tabelle erstellt
- Die Datenherkunft gelöscht und stattdessen in Form_Open ein modulweites DAO-Dynaset auf die Tabelle erstellt
- Das Recordset dem Formular mit Set Me.Recordset zugewiesen
- Und? Geht prima!
- So, und nun: Zur Laufzeit, etwa in Form_Current, einen Test eingebaut:
Msgbox Typename(Me.Recordset)
- Und was kommt raus: Recordset2 !

Das kann eigentlich nur gehen, wenn DAO-Recordset und ACE-Recordset COM-mäßig binäridentisch sind, denn ich kann mir nicht vorstellen, dass quasi das DAO-Recordset auf das in A2007-Formularen eingebaute Recordset2 "gecastet" wird, also ein Konvertierung stattfindet. Oder wie würdest du das sehen?
Es wurden offensichtlich lediglich die neuen Klassen, Props, Methoden in die Type Library aufgenommen und die alten gelassen, wie sie sind.

Wieweit das produktiv gut geht, vermag ich natürlich nicht zu sagen. Da müsste man mal etwas ausführlicher testen.
Aber um die Verwirrung komplett zu machen:
- Ich habe im obigen Beispiel die Tabelle mit einem Attachment-Feld versehen
- Im Formular ein Anlagensteuerelement eingebaut.
- Geht! Man kann etwa Bilder hinzufügen, auslesen, eben wie in A2007 üblich, obwohl die Basis des Formulars dieses DAO-Recordset ist.

Erst, wenn man dezidiert Recordset2/Field2-Methoden in VBA ohne Formular braucht, kommt man damit nicht weiter. (Mit Formular hat man ja das "immanente Type Casting" und damit automatisch ein Recordset2 mit Field2s in den Fields.)

Ciao, Sascha

 

Ich gehe einmal davon aus, dass die beiden Varianten die selbe COM-Schnittstellen-Definition aufweisen.
(Auch das Zuweisen eines "Standard"-Ac07-Form-Rs (ACEDAO) and ein DAO-3.6-Rs ist möglich.)
Vermutlich sieht der ACEDAO-Code so aus: "implements DAO36" *biggrin.gif* => damit wird auch Übergabe an DAO3.6-Rs möglich.

Access macht aber viele komische Sachen im Hintergrund mit Recordsets, die man einem Form zuweist. (Rs werden verändert!)
Weise einmal ein ADODB-Rs einem Form zu und guck dir vorher und nachher die Eigenschaften des Rs an. ... damit ärgerte ich mich voriges Jahr zur Genüge, als ich versuchte, ein eigenes (abgeleitetes) ADODB-RS (über .net-COM) an ein Access-Form zu binden. (die Verwendung per VBA klappte ohne Probleme)

 

Ein Form-Recordset ist eben ein Object, kein Recordset. *wink.gif*

Das mit dem Implements stimmt so. Hab gerade die acedao.dll im OLEViewer begutachtet: Interface Recordset2 > Inherited Interfaces: Recordset (Nur ParentRecordset kam als neue Schnittstellenmethode dazu).

Ciao, Sascha