Office: (Office 2010) Dlookup mit MAX

So ist es. Auch bei selbsterstellten xls(x) werden beim Import nach Access die Datentypen abgeleitet. Da nutzt es auch nichts, wenn diese Ableitung kraft Registry-Einstellung auf allen Zeilen der xls(x) basiert. Denn ein Wert von z.B. 255 kann in verschiedene numerische Datentypen reingeboxt werden. Welcher davon richtig ist, kann das System nicht wissen; Byte mag ausreichen, das hat aber Folgen für z.B. weitere Verarbeitung (Rechenanweisungen, ETL-Prozese etc). Selbst eine Deutung als Text oder Datum wäre möglich.

Daten werden interpretiert. Und das mach ich lieber selbst bzw. habe die Kontrolle darüber.

Gegenfrage: warum tauscht man Daten überhaupt über xls(x) aus?

 

Danke mal für eure Tip's. Werde mal den Import überarbeiten. Werde sehen was ich daraus machen kann.
Gruß Gerhard

 

Vermutlich weil man den großen Hang danach hat, sich das Ganze auch noch einmal ansehen zu müssen - und Excel zu öffnen und sich dort eine Tabelle ansehen fällt vielen leichter als eine Textdatei zu öffnen und eine Texttabelle anzusehen.

Für den reinen Datenaustausch wäre eine CSV fraglos eleganter, schon weil die Datei an sich schlanker ist (Plaintext).

Na und. Meine Zieltabelle hat für den Wert einen vorhandenen Datentyp, und da passt der Wert hinein oder eben nicht. Für bekannte oder wahrscheinliche Fehler der Ausgangsdaten kann man eine Fehlertoleranz einbauen, z.B. wie oben gezeigt eine Typumwandlung.

Absolute Sicherheit bietet der Umweg über CSV (sicherlich ein guter Umweg) nun auch nicht. Wenn ein "Kreativkopf" irgendwo in einer Zahlenspalte dann doch Texte einbaut, kriegst Du auch da Fehler.

Auf der anderen Seite ist permanentes Prüfen auch aufwändig und in vielen Fällen unangemessen, da man Prüfungen meist im Bereich eigener Erfahrungen vermindern oder gar unterlassen kann. Um seine Mutter zu erkennen, braucht man sicher nicht einen stündlichen DNA-Test, sondern wenn man sie sieht, ist sie es auch.
Es ist nun auch eine Erfahrung, dass ein Import per TransferSpreadsheet in sehr vielen Fällen gut gelingt, sonst gäbe es eine solche Standardfunktionalität nicht in dieser Form.

@gery: Im Zweifelsfall zeigst Du mal eine solche Excelmappe und schilderst, was Du eigentlich mit den Daten machen willst.

 

Nicht alles, was Access von sich aus anbietet, ist gut (Nachschlagefelder, Mehrfachwertfelder etc)....

Das ist klar, aber immerhin kann ich eine CSV in eine Puffertabelle mit ausschließlich Textfeldern importieren und domit prüfen, ob überall brauchbare Werte drinstehen. Mit einer xls(x) wird das aufwendiger, weil die Werte da interpretiert werden und erst das Ergebnis in die Text-Tabelle reinkäme. Da ist das Kind evtl. schon in den Brunnen gefallen.

Wir kommen wohl nicht überein *Smilie ich halte Excel grundsätzlich nicht für einen tauglichen Datentransferweg, du schon. Excel ist "schön" für menschliche Augen und Controllerhirne, aber nicht für Datenaustausch.

 

Wenn diese Aussage konsequent verfolgt wird, ist dann der Weg Excel -> CSV -> Datenbank dann auch nicht tauglich und wäre dann keine Lösung für den Fragesteller. "Grundsätzlich nicht tauglich" - d.h. daraus kann man überhaupt nichts machen.

Aber: Der Threadersteller hat nun mal eine Excelmappe und muss nehmen, was er hat. Das soll öfters vorkommen.

