Office: Access 2013; VBA; Unterformular via ADODB

Hallo Leute,

leider stehe ich wieder an einem Problem wo ich mir die Finger beim Suchen wund getippt habe.

Ich habe folgendes Problem:
Ich habe einen Unterformular und möchte die DS per ADODB.Recordset im Unterformular (als Tabellenform) anzeigen lassen. Ursprünglich habe ich ganz normal die Tabelle an das Unterformular angebunden. Doch da ich über ODBC und Remout-MySQL die DS hole, kann ich schlecht die jeweilige Tabelle direkt an das Unterformular binden.

Deshalb habe ich gedacht, dass ich die Daten per ADODB (bitte nicht mit DAO !!!) aus der Tabelle hole und diese an den Unterformular weiter gebe.

Kann mir jemand da Helfen und mir eventuell paar funktionale Beispiele nennen?
Wäre euch echt sehr Dankbar

Habe folgende Funktionen vorbereitet wo ich DS aus den Tabellen entnehmen kann.

Code:

Im Formular habe ich es mir dann in etwa so vorgestellt:
Code:

Aber das Funktioniert so leider nicht. Weil die unterschiedliche Typen sind etc.

:)

 

Hast Du die Zuweisung mal so ausprobiert: Code:

 

Hallo

danke für deine Antwort.
Ja habe ich allerdings aber genau an dieser Zeile bekomme ich folgende Fehlermeldung:

Laufzeitfehler '2467:
In dem von Ihnen eingegebenen Ausdruck wird auf ein Objekt verwiesen, dass geschlossen oder nicht vorhanden ist.

Dabei ist mein Unterformular vorhanden. Der ist nur nicht an eine Tabelle oder Abfrage gebunden.

MfG
Daniel

 

Dieser Fehler könnte von einem im Entwurfsmodus geöffneten Unterformular stammen.
LG Markus

 

Hallo!

[etwas OT]

Ich testete deinen Code mit einem Connectionstring mit OLEDB-Provider zum SQL-Server und mir wurden Datensätze angezeigt.
Anm.: Ich füge bei ODBC-Treibern immer "Provider=MSDASQL;" vor der ODBC-Verbindungsdefinition ein. Das wird aber vermutlich nicht dein Problem sein.


BTW:

Du verwendest einen ODBC-Treiber, warum darf es dann kein DAO-Recordset sein?

mfg
Josef

 

Auch wenn es OT ist und vermutlich nicht der Grund des OP.
DAO hat (seit dem Wegfall von ODBC-Direct) im Gegensatz zu ADO keine sinnvolle und vollständige Implementierung mehr für den Aufruf von Stored Procedures über ODBC.

 

Im aktuellen Fall soll aber nur eine Tabelle verbunden werden. Das läuft normalerweise über DAO/ODBC ganz gut.
Anm.: ich will damit nur ausschließen, dass Crashbreaker die Variante mit den Verbindungsdaten im Jet-SQL-Text nicht kannte und daher mit "bitte nicht mit DAO" eigentliche "bitte keine verknüpfte Tabelle" meinte. *wink.gif*



An den Gedanken von Markus anschließend:
Wird möglicherweise die SourceObject-Eigenschaft des UF-Steuerelements erst nach Form.Load befüllt?

Zur Fehlersuche finde ich es hilfreich, wenn man den Aufruf aus Form.Load entfernt und z. B. mittels Button-Klick o. ä. auslöst. Dann kann man zuerst überprüfen, ob alles andere funktioniert. (Wie z. B. ob da UF richtig - wenn auch ohne DS - dargestellt wird, bevor das RS geladen wird.)

Weiters hilft bei der Fehlersuche das Zerlegen des Codes und ansprechen der Objekte über Variablen.

Beispiel (Luftcode):
Code:

mfg
Josef

 

Hallo Josef,

danke für deine Antwort.
Habe die Idee so übernommen doch nun bekomme ich eine andere Laufzeitfehler.

Und zwar genau an dem Punkt wo ich die Zeile ".Open , , , , adCmdText" in der Funktion "GetRecordset" ...

