Office: zwei Tabellen (unterschiedliche xls Dateien) vergleichen

Hast Du Dir das Beispiel von mir angeschaut? Die Sortierung der resultierenden Unionabfrage ist sicher etwas übersichtlicher als gemixte verschiedenfarbige Zeilen - vermutlich soll man mit dem Ergebnis auch noch arbeiten können.

 

Jaja, hab mir Dein Beispiel natürlich noch angeschaut. Hatte meins zeitgleich fertig und dann hab ich die Ergebnisse verglichen. Hab mittlerweile mein Bsp. Deinem noch etwas angenähert. Vermutlich wird die Liste sowieso noch mit einem Filter versehen, dann würde sowieso jeweils nur eine Farbe angezeigt werden. Nun bin ich aber auf ein neues Problem gestoßen. Nachdem das Ganze mit den Pilotdaten funktioniert hatte entsteht nun mit den aktuellen Projektdaten folgender Fehler:
Das Feld ist zu klein für die Datenmenge, die sie hinzufügen wollten. Versuchen Sie weniger Daten einzufügen.
Kannst Du damit was anfangen?
Prinzipiell müssten es eigentlich im Vergleich weniger geworden sein, da nun in der erste Tabelle anstatt 2100 nur noch ca. 390 Datensätze liegen. In der zweiten sind es nun ca. 160 anstatt 50.
Oder ist damit gemeint, dass eine, bzw. mehrere Zellen zu klein sind, um den dafür vorgesehenen Inhalt darin unterzubringen?

 

Mhh, scheint mit der 255 Zeichen Beschränkung zu tun zu haben. Kann ich das irgendwie umdefinieren? Ich mein, die Daten kommen ja selbst aus Excel, also scheint es dort auch funktioniert zu haben. Zudem erstell ich ja eine Hilfstabelle wegen der Keys und kopiere die Daten auch schlichtweg dorthin. Da funktioniert das Ganze ja auch.

Möglich wäre laut diverser Foren auch, dass sich die Datentypen unterscheiden. Bspw. einmal Int, einmal Double. Ist aber bei mir nicht der Fall, da ist alles Text. Könne nzwar Zahlen drin vorkommen, aber der Typ ändert sich ja nicht innerhalb einer Zelle.
Kann es evtl. sein, dass diverse Zeichen nicht auftreten dürfen? Die Schlüssel sehen nun nämlich ungefähr so aus:
A06ECa100/EFe-6090P

Also mit Slash und Bindestrich

 

Diesen Fehler kenne ich von Fällen, wo vermutlich die Abfrage zu komplex (für Jet) wurde - ist etwas irreführend.

Probiere mal meine Abfrage: Ich verwende keinen zusammengesetzten Schlüssel, sondern joine die beiden Schlüsselfelder gemeinsam. Mit Zeichenketten > 255 Zeichen in Abfragen habe ich keine wirklichen Erfahrungen, als Schlüssel sind Zeichenketten und insbesondere lange Zeichenketten jedoch schlecht geeignet - der Rechner kann mit Zahlen besser und schneller umgehen als mit "Textverarbeitung".

Die Sonderzeichen im Feldwert sollten nicht stören, die sind dort einfach nur Text.

Insgesamt hast Du es wohl mit dem Problem zu tun, dass Dein abgeleitetes Beispiel die Realsituation nicht richtig widerspiegelt und nun die Lösung nicht einfach übertragbar ist, vgl. #69.

 

Hallo Eberhard,
ich habe jetzt nochmal komplett Dein Beispiel verwendet, ohne Änderungen. Führt aber leider zu dem Gleichen Fehler. Binde ich Deinen Code ein, so kommt die Meldung direkt vor der Ausgabe des Recordset in das neue Sheet (das Sheet?).
Möglicherweise liegt es tatsächlich daran, dass mein Beispiel abstrahiert war, aber wie gesagt, auch mit den Pilot-Daten der Firma hat es funktioniert.
Leider wüsste ich auch nicht, wie ich es Dir besser beispielhaft darstellen soll, ohne Daten freigeben zu müssen.

 

Dann sollte es an den Daten liegen. Da alle Felder vom Typ Text sind, kannst Du eigentlich nur die Textlänge checken. Probiere mal pro Tabelle eine Testabfrage
Code:

 

Die Längenabfrage ergibt, dass kein Feld mehr als 256 Zeichen beihaltet. Irgendwie komm ich hier auf keinen grünen Zweig.
Hab mir überlegt, ich würde Dir auch die Original-Daten mal eben schicken, damit Du mal kurz schauen kannst, ob Dir auf die schnelle ein Fehler auffällt. Will ich allerdings nicht für alle Öffentlichkeit hier hochladen

 

