datentransfer excel/access -->recordsetdaten falsch!?!
 

hi! hab ein sehr vereinfachtes beispielprogramm im anhang, wo ihr das ganze testen könnt!
ausführen über den button oben in der menüleiste!

mein problem:
wenn ihr das excel file aufmacht, dann könnt ihr sehen das in der spalte wo volumen steht in der 3. zeile mit daten, eine zahl steht..
diese wird jedoch nicht korrekt importiert mit dem recordset!
das tritt jedoch nur auf, wenn als erster datensatz "#N/A ND" eingetragen ist!

ich will jedoch trotzdem die zahlen darunter korrekt importieren!
wenn man beim modul die werte des recordsets überwacht, dann sieht man dass bei der zahl, also beim 3. durchlauf kein wert drinnen steht!
warum?

wie kann ich das lösen dass ich auch die zahlen importieren kann?

keiner ne ahnung warum beim ersten zahlenwert beim bsp kein wert mehr im recordset steht?

bug von excel oder access?

oder gibts ne logische erklärung dafür?

Das Problem ist der Datentyp. Wenn in der ersten Zeile ein String steht nimmt ADO an, dass es sich auch beim Rest um Strings handelt. Wenn jetzt Excel auf einmal einen anderen Datentyp übergibt ist das natürlich übel :p

Eine Möglichkeit wäre, die Spalte als Text zu formatieren und erst in Access eine Unterscheidung zwischen Zahlenwert und Text zu treffen.
Allerdings zeigt dir dann Excel in der Spalte bei jeder Zahl einen Fehler an ("Zahl als Text gespeichert" oder so ähnlich). Stört zwar nicht wirklich, ist aber auch nicht besonders schön.

Ich hab' dir jetzt ein Beispiel mit einer versteckten Spalte gemacht, in der die Inhalte der angezeigten VOLUME-Spalte gänzlich als Text wiedergegeben werden.

have fun :cool:

thx einmal vorerst!

also das ganze wäre ne möglichkeit!

jedoch muss das ganze automatisiert ablaufen..

dh ich lasse dann im fertigen "programm" den benutzer eine excel datei auswählen, und diese hat dann im groben das format was ich mitgeschickt habe..

du hast ja im lösungsvorschlag in excel selbst das ganze definiert so wie ich das sehe stimmts?

gibts ne möglichkeit das ganze auch von access aus, in excel vorher so zu formatieren, dann zu importieren, und eventuell wieder zurückformatieren nach dem import?

wenn das möglich ist, und du mir da ne kleine hilfestellung bzw anleitung geben kannst, wie ich das ganze von access aus in der excel datei umformatieren kann wäre das echt hilfreich!

schonmal danke im voraus auch wenn du nicht weisst wie es geht bzw wenns überhaupt nicht geht..

Möglich ist alles :D
Da aber viele Wege nach Rom führen gibt's eben das Problem welchen man wählen soll. Eine Möglichkeit wäre ein Export aus Excel ins CSV-Format, was ja per Automatisierung kein Problem sein dürfte. In der resutlierenden Textdatei müsste man dann noch eine kleine Änderung vornehmen indem man die hier fett markierten Teile löscht:

-----------------------------------------------------
RIC;ARNT.TA;;
;;;
available fields;DATE,CLOSE,OPEN,HIGH,LOW,VOLUME;;
fields;DATE;CLOSE;VOLUME
data;26.09.2002;8,9;#N/A ND
;25.09.2002;8,9;#N/A ND
;24.09.2002;8,9;46
;23.09.2002;8,9;327
;22.09.2002;8,9;#N/A ND
;21.09.2002;#N/A ND;#N/A ND
;;;
;;;
;;;
;;;
;;;
-----------------------------------------------------

Danach müsste ADO (wenn ich mich nicht täusche) alle Fields im Format Text übernehmen. Die Umwandlung kannst du ja dann im VB vornehmen.

Die einfachste Möglichkeit wäre natürlich, die betreffende Spalte in Excel schon von Haus aus im Format 'Text' anzulegen. Du bekommst dann zwar diese kleinen grünen Dreiecke für die angeblichen Fehler angezeigt aber das dürfte zu verschmerzen sein.