Laufzeitfehler lautet:
Laufzeitfehler '2147217900 (80040e14)':
[MySQL][ODBC 5.3(w) Driver][mysqld-5.5.45.cll]You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'DRIVER={MySQL ODBC 5.3 UNICODE Driver]}; ...' at line 1

Mein SQL sieht so aus:
Code:

Nun ja, es sprechen mehrere Gründe warum ich lieber ADO verwenden möchte als DAO. Du hast es richtig erkannt. Zum einen möchte ich die Tabellen nicht verknüpft haben und zum anderen brauche ich so nicht an verschiedenen Rechnern vorerst ODBC konfigurieren. So können die Leute einfach mein Access-Datei nehmen und direkt los legen. Mit DAO habe ich leider nicht die Möglichkeit so vorgehen zu können. Hinzukommt wie @sonic8 es erwähnt hat, dass Microsoft selbst lieber ADO bevorzugt für die Leute die mit Remoute-SQL arbeiten wollen.

 

mfg
Josef

Hm, ich hatte deshalb Form.Load ausgewählt, da es direkt geladen sollte. Aber um Fehler einzukesseln hast du recht. Habe eine Schaltfläche gemacht die bei mir "btnTest" heißt.

Nun sieht mein Funktion so aus:
Code:

 

Hallo!

 

\@Josef

Hallo Josef, abseits des Themas hätte mich interessiert, ob die oben angeführte Methode zum Öffnen des ado Recordsets überhaupt möglich ist (hat mit dem Fehler ja nichts zu tun)

.CursorLocation = adUseClient
.CursorType = adOpenDynamic

Ich würde davon ausgehen, dass das Recordset einen statischen CurserType liefert und der dynamic nur bei CursorLocation Server möglich ist. Falls nicht bitte ich um Aufklärung.

LG Markus

 

\@Markus:
adUseClient ist wichtig, sonst funktioniert ein ADODB-Recordset nicht als Formular-Recordset.
Der Rest ist (fast) egal, da das Access bei der Formularübergabe selbst (ich nehme an auf adOpenStatic) umstellt.

zum Ausprobieren:

Code:

/edit:
Gerade ausprobiert:
Wenn man GetRecordset wie folgt nutzt:
Code:

... kommt es zu einem Fehler bei der Zuweisung zum Form-Recordset.

Verwendet man adOpenKeyset statt adOpenDynamic, wird das bei der Formular-Zuweisung auf adOpenStatic geändert.

mfg
Josef

 

Hallo!

Das ist klar, da dein Problem nicht mit dem Recordset zusammenhängt.

Ich hoffe, dass ich die Vorgehensweise anhand der Code-Beispiele deutlich genug beschrieben habe.
Wenn du das ADODB-Rs öffnest, dann darfst du nicht die SQL-Anweisung mit dem Connectionstring verwenden. Das wäre eine Variante, für die Zuweisung der Datenquelle für ein Formular, das als Unterformular verwendet wird.

Ah, ich glaub, jetzt verstehe ich das Problem.
Du verwendest gar kein Formular im Unterformular, sondern hast direkt im Unterformular auf eine Tabelle verwiesen.
Wenn ein Unterformularsteuerelement kein Herkunftsobjekt hat, dann kannst du aber nicht auf die Form-Eigenschaft zugreifen. Das ist aber irgendwie logisch: Wenn keine Form-Instanz vorhanden ist, kann keine Eigenschaft dieser Form-Instanz eingestellt werden.
=> Du musst ein Formular erstellen und in diesem die Datenherkunft bzw. das Recordset einstellen.

mfg
Josef

 

Äh, WTF?!
Das ist genau was dir die Fehlermeldung sagt: Dein Unterformular enthält kein Herkunftsobjekt!

Ein Recordset ist kein grafisches UI-Element, sondern eine Datensatzgruppe im Speicher. Diese kannst Du an ein Formular binden um sie zu visualisieren, aber ohne Formular geht es nicht.

Die von Dir gewünschte Darstellung nennt sich Datenblattansicht und ist eine der möglichen Ansichten eines Formulars.