Excel.Worksheet.Range in ein ADODB.Recordset übertragen
Mirco Wilhelm
Ich versuche eine Excel Worksheet Range in ein Access Recordset zu
importieren, aber ich finde einfach nicht raus, welchen Datentyp ich dazu
benutzen muss.
Das ganze scheint auf jeden Fall mal zu funktionieren.
strExcelRange = "A1:A10
objExcelSheet.Range(strExcelRange).Copy
Wenn ich das Ergebnis ins CLipboard kopiere und dann in Notepad einfüge
sieht das ungefät so aus:
1 a A
2 b B
3 c C
4 d D
5 e E
6 f F
7 g G
8 h H
9 i I
10 j J
Alles was ich jetzt also noch schaffen muss ist diese Ausgabe in einen
Recordset zu übertragen. Da die Typen aber abweichen versuche ich das ganze
erstmal in eine andere Variable zu speichern, die ich dann in ner Schleife
übertragen kann. Laut Hilfe sollte das so aussehn.
objExcelSheet.Range(strExcelRange).Copy NewVariable
Ich hab also versucht das ganze an einen String Array, ADODB.Recordset und
eine Excel.Range zu übergeben, aber bekomme jedesmal die Meldung "Invalid
procedure call or argument".
Hat jemand ne ahnung wo da der Fehler steckt, oder wie ich das ganze
einfacher machen kann?
PS: Ich brauch nicht das ganze Sheet, sondern nur definierte Felder
Mark Doerbandt
* Mirco Wilhelm (Do, 13 Nov 2003 09:57:44 GMT):
> objExcelSheet.Range(strExcelRange).Copy
> Alles was ich jetzt also noch schaffen muss ist diese Ausgabe in
> einen Recordset zu uebertragen.
Ohne es getestet zu haben: probier doch statt .Copy mal
.CopyToRecordset ...
Gruss - Mark
--
Informationen fuer Neulinge in den Access-Newsgroups unter
http://www.doerbandt.de/Access/Newbie.htm
Bitte keine eMails auf Newsgroup-Beiträge senden.
Mirco Wilhelm
>
> * Mirco Wilhelm (Do, 13 Nov 2003 09:57:44 GMT):
>
> > objExcelSheet.Range(strExcelRange).Copy
>
> > Alles was ich jetzt also noch schaffen muss ist diese Ausgabe in
> > einen Recordset zu uebertragen.
>
> Ohne es getestet zu haben: probier doch statt .Copy mal
> .CopyToRecordset ...
>
> Gruss - Mark
>
Auswahl
MfG
mirco
Mark Doerbandt
* Mirco Wilhelm (Do, 13 Nov 2003 12:16:25 GMT):
>> .CopyToRecordset
> gibt aber leider nur .CopyFromRecordset
Sorry - ich hatte das dunkel in Erinnerung, habe vorhin gegoogelt und
auch bei CopyToRecordset Treffer gehabt. Aber offenbar habe sowohl ich
als auch der betreffende Poster sich getaeuscht. :-(
Gruss - Mark
Mirco Wilhelm
Jep, hab mal nachgesehn... CopyToRecordset gehört wohl zu Powerpoint
Objekten, hilft mir bei Excel aber leider dann überhaupt nicht.
Aber es muss doch ne Möglichkeit geben, diesen Excel.Range irgentwie an nen
bestimmten Datentyp zu übergeben.
hab auch schon versucht das ganze ins Clipboard zu schreiben und dann mit
.Paste in ne Variant Variable zu schreiben :-)
...ging aber leider auch nicht.
MfG
mirco
"soviele Funktion und Methoden... und keine geht"
Jürgen Volke
>>
>>>> .CopyToRecordset
>>
>>> gibt aber leider nur .CopyFromRecordset
>>
>> Sorry - ich hatte das dunkel in Erinnerung, habe vorhin gegoogelt und
>> auch bei CopyToRecordset Treffer gehabt. Aber offenbar habe sowohl
>> ich als auch der betreffende Poster sich getaeuscht. :-(
>
> Jep, hab mal nachgesehn... CopyToRecordset gehört wohl zu Powerpoint
> Objekten, hilft mir bei Excel aber leider dann überhaupt nicht.
>
> Aber es muss doch ne Möglichkeit geben, diesen Excel.Range irgentwie
> an nen bestimmten Datentyp zu übergeben.
>
> hab auch schon versucht das ganze ins Clipboard zu schreiben und dann
> mit .Paste in ne Variant Variable zu schreiben :-)
>
> ...ging aber leider auch nicht.
dir bleibt immer noch die Möglichkeit mittels Laufschleife und
Cells-Eigenschaft an die Daten ran zu kommen.
HTH Jürgen
Mirco Wilhelm
haben will.
Sinn der Sache ist, das ich der Funktion den Dateinamen, Startfeld, Endfeld
und Sheetnummer mitgebe und die Inhalte der Range als Recordset
zurückbekomme die ich dann bestimmten Feldern einer Access Tabelle zuordnen
kann.
Bei der Aktion gehts darum, das ich 3 verschiedene Excel Formulare in massen
importieren muss, aber jeweils nur bestimmte Felder eines Formulars (z.B.
C14:H23) brauche die anschließend in die Spalten 1,3,4,6,8,23 der Access
Tabelle geschrieben werden.
Da sich Formulare auch gerne mal ändern brauche ich also ne Funktion die
allgemeingültig ist, und dann von den Formular-Funktionen genutzt wird.
Bis jetzt sieht das Teil so aus:
--------------------------------------------------------------------
Public Function GetRSFromExcel( _
ByVal strExcelFile As String, _
ByVal strFirstFieldID As String, _
ByVal strLastFieldID As String, _
ByVal intExcelWorksheet As Integer) _
As ADODB.Recordset
On Error GoTo GetRSFromExcel_Error
Dim objExcel As New excel.Application
Dim objExcelWorkbook As excel.workbook
Dim objExcelSheet As excel.Worksheet
Dim objStream As ADODB.Stream
Dim rsExcelRange As excel.Range
Dim i As Integer
Dim strExcelRange As String
' open excel file
Set objExcelWorkbook = objExcel.Workbooks.Open(strExcelFile)
Set objStream = New ADODB.Stream
objStream.Type = adTypeText
' make invisible and block userinput
objExcel.Visible = False
objExcel.Interactive = False
' set reference to a worksheet
Set objExcelSheet = objExcelWorkbook.Sheets(intExcelWorksheet)
' disable display refresh
objExcel.ScreenUpdating = False
' read recordset
strExcelRange = strFirstFieldID & ":" & strLastFieldID
objExcelSheet.Range(strExcelRange).Copy rsExcelRange
GetRSFromExcel = rsExcelRange
' activate display refresh
objExcel.ScreenUpdating = True
' activate user input
objExcel.Interactive = True
objExcelWorkbook.Close
objExcel.Quit
' destroy object references
Set objExcelSheet = Nothing
Set objExcel = Nothing
Exit Function
GetRSFromExcel_Error:
End Function
--------------------------------------------------------------------
der Fehler taucht bei diesem Aufruf auf
objExcelSheet.Range(strExcelRange).Copy rsExcelRange
das .copy gibt mir die Möglichkeit entweder das Ergebnis ins Clipboard zu
schreiben oder einer Destination Variablen zu übergeben... ich finde aber
keine Hinweise auf den Variablentyp.
Michael Zimmermann
Mirco:
> Ich versuche eine Excel Worksheet Range in ein Access
> Recordset zu importieren ...
Obwohl ich ADO eher pfui finde, mach es so:
Dim cn As ADODB.Connection
Dim rs As ADODB.Recordset
Dim tConnect As String
tConnect = "C:\DeinPfad\DeineMappe.xls"
Set cn = New ADODB.Connection
cn.Provider = "Microsoft.Jet.OLEDB.4.0"
cn.ConnectionString = "Data Source=" & tConnect & ";" & _
"Extended Properties=Excel 8.0;"
cn.Open
Set rs = New ADODB.Recordset
rs.Open "SELECT * FROM [Tabelle1$A1:C10]", cn
' ^nicht übersehen!
'Bereich Tabelle1 A1 bis C10
'Drei Felder A-C
rs.MoveFirst 'Beachte, daß Zeile 1 die Feldnamen sind!
MsgBox rs.Fields(0).Value 'A2
MsgBox rs.Fields(1).Value 'B2
MsgBox rs.Fields(2).Value 'C2
rs.MoveNext
'...
'9(!) Datensätze
rs.Close
Set rs = Nothing
cn.Close
Set cn = Nothing
Gruß aus Mainz
Michael
Mirco Wilhelm
Hmmm... also ich bekomme da ne "Could not find installable ISAM " Meldung...
Brauch ich da ein spezielles Referenz Modul?
Michael Zimmermann
> Hmmm... also ich bekomme da ne "Could not find installable
> ISAM " Meldung...
Möglicherweise hast Du die Treiber beim Setup nicht
installiert. Schau mal in Access-FAQ 7.10 www.donkarl.com
oder MSDN Q283881. Wenn die Treiber richtig installiert
sind, funktioniert das Verfahren ohne Probleme.
Gruß aus Mainz
Michael
Peter Steimann[MVP Access]
"Michael Zimmermann" <Zimme...@SZWeb.de> schrieb im Newsbeitrag
news:bp04s4$1ilf38$1...@ID-28927.news.uni-berlin.de...
> Hallo, Mirco!
>
> Mirco:
> > Ich versuche eine Excel Worksheet Range in ein Access
> > Recordset zu importieren ...
>
> Obwohl ich ADO eher pfui finde, mach es so:
>
Und warum bitte ist ADO pfui?
Gruss
Peter
Michael Zimmermann
> > Obwohl ich ADO eher pfui finde, mach es so:
> Und warum bitte ist ADO pfui?
Ich habe nicht gesagt, daß es pfui *ist*, sondern daß
ich es *eher* pfui *finde*:
- DAO bildet das Objektmodell der Jet-Engine besser ab
- DAO ist auf Jet wesentlich schneller
- Für einige Funktionalitäten muß ich noch eine Bibliothek
einbinden (ADOX)
- Access-interne Recordsets gebundener Formulare sind
DAO. Beim Umstellen auf ADO sind sie read-only
- Das ADO-Objektmodell ist mir zu "weich". Ich vermisse
klare Objekthierarchien und mag die vielen
Syntax-Varianten für dieselbe Funktionalität nicht.
- Ich kann bei DAO fast alles auswendig ;-)
Ich verwende ADO natürlich bei SQL-Server oder MSDE-
Zugriffen. Es gibt auch sonst die eine oder andere
erfreuliche Sache (ungebundene Recordsets, hierarchische
Recordsets) sowie das relativ einfache Ansprechen
verschiedenster Datenquellen über Provider-Strings,
aber access-intern bin ich nunmal eingefleischter
DAOist.
Gruß aus Mainz
Michael
Josef Poetzl
Michael Zimmermann schrieb:
[...]
> aber access-intern bin ich nunmal eingefleischter
> DAOist.
Hieß der nicht Mao? ;-))
mfg
Josef
Michael Zimmermann
> > ... DAOist.
>
> Hieß der nicht Mao? ;-))
Auch eine Variante. Mich hat zu dem Wortspiel allerdings
der Taoismus inspiriert ;-)
Gruß aus Mainz
Michael
Mirco Wilhelm
> installiert. Schau mal in Access-FAQ 7.10 www.donkarl.com
> oder MSDN Q283881. Wenn die Treiber richtig installiert
> sind, funktioniert das Verfahren ohne Probleme.
Schau mer mal...
Ich hab für diese Datenbank:
Microsoft Visual Basix for Applications Extensibility 5.3
Microsoft ActiveX Date Objects 2.7 Library
Microsoft DAO 3.6 Object Library
Microsoft Office 10.0 Object Library
Microsoft Office Runtime 10.0 Library
Microsoft Excel 10.0 Object Library
Microsoft Word 10.0 Object Library
JET Expression Service Type Library
OLE Automation
Microsoft Calendar Control 10.0
Microsoft Graph 10.0 Object Library
MsoLang 1.0 Type Library
Microsoft OLE DB provider for OLAP Services connection dialog 8.0
Microsoft OLE DB Service Component 1.0 Type Library
aktiv.
(ja, isn großes DB Projekt)
... also met Jet, als da jetzt drin is hab ich nicht, außer der Microsoft
Jet and Replication Objects 2.5 Library, die bringt aber auch nix.
Die funktion bleibt jedenfall immer beim .open stehn
Set cnExcel = New ADODB.Connection
cnExcel.Provider = "Microsoft.Jet.OLEDB.4.0"
cnExcel.ConnectionString = "Data Source=" & tConnect & ";" & "Extended
Properties=Excel 10.0;"
cnExcel.Open
Ich geh mal davon aus, das der Connection String nciht ganz sauber ist.
Mirco Wilhelm
> - DAO ist auf Jet wesentlich schneller
> - Für einige Funktionalitäten muß ich noch eine Bibliothek
> einbinden (ADOX)
> - Access-interne Recordsets gebundener Formulare sind
> DAO. Beim Umstellen auf ADO sind sie read-only
> - Das ADO-Objektmodell ist mir zu "weich". Ich vermisse
> klare Objekthierarchien und mag die vielen
> Syntax-Varianten für dieselbe Funktionalität nicht.
> - Ich kann bei DAO fast alles auswendig ;-)
>
> Ich verwende ADO natürlich bei SQL-Server oder MSDE-
> Zugriffen. Es gibt auch sonst die eine oder andere
> erfreuliche Sache (ungebundene Recordsets, hierarchische
> Recordsets) sowie das relativ einfache Ansprechen
> verschiedenster Datenquellen über Provider-Strings,
> aber access-intern bin ich nunmal eingefleischter
> DAOist.
Ich nehm auch gern ne DAO, wenn jemand ne passende Lösung hat
MfG
mirco
"Hauptsache das funzt bis Montag"
Peter Steimann[MVP Access]
"Mirco Wilhelm" <mir...@msn.com> schrieb im Newsbeitrag
news:uoEZQThq...@tk2msftngp13.phx.gbl...
Ich würde mich erstmal für eines von beiden entscheiden. In Deinem Falle
ADO, und den Jet-Treiber rausnehmen. Auch OLE-Automation wirst Du kaum
brauchen.
Ein Mix DAO/ADO macht nicht nur keinen Sinn, sondern macht Access
manchmal doch sehr wirr-;)
Gruss
Peter
Michael Zimmermann
> > Möglicherweise hast Du die Treiber beim Setup nicht
> > installiert. Schau mal in Access-FAQ 7.10
> > www.donkarl.com
> > oder MSDN Q283881. Wenn die Treiber richtig installiert
> > sind, funktioniert das Verfahren ohne Probleme.
Hast Du das gelesen?
> Ich hab für diese Datenbank:
[Liste der Projektverweise]
Das hat mit dem ISAM-Treiber *nichts* zu tun. Ich vermute,
Du hast beim Office-Setup die ISAM-Treiber einfach nicht
mitinstalliert. Du mußt also noch einmal ein Setup
(Office-Installation; Office-CD einlegen etc.) laufen
lassen.
In Deinen Projektverweisen wirst Du davon nichts sehen,
aber es wird trotzdem laufen. ;-)
> Set cnExcel = New ADODB.Connection
> cnExcel.Provider = "Microsoft.Jet.OLEDB.4.0"
> cnExcel.ConnectionString = "Data Source=" & _
> tConnect & ";" & "Extended Properties=Excel 10.0;"
^^
Das habe ich so nicht geschrieben. Dort muß 8.0 stehen -
auch bei Excel 2000 und XP.
> Ich geh mal davon aus, das der Connection String nciht
> ganz sauber ist.
Der von Dir "verbesserte" nicht mehr. Aber der, den ich Dir
gepostet hatte, schon. Es ist auch kein
"Müßte-so-klappen"-Code, sondern in Excel 97, 2000, XP
getestet.
Also, mach mal eine Office-Wartungs-Installation und
wähle dabei die Excel-Datenbank-Treiber aus, so wie
es auch in der FAQ steht.
Gruß aus Mainz
Michael
Michael Zimmermann
> > > - DAO bildet das Objektmodell der Jet-Engine besser ab
> > > - DAO ist auf Jet wesentlich schneller
> > > - Für einige Funktionalitäten muß ich noch eine
> > > Bibliothek
> > > einbinden (ADOX)
> > > - Access-interne Recordsets gebundener Formulare sind
> > > DAO. Beim Umstellen auf ADO sind sie read-only
> > > - Das ADO-Objektmodell ist mir zu "weich". Ich
> > > vermisse klare Objekthierarchien und mag die
> > > vielen Syntax-Varianten für dieselbe
> > > Funktionalität nicht.
> > > - Ich kann bei DAO fast alles auswendig ;-)
> > >
> > > Ich verwende ADO natürlich bei SQL-Server oder MSDE-
> > > Zugriffen. Es gibt auch sonst die eine oder andere
> > > erfreuliche Sache (ungebundene Recordsets,
> > > hierarchische Recordsets) sowie das relativ
> > > einfache Ansprechen verschiedenster Datenquellen
> > > über Provider-Strings, aber access-intern bin ich
> > > nunmal eingefleischter DAOist.
Du wolltest das doch wissen - jetzt warte ich noch
auf eine Kritik Deinerseits ;-) Oder bist Du völlig
meiner Meinung?
Gruß aus Mainz
Michael
Michael Zimmermann
> Ich nehm auch gern ne DAO, wenn jemand ne passende Lösung
> hat
Dim db As DAO.Database
Dim rs As DAO.Recordset
Set db = OpenDatabase("C:\DeinPfad\DeineDatei.xls",False,
False, "Excel 8.0;")
Set rs = db.OpenRecordset("Tabelle1$A1:C10")
etc.
Du bekommst aber genau dieselben Probleme mit dem
ISAM-Treiber, wenn Du ihn nicht installierst.
Aber Peter hat recht: Du mußt Dich entscheiden ;-)
Gruß aus Mainz
Michael
Peter Doering
>> Möglicherweise hast Du die Treiber beim Setup nicht
>> installiert. Schau mal in Access-FAQ 7.10 www.donkarl.com
>> oder MSDN Q283881. Wenn die Treiber richtig installiert
>> sind, funktioniert das Verfahren ohne Probleme.
>
> Schau mer mal...
Der Blick in die FAQ (7.10) haette gereicht. Die Treiber findest du im
Setup im Untermenue Data Access.
Gruss - Peter
--
Ich beantworte keine Fragen per Email.
Mitglied im http://www.dbdev.org
FAQ: http://www.donkarl.com