Du könntest auch versuchen die Connection darauf zu trimmen, das korrekte Format zu erkennen, sprich mehr Angaben zu machen (Properties). Wenn man einen Datei-DSN erstellt, dann kann man auch die Anzahl der zu scannenden Zeilen angeben. Das wirkt sich dann auch auf den erkannten Datentyp aus. Allerdings könntest du dann wahrscheinlich nie ganz sicher sein ob der Datentyp wirklich der richtige ist. Ein DSN für deine aktuelle Beispieldatei würde im Texteditor so aussehen:

-----------------------------------------------------
[ODBC]
DRIVER=Microsoft Excel-Treiber (*.xls)
UID=admin
UserCommitSync=Yes
Threads=3
SafeTransactions=0
ReadOnly=1
PageTimeout=5
MaxScanRows=10
MaxBufferSize=2048
FIL=excel 8.0
DriverId=790
DefaultDir=C:\DOKUMENTE UND EINSTELLUNGEN\PFARRENT\DESKTOP\beispiel
DBQ=C:\DOKUMENTE UND EINSTELLUNGEN\PFARRENT\DESKTOP\beispiel\rictest.xl s
-----------------------------------------------------

Falls du mit den Vorschlägen auch nicht weiterkommst, melde dich einfach nochmal. Irgendwas wird schon passen ;)

Muss mich auch mal zu Wort melden. (nachdem ich jetzt auch indirekt mit seinem Problem betraut bin - bzw. ich helf ihm dabei ;))

Das was ich da gequotet habe, hamma heute auch schon kurz probiert. (nachdem ich dein voriges Posting gelesen hab - und das Beispiel sag is mir das eingefallen)
Is aber in der Kürze noch nicht rund gelaufen.

Ich wollt dann versuchen, den Range über die Zellen zu ziehen und dann alle Zellen auf Text setzen - die grünen Dreicke sind egal, weil das Dokument sowieso nur im Hintergrund geöffnet wird.

Nur hats mit dem Import noch nicht ganz so funktioniert - wir wissen noch nciht woran es liegt - wir werden es uns am Montag anschaun.

Wer ma dann eh sehen, ob wir was zusamemnbringen oder nicht. :)

jo stimmt was der llr da sagt, und ich will noch hinzufügen, bzgl dem vorschlag von dir mit der csv datei..

das würde vielleicht ein kleines problem geben, da ich nicht hundet prozentig voraussagen kann wie die datei aussieht.. sie kann sich mal ändern und bissl anders ausehen..

fix vom format her ist:
das "ric" in der selben zeile wie die titel sprich "arnt.ta" steht!
dann ist noch vorgabe, das in der zeile mit fields, die attribute stehen, welche sich auch teilweise abändern können.. bei manchen gibt es ein volumen beim anderen nicht..
und in der zeile "data" fangen die daten zum einlesen an..
in der "echten" exceltestdatei, zb ist eine zeile abstand zwischen den attributen und den daten..

was es vielleicht etwas schwierig beim rauslöschen der störenden daten in der csv datei macht..

weil ich ja zb auch immer die titel brauche, und wenn ich jetzt alles in ne csv datei kopiere, und dann solche sachen rauslösche, eventuell nicht mehr unterscheiden kann welchen titel ich da jetzt hab bzw wo das ende des einen und der anfang des nächsten ist!


wir probiern jetzt mal die möglichkeit das ganze in der excel datei zu ändern, und dann eventuell wieder in das ursprüngliche format zu bringen.. mal schaun was wir da reißen ;)

Ich nehme mal an, ihr habt in einer bestehenden Excel-Datei eine Spalte mit Zahlen einfach auf Text umformatiert. Das allein genügt aber noch nicht. In diesem Fall müsste man noch vor die Zahl ein Hochkomma ' schreiben. Nur wenn die Zelle schon beim Eintragen der Zahl das Format Text besitzt wird die Zahl auch automatisch als Text behandelt.
Es würde also nur bei bestehenden Dateien ein Problem bestehen das sich aber mit einem einfachen Makro aus der Welt schaffen ließe.

Ich habe übrigens herausgefunden, dass man die angezeigten Fehlerwarnungen auch ausblenden kann. (Extras/Optionen/Fehlerüberprüfung)

hmm, schas ;)

Bist dir da ganz sicher?

Weil es geht darum, dass in der Excel Tabelle Daten von einem "Kunden" stehen die von Access aus importiert werden müssen. (nur falls der maxmustermann das nicht eh schon geschrieben hat ;))

Drum können wir in dem Excel Sheet händisch nix umändern - das muss das Programm machen.