Als Hinweis: Im Excelforum habe ich einige Lösungen, wo pure Excelfragen über SQL gelöst wurden. SQL ist ja bekanntlich sehr empfindsam bei Datentypen. Dass so etwas gelingen kann und einem nicht um die Ohren fliegt, liegt u.a. daran, dass es durchaus Personen gibt, die Listen (saubere Tabellen) anlegen und verstehen können, wie auch viele mit der Begrifflichkeit Standardisierung etwas auch praktisch anfangen können.

Über das Zeugs, was Du ansprichst, denke ich nicht nach.
Grundfrage wäre aber: Funktionalitäten und Assistenten, die dem Bediener/Entwickler das Denken abnehmen und gewisse Aufgaben ausführen - sind die grundsätzlich schlecht und abzulehnen?
Wenn ich sage, der grafische Abfrageeditor von Access hat seine Macken und veranstaltet auch allerlei Unsinn, so nutze ich ihn doch trotzdem, weil er in vielen Lagen bequem und hilfreich ist. Dabei muss ich dann aber die Grenzen kennen und im Bedarfsfall umschalten, also dann eine ungewollte falsche Hilfe vermeiden.

 

Da stimme ich zu. Ich sehe die ungewollte Hilfe hier eben im Ableiten der Datentypen. Da ist mir der Excelimport zu übereifrig. Ein direkter Excelimport kann natürlich gelingen, aber es ist kein Verlass drauf, dass es klappt. Mit einem Import in eine Nur-Text-Tabelle habe ich mehr Einflussmöglichkeiten und kann Unsinniges auch gleich abweisen, bevor es weiterverabeitet wird.

"Personen (...), die Listen (saubere Tabellen) anlegen und verstehen können, wie auch viele mit der Begrifflichkeit Standardisierung etwas auch praktisch anfangen können" nutzen gleich ein RDBMS statt Excel. Excel als Datenhaltungstool ist was für Leute, die (noch) nicht strukturiert denken wollen und/oder RDBMS nicht kennen.

 

Ein wenig differenzieren sollte man schon. Damit eine einfache Mitgliederliste als Datenquelle für einen Serienbrief dienen kann, muss man nun nicht ersatzweise ein RDMS einsetzen, auch wenn man strukturiert denken kann und RDMS kennt und anzuwenden weiß. Man sollte schon reale Aufgaben und Anforderungen im Blick haben und nicht bei der Lösung in hohen Wolken schweben.

Als Datenhaltungstool werden die wenigsten eine Excelarbeitsmappe sehen. Da ist praktisch immer eine Datenverarbeitung und eine Darstellung von Daten und Ergebnissen vorhanden.

Excel kann eine ganze Menge. Das sollte man nicht vergessen. Im Zweifelsfall könnte man sich im Excel-Forum umschauen, was da so gelöst wird. Und Excel ist sehr intuitiv zu bedienen. Auch daran kommt man nicht wirklich vorbei.
Somit ist Excel (wie auch jedes andere Programm) nicht die ultimative Lösung für alle Fälle, aber eben auch nicht die absolute Katastrophe.

 

Hallo und danke nochmals für eure Hilfe. Als ich vom urlaub zurück kam, war ich sehr erstaunt über weitere Beiträge (Diskussion).*Smilie
Da ebs17 genaueres benötigt versuche ich es mal zu erklären.
Es geht im ganzen um Datenauswertungen aus dem SAP. Daher exportiere ich aus dem SAP die Daten in Xlm. Vielleicht ist dies auch schon mal ein falscher Ansatz? ich habe folgende Formate aus dem SAP: unkonvertiert, Tabellenkalkulation, RTF, HTML.
Die Tabellen die ich von Excel in Access importieren ist eine TEMP_Tabelle die wie ich schrieb keine Spaltenbeschriftung hat. ich öffne die Temp und übergebe die Daten in eine Tabelle. Dabei werden die Daten formartiert und überprüft ob der Datensatz schon vorhanden ist oder geändert wurde.
Ich ziehe jede Woche die Daten vom SAP, daher sollen neue Daten in meine Tabelle hinzugefügt werden und geänderte Editiert werden.
Bis jetzt gab es keine Probleme, jedoch betragen die Anzahl der DS über 100.000 schon. Mit den folgenden Code geht der import.
Code:

jedoch die Verarbeitung (Format, Abfragen) in andere Tabelle verursacht (keine Rückmeldung)friert ein. Kommt mit der Masse der DS nicht mehr zurecht?
Code:

So stellte ich es mir vor, aber nun bei diesen Datenmengen gehts nicht mehr.
Daher meine Fragestellung. Oder soll ich ein anderes Format verwenden, andere VBA Code?
Gruß Gerhard

 

Die im Eingangsbeitrag geschilderte Problematik kommt im Code nicht vor. Hast Du Dich anders entschieden?

Doch, der Code kommt schon noch zurecht, allerdings benötigt er durch die recht ungeschickte Gestaltung sehr sehr lange, so dass Du etwas mehr Geduld aufbringen musst oder besser eine optimalere Gestaltung wählen solltest.

Datensätze aus einer Tabelle in eine andere Tabelle überträgt man besser per Anfügeabfrage (Massendatenverarbeitung schlägt prozedurale Einzeldatenverarbeitung), die Berücksichtigung von nur neuen Datensätzen kann man über eine Inkonsistenzprüfung realisieren. Dann hättest Du vermutlich nicht mal die Zeit, Dir einen neuen Kaffee zu holen.
Code:

Wie oben vermerkt: Der Zwischenimport in eine Temp-Tabelle ist überflüssig (aber Aufwand, der auch Zeit kostet), weil man auf eine verknüpfte Exceltabelle genau so gut zugreifen kann. Eine Datenbanktabelle als Zwischentabelle macht dann besonderen Sinn, wenn man sie vor Verwendung geeignet indiziert und diese Indexierung nachfolgend nutzt.

Zur oben geführten Diskussion: SAP-Daten kommen aus einer Datenbank und sollten hinreichend standardisiert sein, um sie aus einer Exceltabelle verwerten zu können. Trotzdem wäre eine CSV als Datenüberträger geeigneter. Die Gründe wurden hinreichend genannt.
Eine Texttabelle (CSV) kann man genau so gut wie eine Exceltabelle importieren bzw. besser verlinken, und die Verarbeitung ist unproblematischer wegen der Möglichkeit der Verwendung von Spezifikationen, fehlender Eigendynamik zur Interpretation von Werten und schon mal durch die Tatsache, dass eine Textdatei schön schlank ist.

 

Vorerst danke für die Gedult. *Smilie
Du hast vollkommen recht, dies ist sehr umständlich aufgebaut.
Ich möchte deinen Vorschlag umsetzen. Als Export vom SAP habe ich nur "unconvertiert" zur Verfügung und die Datei wird mir als TXT gespeichert.
Ich suche mir einen Code zum Importieren einer Textdatei und melde mich wie mein Versuch ausging, da ich z.B. einige Zeilen nicht importieren möchte sondern nur die Kopfzeile und Daten. Das heist Zeile 1-6 nicht und die 8. nicht und die am Schluß nicht. Sieht schon wieder sehr kompliziert aus (Beispiel im Anhang).
Eine wahrscheinliche Dumme Frage. Wo ist der Unterschied zwischen einer TXT und CVS Datei? Sind nicht beide Textdateien?
Gruß Gerhard

 

Du meinst sicher TXT CSV?
Der Unterschied ist nur die Dateiendung, und dass eine Dateiendung CSV standardmäßig Excel als zugewiesenes Programm verwendet, siehe CSV - Trallallalla.

Für einen direkten Import, den ich bevorzuge, ist die gezeigte Datei sehr ungünstig. Da müsste man diese optischen Zeilen- und Spaltentrenner zusätzlich zu den ungewünschten Zeilen entfernen, ehe man wirklich importiert.

 

Hallo ebs17,
habe mir entschlossen es mit der CSV Datei zu machen.
Schnell geht es ja, jedoch nicht das was ich wollte. Nachdem ich
Code:

