Office: (Office 365) copyfromrecordset funktioniert nicht mehr

Das hatte ich auch schon gelesen und gemacht ... erst unrgistered, dann neu registered.
Dennoch keine Veränderung.

 

Die dao360.dll ist jedoch nicht als "Verweis" in Access eingebunden, sondern nur die folgenden:

Visual Basic for Applications
Microsoft Access 16.0 Object Libary
OLE Automation
Microsoft Office 16.0 Access database engine Object libary

Wobei sich bei gleichzeitiger Aktivierung Microsoft Office 16.0 Access database engine Object libary und die dao360.dll gegenseitig ausschließen.

 

Anbei mal eine Beispiel-Datei.
Bitte beachten das der Export in eine vordefinierte XLSM-Datei eingefügt werden soll und der Pfad in diese gemäß Code erst erstellt oder angepasst werden muss.

Ansonsten hab ich nur noch den für den Export relevanten Code in der Datenbank gelassen, bei dem ansonsten keine Fehler auftauchen.

 

...tja... was soll man dazu sagen? Du dokterst hier schon eine Woche an diesem Problem herum, dass schon vor 6 Tagen in unter 5 Min. hätte gelöst sein können.
Und das, nur weil Du Dich an VBA klammerst und andere Möglichkeiten kategorisch ausschliesst...

 

Hallo Ralf,

ich bin nun mal nur ganz normaler Anwender und habe von PQ keine Ahnung ... daher schließe ich es nicht kategorisch aus.
Zudem geht es, wenn ich Dich nicht falsch verstehe, nicht nur um das Einfügen des Recordsets in eine Excel-Datei, sondern um den Export individueller Daten in bis zu 20 Dateien.

 

Das muss ja nicht so bleiben. Vermutlich hattest Du irgendwann mal auch keine Ahnung von Access, Excel oder VBA?

...reagierst dennoch nicht auf einen entsprechenden Vorschlag... Null Reaktion...

Ja und? Import statt Export. Braucht man trotzdem nur eine Datei und regelt das mit entsprechenden Parametern.... kann man aber auch auf 20 Dateien verteilen.... wie man es gern hätte...

 

Sofern ich Dich nicht falsch verstehe ... ich möchte gern weiterhin, dass der Export von Access heraus gestartet und generiert wird und man nicht jede Excel-Datei separat öffnen muss.
Lässt sich das so mit Deinem Vorschlag umsetzen ?

 

Wenn Du auf den Export bestehst, dann geht das natürlich nicht mit PQ. Wenn Du allerdings flexibel bist, dann reicht, wie ich schon sagte, eine einzige Exceldatei statt 20. In der steuerst Du dann, welche Daten importiert werden sollen... oder speicherst jeden der 20 Importe in einem separaten Tabellenblatt der gleichen Datei...

 

In meinem Fall müssen 20 eigenständige und individuelle Excel-Dateien erstellt sein, da ich diese per Mail an 20 verschiedene Personen versende.

 

...in diesem Fall bleibe bei VBA in Access... da kannst Du alles zentral steuern...

Wenn allerdings die immer gleichen Leuten die immer gleichen Daten bekommen sollen (die lediglich aktualisiert werden müssen), dann würde ich 1malig 20 Dateien erstellen, die einmalig verschicken und die Empfänger können sie bei jedem öffnen selbständig per Hand oder automatisch aktualisieren (lassen)...

 

Leider ist die Aktualisierung nicht möglich, da die Verwendung nur LOKAL und ausserhalb meines Netzwerks passiert.

 

Ich habe mal mit dem MS Copiloten a bissl gespielt und komme nach der Code-Umstellung auf ADODB zu dem Ergebnis, dass dieser wie gewünscht funktioniert wenn ich die SQL-Abfrage als sqlString selbst im Code stehen habe, jedoch nicht wenn ich mich per sqlString = AcTabAbfrSQL auf die Abfrage beziehe.

Gibt es dafür eine Erklärung ?

 

Die weitere Recherche ergab den nachfolgenden Code, mit dem soweit im kurzen Test geprüft, erst mal wieder alles funktioniert.

Code:

Sub ExcelExportCopyFromRecordset(AcTabAbfrSQL As String, _
                                 FullExcelDatName As String, _
                                 ExcelTabName As String, _
                                 ExcelStartZelle As String, _
                                 ZellenLeeren As Boolean)

    Dim xlApp As Object, xlbook As Object, xlsheet As Object
    Dim AktDb As Object, rs As Object
    Dim sqlString As String
    Dim qdf As QueryDef

    On Error GoTo ErrorHandler

    ' Set ADODB connection and recordset objects
    Set AktDb = CreateObject("ADODB.Connection")
    Set rs = CreateObject("ADODB.Recordset")

    ' Open the Access database connection
    AktDb.ConnectionString = "Provider=Microsoft.ACE.OLEDB.12.0;Data Source=" & CurrentDb.Name
    AktDb.Open
    Debug.Print "Verbindung zur Datenbank hergestellt."

    ' Open Excel and the specified workbook
    On Error Resume Next
    Set xlApp = GetObject(, "Excel.Application")
    If xlApp Is Nothing Then
        Set xlApp = CreateObject("Excel.Application")
    End If
    On Error GoTo 0
    If xlApp Is Nothing Then
        MsgBox "Excel konnte nicht gestartet werden."
        Exit Sub
    End If

    Set xlbook = xlApp.Workbooks.Open(FullExcelDatName)
    Set xlsheet = xlbook.Sheets(ExcelTabName)
    xlApp.Visible = False
    Debug.Print "Excel-Datei geöffnet: " & FullExcelDatName

    ' Get the SQL from the saved query
    Set qdf = CurrentDb.QueryDefs(AcTabAbfrSQL)
    sqlString = qdf.SQL
    Debug.Print "SQL-Abfrage: " & sqlString

    ' Use ADODB constants explicitly
    Const adOpenStatic = 3
    Const adLockReadOnly = 1

    ' Open the recordset with explicit ADODB parameters
    rs.Open sqlString, AktDb, adOpenStatic, adLockReadOnly
    Debug.Print "Recordset geöffnet."

    ' Clear the specified range if necessary
    If ZellenLeeren Then
        xlsheet.Range(ExcelStartZelle, Mid(xlsheet.UsedRange.Address, _
                     InStr(xlsheet.UsedRange.Address, ":") + 1)).ClearContents
    End If

    ' Check if the recordset is empty
    If rs.BOF And rs.EOF Then
        MsgBox "Das Recordset ist leer!"
    Else
        xlsheet.Range(ExcelStartZelle).CopyFromRecordset rs
    End If

    ' Save and close the Excel workbook
    xlbook.Save
    xlbook.Close
    rs.Close
    AktDb.Close

    ' Clean up
    Set rs = Nothing
    Set qdf = Nothing
    Set xlsheet = Nothing
    Set xlbook = Nothing
    Set xlApp = Nothing

    Exit Sub

ErrorHandler:
    MsgBox "Fehler " & Err.Number & ": " & Err.Description
End Sub

 

ADO ist für mich auch die bessere Lösung, wobei das immer noch nicht erklärt, warum DAO plötzlich nimmer funktioniert.
Egal.
Meiner Erfahrung nach ist ADO sehr stabil. Würde dabei bleiben.