Aber eine Idee is mir noch als "letzter Ausweg" gekommen - das ganze "zu Fuß" über Range("A2").Formula den Wert auslesen und dann in die DB schreiben - dann ersparen wir es uns ADO auszutricksen (so mach ich das eigentlich immer wenn ich direkt in Excel ein Makro screib)

was aber bei einigen tausend feldern performance mäßig nicht so gut sein wird sag ich mal..


hätte dir im anhang mal die datei mitschicken wollen, wie sie dann im original aussieht, also das excel file, aber leider is es selbst mit winrar und winzip noch bissl zu groß.. naja is ja auch nicht so wichtig..

Jetzt sag aber bloss nicht, dass du den Kunden erlaubst die Excel-Files selbst zu erstellen!!!
Die sollen gefälligst eine Vorlage nehmen die du Ihnen zukommen lässt. Warum sollst du dich mit den Unzulänglichkeiten von Usern ärgern wenn schon die Softwaretools genug Macken haben?

Wenn du in einer Vorlage die betreffenden Spalten von Haus aus als 'Text' definierst und die Kunden dann in diese eintragen, hat sich das Problem erledigt. Falls wirklich noch alte Files aufgearbeitet werden müssen kann man als Übergangslösung sicher auch mal einzeln ein Programm oder Makro drüberlaufen lassen das die Sache behebt. Besser der Computer arbeitet nachts mal ein paar Stunden, als du verbringst unnötige Zeit vor'm Schirm (es sei denn du wirst nach Zeit bezahlt :D)

tja, die einzige "Bezahlung" die wir erhalten, is der Abschluss eines Maturaprojekts... ;)

Und das mit dem Makro glaub ich nicht, dass der das so gern hätte. Bzw. muss dir da der maxmustermann sagen was die Aufgabenstellung war, da ich erst seit dem Troubleshooting bei dem einen Modul dabei bin. :)

Aber is der Zugriff direkt auf die Zellen wirklich so viel langsamer als mit einem "Excel-Recordset"?
Weil das hab ich vorher noch nie gesehen/verwendet und weiß auch nicht was der da im Hintergrund alles werkelt um das ganze als Recordset aufzubereiten.

das excel file wird soweit ich weiss von einer seite im web runtergeladen..

also das is so ne seite für aktien..

da kann man dann glaub ich auswählen welche aktien man will, und dann wird ein excel file erstellt.. das man runterladet.. oder irgendwie so =)

weiss ich auch ned so genau.. ich weiss nur das ich das file halt dann so bekomm

Im Prinzip wird die Zugriffsart ziemlich egal sein. Die Geschwindigkeit wird sicher nicht so niedrig sein, dass sich daraus ein Problem ergibt. Wie gross der Unterschied wirklich ist könnte ich jetzt auf Anhieb aber nicht sagen. ADO bietet aber jeden Fall den Vorteil eines sehr komfortablen Handlings der Daten.

Da in eurem Fall die Daten aber eben leider in einer ziemlich ungeeigneten Form vorliegen, lässt sich die Verwendung anderer Hilfsmittel durchaus argumentieren.
Die Möglichkeiten bei Verwendung von Automatisierung oder DDE sind ja auch nicht zu verachten. Wenn man sich mit einem dieser Hilfsmittel eine kleine Klasse für den Datenzugriff schreibt, dann kann man bestimmt auch ganz passabel mit den Daten arbeiten.

wie was wann wo? ;)

Könntest du ev. ein kleines Beispiel bauen? Weil das was du oben geschrieben hast übersteigt meine VB Kenntnisse (hab mir noch nie eine eigene Klasse bauen müssen, und weiß eigentlich auch nicht wie das geht)

Falls du dazu kommst, dank ich dir schon mal - weil dann lern ich wieder was neues dazu. :)
Kannst es natürlich auch im "nativen" VB (=6.0) schreiben, geht warhscheinlich schneller als wenns dir eine Access DB mit VBA Code baust.

Naja, wie auch immer, ich bedank mich jetzt schon mal, mfg, LLR

hi

ich komme hier ziemlich spät rein, und vielleicht habe ich beim durchlesen irgenwas übersehen oder falsch verstanden.

hat schon jemand überlegt, die excel-datei über vba-code in der access-db zu formatieren?
besser noch eine kopie, die kann man nachher löschen, und das original bleibt unangetastet.