Siehe PN.

 

Anmerkung: Ich habe die Hilfsblätter sowie den zusammengesetzten Key weggelassen und beziehe mich auf die Ursprungsdaten.

Da wollen wir doch mal sehen, ob wir die "unendliche" Geschichte mit einer Lösung zu Ende führen können. Die folgende Abfrage ließ sich mit den Testdaten laut #73 ausführen, nicht jedoch mit den Originaldaten, obwohl ich in den Originaldaten selber keinen Grund für ein Problem erkennen konnte:
Code:

Diese Abfrage ließ sich in Access ausführen, wenn die Exceltabellen importiert wurden (folglich Abfrage ausführbar), nicht jedoch, wenn sie direkt in Excel (DAO oder ADODB) oder in Access mit eingebundenen Exceltabellen ausgeführt wurde. Es erschien die Meldung: "[Microsoft][ODBC Excel Driver]: Das Feld ist zu klein für die Datenmenge, die Sie hinzufügen wollen. Versuchen Sie weniger Daten anzufügen."
Offensichtlich ist der genannte Treiber überfordert, nicht jedoch, wenn auf die rot markierten Kriterien verzichtet wurde.

Denkbare Auswege:
- Wechsel der Umgebung (nach Access?)
- Finden einer funktionierenden Verbindungsart Excel-SQL
- Finden eines funktionierenden ODBC-Treibers

Da Odin99 innerhalb der Excelumgebung verbleiben muss und Wege 2 + 3 mir derzeit nicht lösbar sind, habe ich mich für eine Zwischenspeicherung des Abfrageergebnisses ohne die gezeigten Kriterien entschieden. Dieses Zwischenergebnis wird dann mit einer zweiten Abfrage mit Kriterium (hoffentlich) auf das gewünschte Resultat reduziert. Der Code:
Code:

Das kritische Kriterium in der ersten Abfrage habe ich mit einem Dummykriterium (1=1, immer erfüllt) ersetzt.

@Odin99: Bitte noch den Hinweis umsetzen:
' ==> alle Formatierungen auf konkretes Sheet (oSh) beziehen!!
Es ist sicher fehlerunanfälliger, wenn sich Maßnahmen wie Formatierungen auf ein benanntes konkretes Arbeitsblatt beziehen statt wie bei Dir auf das gerade aktive.

 

Hallo Ebs,
Ich habe, wie von Dir geraten die Formatierungen auf das konkrete Tabellenblatt oSh bezogen. Alles kein Problem. Das Problem, welches bei Deinem Code auftritt ist folgendes:
"Das Datenbankmodul kann 'Temp$' nicht finden. Stellen Sie sicher...". Man kennt den Fehler ja.
Das Tabellenblatt Temp ist allerdings bereits erstellt und befüllt.
Ich habe, wie angekündigt, das ganze zunächst so gelöst, dass ich hinterher einen Filter einbaue und die Daten dann lösche (Filter: Hauptkunde = 'Nein' => löschen).
Also wohl noch kein 'Ende' in Sicht (welch Wortwitz).

 

Hallo Ebs,
endlich hab ich wieder Zeit gefunden an meinem Makro zu arbeiten, nachdem ich zwischenzeitlich anderweitig beschäftigt war. Für das oben genannte Problem habe allerdings immer noch keine Lösung gefunden. Weißt Du woran das liegen könnte (also das Problem, nicht die Tatsache, dass ich keine Lösung finde).
Gruß Odin

 

Siehe #84. Ich hätte gedacht, ein funktionierendes Beispiel hingelegt zu haben.

Falls sich von Dir das Beispiel nicht auf die Realität übertragen lässt oder die Realität Umstände enthält, die im Beispiel nicht nachgebildet sind - was folgt daraus?

 

Haben soweit keinen Neuerungen. Immer noch das gute Alte Beispiel. Dein Code hat beim ersten Versuch bereits nicht funktioniert, weil - wie gesagt - das bereits erstellte und befüllte Tabellenblatt 'temp$' nicht gefunden werden konnte.
Scheinen wohl die kleinen Unterschiede zwischen Access und Excel zu sein.
Aber wissen tu ichs natürlich nicht, da ich ja ausschließlich mit Excel arbeite

 

Hab das Problem mittlerweile gelöst. Man muss dem gesamten befüllten Tabellenbereich einen Namen zuweisen (hier z.B. 'temp'). Die Abfrage bezieht sich in diesem Falle wohl nicht auf ein Tabellenblatt, sondern auf einen benannten Bereich, daher konnte 'temp' nicht gefunden werden