DBF-Datenbankabfrage per VBA in Excel
Excel-2003
Hallo,
ich habe mich zum ersten Mal an eine Datenbankabfrage gewagt. Da ich nur abfragen und auf keinen Fall etwas in die Datenbank reinschreiben will, nutze ich Query. Hierzu habe ich den folgenden Code:
Das funktioniert so auch schon sehr gut, aber: Es werden ALLE Datensätze entsprechend der Abfrage importiert, leider auch die, die in der Datenbank als gelöscht gekennzeichnet sind. Kann ich das Importieren gelöschter Datensätze verhindern?
Bin für jede Hilfe dankbar!
[Edit] Codeformatiert, damit es vielleicht eine/r lesen mag [/Code]
Hallo,
ich habe mich zum ersten Mal an eine Datenbankabfrage gewagt. Da ich nur abfragen und auf keinen Fall etwas in die Datenbank reinschreiben will, nutze ich Query. Hierzu habe ich den folgenden Code:
Private Sub CommandButton1_Click()
Range("BF1:BJ65536").Clear
With ActiveSheet.QueryTables.Add(Connection:=Array(Array( _
"ODBC;DSN=dBASE-Dateien;DefaultDir=C:\;DriverId=533;FIL=dBase 5.0;MaxBufferSize=204" _
), Array("8;PageTimeout=5;")), Destination:=Range("BF1"))
.CommandText = Array( _
"SELECT ABPOS.ART_NR, ABPOS.SART_NR, ABPOS.MG_BES, ABPOS.TERMIN, ABPOS.AUSLIEFNR" & Chr( _
13) & "" & Chr(10) & "FROM {oj `F:\STAND94`\ABPOS.DBF ABPOS LEFT OUTER JOIN `F:\STAND94`\ABKOPF. _
DBF ABKOPF ON ABPOS.AB_NR = ABKOPF.AB_NR}" & Chr(13) & "" & Chr(10) & "WH" _
, "ERE (ABKOPF.DEB_NR Like '1100%') AND (ABPOS.TERMIN Like '" & Format(CDate(Date), "yy") _
& "%') AND (ABPOS.MG_GEL Is Null) AND (ABPOS.AUSLIEFNR Is Not Null)")
.Name = "Abfrage von dBASE-Dateien"
.FieldNames = False
.RowNumbers = False
.FillAdjacentFormulas = False
.PreserveFormatting = False
.RefreshOnFileOpen = False
.BackgroundQuery = False
.RefreshStyle = xlOverwriteCells
.SavePassword = False
.SaveData = True
.AdjustColumnWidth = False
.RefreshPeriod = 0
.PreserveColumnInfo = False
.Refresh BackgroundQuery:=False
End With
Call DieseArbeitsmappe.StarteAuswahlBox 'Hier beginnen die weiteren Auswertungen
End Sub
Bin für jede Hilfe dankbar!
[Edit] Codeformatiert, damit es vielleicht eine/r lesen mag [/Code]
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 177588
Url: https://administrator.de/forum/dbf-datenbankabfrage-per-vba-in-excel-177588.html
Ausgedruckt am: 23.04.2025 um 07:04 Uhr
4 Kommentare
Neuester Kommentar
Moin HAPO-MF,
meines Wissens nach wird die dBase-Einstellung SET DELETED OFF zum Überlesen der (logisch) gelöschten bzw. der als gelöscht markierten Sätze von keinem der in freier Wildbahn befindlichen Treiber erkannt.
Ist bei deinem Treiber (DriverID 533) so, war aber auch so bei dBase IV (DriverID 277?) und dBaseIII (+).
Falls du diese Wahrheit (sorry, ich bin ja nur der Bote) an dich heranlässt, dann bleiben folgende vertretbare Workarounds
--> alles andere ist witzlos, du könntest die Daten natürlich nach Access, Excel,.... ziemlich jedem Format "importieren" jeweils mit der Applikation Access, Excel,....usw.
Aber egal wer es importiert, die DELETED-Sätze werden entweder mit übernommen (also nicht erkannt als gelöscht) oder aber, falls zufällig "der erste Importsatz" eine Löschmarkierung hat, dann werden ganze 0 Datensätze übernommen.
Der dritte (unvertretbare) Workaround ist -> lies diese dBase-Daten ohne Treiber und ohne ODBC, mit einem byteweise-arbeitenden Schnipsel.
Alle dBase-Formate sind voll durchdokumentiert und es sind relatv harmlose Flatfiles (mit Header und danach fester Zeilenlänge).
Wenn die Daten wichtig sind, dann suchmaschine danach, ansonsten vergiss es.
Falls du (du hast ja in mehreren Foren crossgepostet) anderswo eine "echte" Lösung findest, bitte stell sie auch bei uns ab.
Grüße
Biber
meines Wissens nach wird die dBase-Einstellung SET DELETED OFF zum Überlesen der (logisch) gelöschten bzw. der als gelöscht markierten Sätze von keinem der in freier Wildbahn befindlichen Treiber erkannt.
Ist bei deinem Treiber (DriverID 533) so, war aber auch so bei dBase IV (DriverID 277?) und dBaseIII (+).
Falls du diese Wahrheit (sorry, ich bin ja nur der Bote) an dich heranlässt, dann bleiben folgende vertretbare Workarounds
- Wenn du noch ein dBase im Betrieb hast, dann mach endlich ein PACK und dann hast du keine logisch gelöschten Sätze mehr.
- oder lies diese Dbase-Trümmer mit einem FoxPro-Treiber -> der kann putzigerweise dBase lesen UND die DELETED-Sätze erkennen
--> alles andere ist witzlos, du könntest die Daten natürlich nach Access, Excel,.... ziemlich jedem Format "importieren" jeweils mit der Applikation Access, Excel,....usw.
Aber egal wer es importiert, die DELETED-Sätze werden entweder mit übernommen (also nicht erkannt als gelöscht) oder aber, falls zufällig "der erste Importsatz" eine Löschmarkierung hat, dann werden ganze 0 Datensätze übernommen.
Der dritte (unvertretbare) Workaround ist -> lies diese dBase-Daten ohne Treiber und ohne ODBC, mit einem byteweise-arbeitenden Schnipsel.
Alle dBase-Formate sind voll durchdokumentiert und es sind relatv harmlose Flatfiles (mit Header und danach fester Zeilenlänge).
Wenn die Daten wichtig sind, dann suchmaschine danach, ansonsten vergiss es.
Falls du (du hast ja in mehreren Foren crossgepostet) anderswo eine "echte" Lösung findest, bitte stell sie auch bei uns ab.
Grüße
Biber
Moin HAPO-MF,
danke auch für deine Antwort.
Bin in der Tat überrascht, dass es da jetzt doch etwas "unkompliziertes" geben könnte.
Beim postwendenden Versuch, das an meiner neuen (und deshalb relativ ungepimpten) Windows7-Büchse auszuprobieren, kam allerdings sofort eine Meldung des "Microsoft ODBC-Administrators" beim Anfassen des dBASE-Treibers.
Aber ich denke, das ist ein (für Redmonder PraktikantInnen) relativ normaler Bug, der alle Benutzer-ODBC-Treiber betrifft, die ohne vorheriges Anschauen mit Admin-Rechten benutzt werden sollen. Stümper, damische, amerikanische.
Wenn ich bei Gelegenheit mal wieder mit Admin-Rechten unterwegs bin, probiere ich es noch mal.
[Nachtrag] Die Fehlermeldung geht nach dem nächsten OK noch weiter, hab ich grad gemerkt.
Nein, liebe Redmonder.
Das weist eher eine fehlende Passgenauigkeit von Anforderungen und Voraussetzungen auf, ihr Dödel.
Ich hau mir jezz' auch einen Glühwein in'n Kopp.
[/Nachtrag]
[Nachtrag2 am 17.12.2011]
Unter Vista/Office2003 funktioniert es in der Tat wie oben beschrieben.
Unter Win7 komme ich es (auch mit Admin-Rechten) nicht hin.
Habe es allerdings auch nicht weiter verfolgt, da ich keinen eigenen Leidensdruck zum Einlesen von DBF-Dateien habe.
[/Nachtrag2 am 17.12.2011]
Grüße
Biber
danke auch für deine Antwort.
Bin in der Tat überrascht, dass es da jetzt doch etwas "unkompliziertes" geben könnte.
Beim postwendenden Versuch, das an meiner neuen (und deshalb relativ ungepimpten) Windows7-Büchse auszuprobieren, kam allerdings sofort eine Meldung des "Microsoft ODBC-Administrators" beim Anfassen des dBASE-Treibers.
"Die Setup-Routinen für den Microsoft Access dBASE Driver (*.dbf, *.ndx, *.mdx) ODBC-Treiber konnten nicht gefunden werden. Installieren Sie den Treiber erneut."
Aber ich denke, das ist ein (für Redmonder PraktikantInnen) relativ normaler Bug, der alle Benutzer-ODBC-Treiber betrifft, die ohne vorheriges Anschauen mit Admin-Rechten benutzt werden sollen. Stümper, damische, amerikanische.
Wenn ich bei Gelegenheit mal wieder mit Admin-Rechten unterwegs bin, probiere ich es noch mal.
[Nachtrag] Die Fehlermeldung geht nach dem nächsten OK noch weiter, hab ich grad gemerkt.
Fehler bei ConfigDSN, ConfigDriver oder ConfigTranslator
Fehler gefunden.
Der angegebene DSN weist eine nicht übereinstimmende Architektur von Treiber und Anwendung auf.
Fehler gefunden.
Der angegebene DSN weist eine nicht übereinstimmende Architektur von Treiber und Anwendung auf.
Nein, liebe Redmonder.
Das weist eher eine fehlende Passgenauigkeit von Anforderungen und Voraussetzungen auf, ihr Dödel.
Ich hau mir jezz' auch einen Glühwein in'n Kopp.
[/Nachtrag]
[Nachtrag2 am 17.12.2011]
Unter Vista/Office2003 funktioniert es in der Tat wie oben beschrieben.
Unter Win7 komme ich es (auch mit Admin-Rechten) nicht hin.
Habe es allerdings auch nicht weiter verfolgt, da ich keinen eigenen Leidensdruck zum Einlesen von DBF-Dateien habe.
[/Nachtrag2 am 17.12.2011]
Grüße
Biber