der code für die verwendung von excel als object in access dürfte nicht so kompliziert sein. ich habe sowas einmal in einem vb6 projekt gemacht.
auf den code zum manipulieren der excel-datei kommt man leicht, wenn man in einer testdatei die gewünschte aktion als makro aufzeichnet.

vielleicht bringt euch das ja weiter.

WB

also der code um excel als objekt zu verwenden is wirklich nicht das problem..
das haben wir schon gemacht, nur ist dieser vorgang meiner meinung nach bissl umständlicher als einfach einen recordset über ado in einem bestimmten bereich zu definieren.. zumindest bei dem teil des moduls..

ich werd morgen mal testhalber das ganze mit der objektmethode versuchen und anschliessend mit der ado recordset methode..

mal sehen wie groß der zeit unterschied ist!

das mit dem bearbeiten der excel datei aus dem vba-code heraus geht auch nicht wirklich, da die feldtypen schon bestimmt sind, sobald was drinnen steht..

die müssen vorher definiert sein.. zumindest soweit ich das verstanden hab! sonst funkt das nicht, und ich hab das prob warum der beitrag überhaut entstanden ist!

wie meinst das mit der kopie? ganz neue excel datei erstellen?

das was seidl vorgeschlagen hat, würd ich aber auch sagen könnten wir mal ausprobiern! nur ne kleine anleitung bzw bspcode wie llr schon erwähnt hat wäre da echt nicht schlecht =)

weil hab keine ahnung wie sowas geht..

ich kann dein beispiel nicht nachvollziehen, weil ich die passende version von office nicht habe.
in office 97 war ado noch kein thema, und ich bin von access überhaupt weg. (eben wegen der ständigen neuerungen, die inkompatibel mit der vorversion sind)

ich gehe aber davon aus, daß das problem nicht auftritt, wenn alle zellen als "text" formatiert sind. seidl hat da wahrscheinlich recht.

ich hab mir vorgestellt, der vba-code macht folgendes:

kopie der excel-datei erstellen

zellen in "text" umformatieren
falls umformatieren nicht reicht, oder nicht funktioniert, eine neue tabelle mit vorformatierten zellen erstellen, und daten übernehmen

daten importieren

kopie löschen

das kostet zwar etwas zeit, aber wenns funktioniert sollte das keine rolle spielen

WB

wäre auch ne möglichkeit..

aber erstmal abwarten was mit dem vorschlag von seidl mit der automatisierung und dde rauszuholen ist!

Hallo!

Ich werde heute am Abend versuchen ein kleines Beispiel zu coden.

danke.... :)

Sicher nicht perfekt aber es soll ja auch nur ein Beispiel sein.

hmm, danke.
Ich bin zwar noch nicht ganz so schlau draus geworden, aber ich werds mir vielleicht nochmal anschaun. :)

Inzwischen haben wir die Import-Funktion neu gecoded. Einfach direkt auf die Zellen zu gegriffen und dann geschaut was da drin zu finden ist.
Funkt 1A und ist mindestens genauso schnell wie über des ADO-Klumpat. ;)

Weil 3min für fast 14000 Datensätze aus Excel auf einem P3-650 sind finde ich ganz ok. :D (weil ja VBA bekannt langsam ist...)

Im Prinzip macht mein Beispiel nichts anderes. Man gibt einen Bereich vor aus dem die Daten gelesen werden sollen und diese werden dann in ein ADO-Recordset geschrieben welches zurückgegeben wird. Dadurch hat man dann trotz allem die Möglichkeiten von ADO zur Verfügung(filtern, sortieren, als XML speichern, Verwendung für DataGrid, ...)

das beispiel funktioniert leider nicht..

anwendungs- oder objektdefinierter fehler sagt er..

und das ganze passiert hier:
objExcelReader.ReadData Me.txtPath, Me.txtFirstCell, Me.txtLastCell


haben uns noch nicht wirklich damit auseinander gesetzt, aber hast du das ganze bei dir mal probiert? hats da funktioniert?

Na das find' ich ja mal elend :(
Da dürfte ich nach der letzten Änderung vergessen haben zu speichern. Jetzt habe ich die fehlende Änderung nochmal eingetragen und einen Testlauf gemacht:

- Mit 'Browse' die Exceldatei auswählen
- 'FirstCell' eintragen (Bereich links oben)
- 'LastCell' eintragen (Bereich rechts unten)
- Daten mit 'GetData' einlesen

Die Defaultwerte für FirstCell und LastCell passen auf euer Beispiel.