Office: (Office 365) copyfromrecordset funktioniert nicht mehr

Ja, warum einfach, wenn es umständlich auch geht?
Ich persönlich hab noch keine einzige Abfrage in PQ geschafft, die mich nicht an den Rand des Nervenzusammenbruchs gebracht hat.

 

...einen simplen Datenimport solltest auch Du ganz locker hinbekommen. Um mehr geht es ja in diesem Fall nicht...
Das wäre im PQ Editor ein 2-Zeiler:

Code:

let
    Datenbank = Access.Database(File.Contents("C:\Users\User\OneDrive\Access\Uni Erfurt\Kolleg_2006-11-19.mdb"), [CreateNavigationProperties=true]),
    Auswahl = Datenbank{[Schema="",Item="A_Serienbrief_Mahnung_Kurse"]}[Data]
in
    Auswahl

Wobei die Variablennamen vor dem = von mir (zum besseren Verständnis) geändert wurden. Datenbank ist im Original Quelle.
Anzupassen wären natürlich noch der Pfad und auch der Abfrage-/ Tabellenname. Also alles das, was zwischen den Anführungszeichen steht...

Und jetzt vergleich das mit dem VBA Code...
Und das Beste daran... man muss den Code nicht einmal selbst schreiben. Den klickt man sich (in diesem Fall) ganz einfach durch die entsprechenden Auswahloptionen ratz fatz mit der Maus zusammen. (sh Post #14)
Soviel zum Thema, warum einfach, wenn es umständlich geht...

 

Weißt du, wenn ich den Code vom PQ Editor sehe, bekomme ich Nagelbrennen.
Ehrlich, ich verwende Qery, um komplexe Abfragen zu konstruieren. Da muss ich mir nicht viel Gedanken zu SQL machen sondern die Abfrage zusammenklicken. Das kann PQ gar nicht.
Das Ganze kann ich dann mit ein paar Handgriffen auch über VBA automatisieren.
Denke, so wird das vom OP auch mal gemacht worden sein.

 

Klar, jeder hat halt so seine Vorlieben. Vor PQ hab ich auch fast alles mit VBA erledigt, aber je mehr ich mich in PQ einarbeitete, umso mehr komme ich von VBA ab.
Klar, der M-Code ist gewöhnungsbeürftig, die Schleifen oder einfache Funktionen wie Summe, SummeWenn oder alles, was man bisher ganz easy beherrschte, bedarf einer völlig anderen Herangehensweise. Doch gerade die Verbindung von PQ mit Power Pivot oder die Verwendung von Power BI (da ist M-Code nunmal Standard) lässt VBA dann weit hinter sich. Es lohnt sich also, sich damit vertraut zu machen.
Aber ja... man muss es natürlich nicht... so, wie man auch Excel nicht zum Leben braucht ...

 

Guten Morgen zusammen,

ich würde gern die DAO 360 Objektbibliothek per AddFromFile-Methode einbinden. An welcher Stelle platziere ich das dann in den Code aus Thread 1 ein ?
Und muss dann vom bestehenden Code noch etwas geändert werden ?

Beste Grüße
Jens

 

Vielleicht noch ein Anhaltspunkt, ich hatte erst Office 365 als 64bit-Version und danach nach als 32bit-Version aufgespielt bekommen. Wobei ich aber sagen muss, dass der Export-Code nach Excel unter Office 365 als 64bit-Version auch tadellos funktioniert hat.

 

Hast du den Link mal angeschaut, den ich dir gepostet hab?
Da sind die beiden Möglichkeiten drin. Für 64 bit braucht es eine andere Version von der DLL

 

Ja Deinen Post #14 hab ich mir angesehen und meine Rückfrage dazu unter Post #20 gestellt.

 

Code:

Dim AktDb As object,  rs As object
Dim dbe As Object
Set dbe = CreateObject("DAO.DBengine.36")
set AktDb = dbe.Database
set rs as dbe.recordset

Hab hier kein Access, drum kann ich nur ins Blaue schießen, ob das genau so geht.

Hast du dir eigentlich mal im Direktbereich das Recordset angeschaut, ob da überhaupt Daten drin sind?

 

Zur Info....
copyfromrecordset funktioniert nicht mehr | HERBERS Excel Forum

 

Guten Morgen,

das Ergebnis des nachfolgenden Codes am Ende ergibt schon mal, dass das Recorset nicht leer ist.
Ansonsten wird mir Deine Zeile in rot dargestellt: set rs as dbe.recordset

Nach der Änderung in Set rs = dbe.Recordset hängt sich der Code wegen LZ-Fehler 438: "Objekt unterstützt diese Eigenschaft oder Methode nicht" in Zeile Set AktDb = dbe.Databaset auf.


Set rs = AktDb.OpenRecordset(AcTabAbfrSQL)
If rs.BOF And rs.EOF Then
MsgBox "RecordSet ist leer!"
Else
MsgBox "RecordSet ist nicht leer!"
End If

 

Okay, das kommt davon, wenn man ins Blaue schießt.
Wenn das Recordset nicht leer ist, dann kann es fast nicht an der DLL liegen
Oder doch?
Schau mal, ob du unter c:/program files/common files/microsoft shared/dao/ die dll liegen hast.
Bei mir existiert die auf dem Rechner in der Arbeit gar nicht.

 

Ja die dao360.dll ist unter C:\Program Files (x86)\Common Files\Microsoft Shared\DAO vorhanden.

 

Nachtrag. Hab die in einem seltsamen Ordner gefunden.
Wenn das bei dir auch so sein sollte, müsste die erst registriert werden. Das kannst du ergooglen.

 

Vielleicht musst du sie dennoch registrieren?