ausführte, erstellte er mir die tabelle, jedoch wurden die Semikole nicht Berücksichtigt und schrieb alles in die 1.Spalte anstatt auf die 57 Spalten aufzuteilen.
habe auch im Forum etwas über die Spezifikation gelesen nur wie oder was habe ich nicht verstanden. Wie erstellt man eine, wo wird die gespeichert usw.
In der Beschreibung von Access steht das diese Datei optional ist, daher hätte es mit dem Code funktionieren müssen.*upps
Gruß Gerhard

 

Anlegen einer Spezifikation. In >=Acc2007 sieht das wegen der Menüführung etwas anders aus.

Wer den guten "Handbetrieb" möchte: Importspezifikation einer DB in VB erstellen

Der Name der Spezifikation wäre dann als zweiter Parameter bei TransferText zu verwenden.

Hast Du denn jetzt eine ordentliche Standard-CSV? Die sähe etwa so aus (semikolongetrennt mit Headerzeile):
Code:

 

Sieht genau so aus.*wink.gif*
Danke für den Link, werde nun das für meine DB umschreiben und teile dir mit ob ich Erfolg hatte.
Gruß Gerhard

 

Hallo ebs17,
als erstes kann ich mich nicht genug bedanken für deine Unterstützung und hoffe mit deinem Rat entlich mal zur Endlösung zu kommen.
ich habe nun einiges durchgetestet und die Importlösung auf einfache weise wie du es vorgeschlagen hast umgesetzt.
Ich verlinke die csv Datei.
Code:

ich finde jedoch keine Lösung um die bestimmten daten in eine Tabelle zu speichern.
Bei Versuch die Import Verknüpfung mit openrecord zu öffnen und MoveFirst, MoveNext, benötige ich so viele Abfragen das Access wahrscheinlich über Nacht rechnen müsste. Habe mit Task geschlossen.
Der Code würde hier eine lange Liste ergeben und da sind nicht mal die erstellten Abfragen inbegriffen. Vielleicht ist die Lösung eigentlich einfach, aber ich wieder um vier Ecken denke. Daher ein Beispiel welche Daten (Datensätze) aus den 100.000 DS benötigt werden. Vielleicht denke ich auch in die falsche Richtung? Füge mal die Tabelle als HTML ein damit sie übersichtlich ist.

HTML:

Material	gültig bis	Status	bearbeitet	Pos
-----------------------------------------------------------
40002119 ´	17.01.2014	C	17.01.2011	1
40002119 	13.05.2018	C	18.01.2011	2
40002119 	17.01.2014	A	17.01.2011	5
40002119 	18.03.2016	A	18.01.2011	3
40002119 	17.01.2014	C	17.01.2011	4
140001061	23.04.2018	C	10.08.2012	1
140001061	08.01.2012	A	10.08.2012	2
140001061	08.01.2012	A	10.08.2012	3
140001061	17.01.2014	C	10.08.2012	4

Im Beispiel sind 2 verschiedene "Material" Nummern vorhanden und von jedem Material benötige ich den Datensatz.
Das heist vom Material 40002119 benötige ich einen DS und vom Material 140001061 einen DS. Benötigt wird derjenige bei dem :
"gültig bis" größer als das aktuelle Datum vom Material 40002119 ist.
"Status" muss "C" sein vom Material 40002119.
"bearbeitet" muss das höchste Datum vom Material 40002119
"Pos" muss der höchste Wert vom Material 40002119

Nun müsste ein DS exestieren, wenn "gültig bis" und "Status" zutrifft.
Und da bekomme ich falsche DS raus.

Aber es geht ja noch weiter da nun dieser DS in einer anderen Tbl gespeichert werden soll:
Dazu die Abfrage:
Ist das Material nicht vorhanden wird der DS gespeichert.
Ist das Material vorhanden jedoch "bearbeitet" ist > als in der Tabelle oder Pos > als vorhanden so wird Edit durchgeführt, ansonsten keine Aktion.

So sollte es ablaufen. Ich muss gestehen, das auch diese Abfragen zu komplex sind. Gehe ich vielleicht das ganze falsch an?
Ich würde mich schon mit ein paar Tip's begnügen und Dankbar dafür sein.
Gruß Gerhard