Vba. if then schleife stürzt nach etlichen durchgängen ab
Hallo an alle Experten für VBA-Makro!
Ich bin kein Spezialist für VBA und habe deshalb ein riesen Problem.
Ich habe den Quellcode schon mehrmals auf Fehler untersucht und stundenlang im Internet gegoogelt.
Problem ist folgendes.
Ich habe zwei Tabellen
Tabelle 1 mit 3800 Zeilen (Datensätzen)
Tabelle 2 mit 3100 Zeilen (Datensätzen)
Problem ist folgendes.
Ich habe zwei Tabellen
Tabelle 1 mit 3800 Zeilen (Datensätzen)
Tabelle 2 mit 3100 Zeilen (Datensätzen)
Nun will ich aus beiden Tabellen eine Tabelle erstellen, worin sich alle Datensätze befinden, die sowohl in Tabelle 1 als auch in Tabelle 2 vorhanden sind.
Ich lese zuerst die Daten aus Tabelle 2 ein, und suche ab Zeile 2 in Tabelle 1.
Wird der Datensatz in Tabelle 1 gefunden, kopiere ich diesen in Tabelle 3 und lösche ihn danach in Tabelle 1.
Nun suche ich ab der nächsten Zeile in Tabelle 1 weiter, ob es diesen Datensatz nochmals gibt.
Nachdem alle Datensätze in Tabelle 1 durchsucht wurden, wird kontrolliert, ob der gesuchte Datensatz in Tabelle 1 gefunden wurde.
Wenn ja, wird dieser Datensatz auch in Tabelle 2 gelöscht.
Alle drei Tabellen befinden sich in der gleichen Arbeitsmappe.
Nun, das Macro funktioniert langsam, aber gut.
LEIDER schmiert das Macro nach zirka 1900 Datensätzen ab.
Fehler 1004.
Der Hinweis, in Excel den Punkt "Zugriff auf Visual Basic-Project vertrauen" anklicken, nützt natürlich nichts.
Keine Zelle ist schreibgeschützt.
Teile ich die Tabelle2 mit den Quelldatensätzen, und vergleiche nur 1000, dann gibt es keinen Absturz.
Danach kann ich die nächsten 1000 zu vergleichenden Datensätze nehmen (inklusive dem Datensatz, der vorher 1900 war), und wieder ohne Absturz vergleichen.
Ich habe auch schon versucht, in der kompletten Tabelle 2 (mit 3800 Zeilen) nicht alle, sondern zuerst nur 1500 Datensätze zu vergleichen.
Ergebnis - KEIN Absturz
Danach ändere ich die Einstellungen (Beginn der ersten Zeile für Zieltabelle 3, die Anzahl der Datensätze in Vergleichstabelle 1) und starte das Makro wieder, wobei ich sicherheitshalber nur 200 Datensätze vergleiche.
Auf diese Art kann ich die komplette Tabelle ohne Absturz durchsuchen.
Nun, das ist erstens RECHT MÜHSAM und LANGWIERIG, und AUCH NICHT DER SINN EINES MACROS.
Da ich auf diese Art und Weise einen Programmierfehler ausschließen konnte, und es auch nirgends einen Typenkonflikt geben kann, frage ich mich, ob es IRGENDWO ein Speicherproblem mit Excel geben kann.
Ich kann auch ausschließen, das es am Betriebssystem oder am Arbeitsspeicher liegt.
Ich habe dieses Problem auf meinem Stand-PC mit Win-XP SP3 und 2GB RAM, DualCore Prozessor mit 3,33GHz
und auf meinem Laptop mit Pentium Dual-Core CPU T4500, 2,30GHz und 4GB RAM.
Bitte um Hilfe der Spezialisten
Danke im voraus
Gerry
Ich bin kein Spezialist für VBA und habe deshalb ein riesen Problem.
Ich habe den Quellcode schon mehrmals auf Fehler untersucht und stundenlang im Internet gegoogelt.
Problem ist folgendes.
Ich habe zwei Tabellen
Tabelle 1 mit 3800 Zeilen (Datensätzen)
Tabelle 2 mit 3100 Zeilen (Datensätzen)
Problem ist folgendes.
Ich habe zwei Tabellen
Tabelle 1 mit 3800 Zeilen (Datensätzen)
Tabelle 2 mit 3100 Zeilen (Datensätzen)
Nun will ich aus beiden Tabellen eine Tabelle erstellen, worin sich alle Datensätze befinden, die sowohl in Tabelle 1 als auch in Tabelle 2 vorhanden sind.
Ich lese zuerst die Daten aus Tabelle 2 ein, und suche ab Zeile 2 in Tabelle 1.
Wird der Datensatz in Tabelle 1 gefunden, kopiere ich diesen in Tabelle 3 und lösche ihn danach in Tabelle 1.
Nun suche ich ab der nächsten Zeile in Tabelle 1 weiter, ob es diesen Datensatz nochmals gibt.
Nachdem alle Datensätze in Tabelle 1 durchsucht wurden, wird kontrolliert, ob der gesuchte Datensatz in Tabelle 1 gefunden wurde.
Wenn ja, wird dieser Datensatz auch in Tabelle 2 gelöscht.
Alle drei Tabellen befinden sich in der gleichen Arbeitsmappe.
Nun, das Macro funktioniert langsam, aber gut.
LEIDER schmiert das Macro nach zirka 1900 Datensätzen ab.
Fehler 1004.
Der Hinweis, in Excel den Punkt "Zugriff auf Visual Basic-Project vertrauen" anklicken, nützt natürlich nichts.
Keine Zelle ist schreibgeschützt.
Teile ich die Tabelle2 mit den Quelldatensätzen, und vergleiche nur 1000, dann gibt es keinen Absturz.
Danach kann ich die nächsten 1000 zu vergleichenden Datensätze nehmen (inklusive dem Datensatz, der vorher 1900 war), und wieder ohne Absturz vergleichen.
Ich habe auch schon versucht, in der kompletten Tabelle 2 (mit 3800 Zeilen) nicht alle, sondern zuerst nur 1500 Datensätze zu vergleichen.
Ergebnis - KEIN Absturz
Danach ändere ich die Einstellungen (Beginn der ersten Zeile für Zieltabelle 3, die Anzahl der Datensätze in Vergleichstabelle 1) und starte das Makro wieder, wobei ich sicherheitshalber nur 200 Datensätze vergleiche.
Auf diese Art kann ich die komplette Tabelle ohne Absturz durchsuchen.
Nun, das ist erstens RECHT MÜHSAM und LANGWIERIG, und AUCH NICHT DER SINN EINES MACROS.
Da ich auf diese Art und Weise einen Programmierfehler ausschließen konnte, und es auch nirgends einen Typenkonflikt geben kann, frage ich mich, ob es IRGENDWO ein Speicherproblem mit Excel geben kann.
Ich kann auch ausschließen, das es am Betriebssystem oder am Arbeitsspeicher liegt.
Ich habe dieses Problem auf meinem Stand-PC mit Win-XP SP3 und 2GB RAM, DualCore Prozessor mit 3,33GHz
und auf meinem Laptop mit Pentium Dual-Core CPU T4500, 2,30GHz und 4GB RAM.
Bitte um Hilfe der Spezialisten
Danke im voraus
Gerry
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 184366
Url: https://administrator.de/contentid/184366
Ausgedruckt am: 19.11.2024 um 17:11 Uhr
19 Kommentare
Neuester Kommentar
Moin Moin,
nachdem ich so die Hälfte durchgelesen hatte und mir schon überlegte, dass man das mit z.B. Access ganz einfach lösen könnte, fand ich heraus, dass du von Excel sprichst. Leider ist die Version so geheim, dass Hilfe bzw. Aussagen hinsichtlich Abstürze etc. zumindest von mir nicht möglich sind.
ym2c
/edit
btw umständlicher geht es wohl nicht? Überdenke bitte mal dein Konzept.
/edit
Grüße aus Rostock
Wolfgang
(Netwolf)
nachdem ich so die Hälfte durchgelesen hatte und mir schon überlegte, dass man das mit z.B. Access ganz einfach lösen könnte, fand ich heraus, dass du von Excel sprichst. Leider ist die Version so geheim, dass Hilfe bzw. Aussagen hinsichtlich Abstürze etc. zumindest von mir nicht möglich sind.
Ich kann auch ausschließen, das es am Betriebssystem oder am Arbeitsspeicher liegt.
mutig, das sind zwei Aussagen, die ich nie und nimmer so behaupten würde!ym2c
/edit
btw umständlicher geht es wohl nicht? Überdenke bitte mal dein Konzept.
/edit
Grüße aus Rostock
Wolfgang
(Netwolf)
Hallo gerry56!
Da Du keinen Code gepostet hast, vermute ich mal, dass Deine Schleife abschmiert, weil der Schleifenzähler beim Löschen von Zeilen nicht entsprechend angepasst wird.
Gruß Dieter
Da Du keinen Code gepostet hast, vermute ich mal, dass Deine Schleife abschmiert, weil der Schleifenzähler beim Löschen von Zeilen nicht entsprechend angepasst wird.
Gruß Dieter
Moin Moin,
du könntest diesen Bandwurmsatz deaktivieren und testen, ob der Code dann durchläuft.
Du könntest dir die einzelnen Werte im Debugmodus ansehen um festzustellen, welcher (falsche) Wert dann den Absturz verursacht.
Tipp: teile den Bandwurmsatz mal in einzelne Teil-Sätze auf.
Die Office 2003 Version war bekannt für Ihre Speicherlecks bei größeren Aktionen. Die Problematik der Speicherlecks hat sich durch alle Programme des Paketes gezogen.
Selbst die angebotenen Servicepacks haben dieses Problem imho nicht behoben.
Grüße aus Rostock
Wolfgang
(Netwolf)
du könntest diesen Bandwurmsatz deaktivieren und testen, ob der Code dann durchläuft.
Du könntest dir die einzelnen Werte im Debugmodus ansehen um festzustellen, welcher (falsche) Wert dann den Absturz verursacht.
Tipp: teile den Bandwurmsatz mal in einzelne Teil-Sätze auf.
Die Office 2003 Version war bekannt für Ihre Speicherlecks bei größeren Aktionen. Die Problematik der Speicherlecks hat sich durch alle Programme des Paketes gezogen.
Selbst die angebotenen Servicepacks haben dieses Problem imho nicht behoben.
Grüße aus Rostock
Wolfgang
(Netwolf)
Moin Gerry,
ich hatte es oben schon geschrieben - poste bitte den Wortlaut der Meldung, die den 'Absturz' anzeigt. Ebenfalls stand dort ein klarer Hinweis auf Änderung - ein weglassen der Zeile bringt Dich (uns) der Lösung wohl nicht näher.
Vielleicht könntest Du den Wünschen der Hilfeleistenden einmal entsprechen - das wäre zielführender und zeitsparender für uns alle.
BTW: Was für Dich unlogisch erscheinen mag, hat durchaus realen und logischen Hintergrund - wenn Du also einen zusammengesetzten String als Formel in eine Zelle schreiben willst, kann genau dieser String erst ab/in der 1.900. Zeile einen Wert annehmen, den Excel (als Formel) moniert ... Selbst die Berechnungen in dem fraglichen Konstrukt bieten genug Potenzial für Bereichsfehler in Variablen.
Ganz in diesem Sinne, freundliche Grüße von der Insel - Mario
ich hatte es oben schon geschrieben - poste bitte den Wortlaut der Meldung, die den 'Absturz' anzeigt. Ebenfalls stand dort ein klarer Hinweis auf Änderung - ein weglassen der Zeile bringt Dich (uns) der Lösung wohl nicht näher.
Vielleicht könntest Du den Wünschen der Hilfeleistenden einmal entsprechen - das wäre zielführender und zeitsparender für uns alle.
BTW: Was für Dich unlogisch erscheinen mag, hat durchaus realen und logischen Hintergrund - wenn Du also einen zusammengesetzten String als Formel in eine Zelle schreiben willst, kann genau dieser String erst ab/in der 1.900. Zeile einen Wert annehmen, den Excel (als Formel) moniert ... Selbst die Berechnungen in dem fraglichen Konstrukt bieten genug Potenzial für Bereichsfehler in Variablen.
Ganz in diesem Sinne, freundliche Grüße von der Insel - Mario
Wahrscheinlich stammt die Rohfassung vom Makrorekorder, und der Rest ist in mühsamer Suchmaschinen-Kleinarbeit entstanden? Ich würde die gesamten .Select-, Selection und Active*-Konstruktionen vollständig eliminieren, da knallt Dir wahrscheinlich das Timing um die Ohren - sowas braucht man nur in Situationen, in denen der Anwender Eingriff nehmen soll. Hier sind Quellen und Ziele ja jeweils klar bekannt, weil selber ermittelt.
Übrigens hängen Deine jeweils kombinierten Ranges alle vollständig zusammen - da kannst Du einfach direkt einen einzigen Range erstellen (z.B. Range("A" & CStr(quellzei), "N" & CStr(quellzei)) statt Range("A" & CStr(quellzei)) & .... & Range("N" & CStr(quellzei))), und Du solltest weggehen von diesen String-Geschichten und hin zu numerischen Zeilen- und Spaltenangaben (über Cells). Bitte auch nicht Formula verwenden, wenn Value gemeint ist. Das aber nur nebenbei, es liegt da schon ziemlich viel (auch anderes) im Argen. Schauen wir aber zunächst einfach mal, dass es überhaupt läuft.
netzwerkknecht auf Windows Intune: http://bit.ly/wide12hp
Übrigens hängen Deine jeweils kombinierten Ranges alle vollständig zusammen - da kannst Du einfach direkt einen einzigen Range erstellen (z.B. Range("A" & CStr(quellzei), "N" & CStr(quellzei)) statt Range("A" & CStr(quellzei)) & .... & Range("N" & CStr(quellzei))), und Du solltest weggehen von diesen String-Geschichten und hin zu numerischen Zeilen- und Spaltenangaben (über Cells). Bitte auch nicht Formula verwenden, wenn Value gemeint ist. Das aber nur nebenbei, es liegt da schon ziemlich viel (auch anderes) im Argen. Schauen wir aber zunächst einfach mal, dass es überhaupt läuft.
netzwerkknecht auf Windows Intune: http://bit.ly/wide12hp
"Moin!"
1.) Der Tip von Wolfgang (Netwolf) hat den Fehler eindeutig auf Zeile 70 eingegrent
Nicht ganz - das hattest Du tatsächlich selber getan.
da durch entfernen dieser Zeile das Macro auf Win-XP und Win-7 absturzfrei läuft.
Defekte Funktionalität zu entfernen ist immer eine Lösung - wenn man die Funktionalität nicht braucht.
Man fragt sich dann natürlich, warum man zuvor irrig glaubte, die Funktionalität zu brauchen.
Eine andere Motivationslage könnte durchaus auch dazu führen, die Funktionalität zum Arbeiten zu bringen.
Das heißt, ich habe die Zeile 70 von
ActiveCell.FormulaR1C1 = ...
auf
Selection.Value = ...
geändert.
ActiveCell.FormulaR1C1 = ...
auf
Selection.Value = ...
geändert.
Für den Privatgebrauch - warum nicht.
netzwerkknecht auf Windows Intune: http://bit.ly/wide12hp
Moin Gerry,
mit der Umstellung auf 'numerische' Werte ist gemeint, eine Zelle über Zeilen- und Spaltennummer anzusprechen, da hierbei Referenzumrechnungen ('A' -> 1 oder 'Z' -> 26) wegfallen.
In Deinem Beispiel bedeutet das (u.a.), Zeile 69 ersatzlos zu eliminieren und in Zeile 70 zu schreiben:
Zusätzlich solltest Du prüfen, welche Zeilen in Quelle und Ziel beim 1.719. Durchlauf tatsächlich referenziert werden, eventuell steckt dort auch noch ein (Format-)Fehler. Damit ein Durchlauf zur Fehlersuche schneller geht, kannst Du die Startzeilen hochsetzen (Zeile 34+35).
Ebenfalls ein schönes Wochenende und freundliche Grüße von der Insel - Mario
mit der Umstellung auf 'numerische' Werte ist gemeint, eine Zelle über Zeilen- und Spaltennummer anzusprechen, da hierbei Referenzumrechnungen ('A' -> 1 oder 'Z' -> 26) wegfallen.
In Deinem Beispiel bedeutet das (u.a.), Zeile 69 ersatzlos zu eliminieren und in Zeile 70 zu schreiben:
Cells(1, 26).Value = ...
Zusätzlich solltest Du prüfen, welche Zeilen in Quelle und Ziel beim 1.719. Durchlauf tatsächlich referenziert werden, eventuell steckt dort auch noch ein (Format-)Fehler. Damit ein Durchlauf zur Fehlersuche schneller geht, kannst Du die Startzeilen hochsetzen (Zeile 34+35).
Ebenfalls ein schönes Wochenende und freundliche Grüße von der Insel - Mario
Moin Gerry,
1. Deine Vermutung ist richtig - es gibt aber noch mehr Range-Probleme, - später ...
2. Diese Suchbereiche lässt Du vorerst unangetastet - ersteinmal geht es um die Suche des eigentlichen Fehlers, - da sind größere Codeumstellungen immer kontraproduktiv.
Ansonsten gilt immer noch:
Freundliche Grüße von der Insel - Mario
1. Deine Vermutung ist richtig - es gibt aber noch mehr Range-Probleme, - später ...
2. Diese Suchbereiche lässt Du vorerst unangetastet - ersteinmal geht es um die Suche des eigentlichen Fehlers, - da sind größere Codeumstellungen immer kontraproduktiv.
Ansonsten gilt immer noch:
Zusätzlich solltest Du prüfen, welche Zeilen in Quelle und Ziel beim 1.719. Durchlauf tatsächlich referenziert werden, eventuell steckt dort auch noch ein (Format-)Fehler. Damit ein Durchlauf zur Fehlersuche schneller geht, kannst Du die Startzeilen hochsetzen (Zeile 34+35).
Freundliche Grüße von der Insel - Mario
N'abend!
Das bedeutet für mich, daß es egal ist, ob ich
ActiveCell.FormulaR1C1 = ...
ODER
Selection.Value = ...
in Zeile 70 verwende.
Der Absturz bleibt leider.
ActiveCell.FormulaR1C1 = ...
ODER
Selection.Value = ...
in Zeile 70 verwende.
Der Absturz bleibt leider.
Das wundert mich nicht allzu sehr - was bleibt ist nämlich auch meine Empfehlung: "Ich würde die gesamten .Select-, Selection und Active*-Konstruktionen vollständig eliminieren, da knallt Dir wahrscheinlich das Timing um die Ohren [...]". Ich schwöre nicht, dass das Dein konkretes Problem ist (da sind so viele Dinge, die im Idealfall so nicht sein sollten), aber ich bin durchaus kurz davor. Das sind Interaktionselemente, die auf reinen Code sehr oft sehr unfreundlich reagieren (in wenigen Fällen geht es nicht anders, weil bestimmte Excel-Funktionalitäten sich z. B. auf markierte Bereiche beziehen, aber das ist dann der Notfall, bei dem man die Daumen drückt und nach Alternativen sucht).
Vorschlag zur Güte (die Fehlerstelle muss nicht zwingend auch die verursachende Stelle sein - schon gar nicht bei Timingproblemen, überwiegend aber ist es so): Teste es in der ursprünglichen Zeile 70 mit der Erklärung von Mario (vorausgesetzt, der Code steht im Modul des Worksheets, in dem besagte Zelle Z1 liegt, anderenfalls noch den passenden Worksheet-Objektbezeichner davorsetzen):
Cells(1,26).Value = ...
1.) Wenn ich das ganze richtig verstehe, arbeitet VBA in wirklichkeit mit Zeilennummern und Spaltennummern.
Verwende ich im Quelltext Range("a" & CStr(quellzei)), so vergewaltige ich VBA dazu, das ganze intern in Zeilennummern und Spaltennummern umzurechnen.
Daher benötigt das Progi mehr Arbeitsspeicher und wird langsamer.
Ist meine Vermutung richtig?
Verwende ich im Quelltext Range("a" & CStr(quellzei)), so vergewaltige ich VBA dazu, das ganze intern in Zeilennummern und Spaltennummern umzurechnen.
Daher benötigt das Progi mehr Arbeitsspeicher und wird langsamer.
Ist meine Vermutung richtig?
Das ist dem Grunde nach richtig, gehört aber in die Ecke der letzten Optimierungen. Die Unterschiede sind marginal und werden erst im Hochlastfall interessant. Natürlich ist es trotzdem besser, wenn man solche Schwachstellen gleich vermeidet, aber viel wichtiger ist: Diese String-Geschichten sind neben ihrer Ineffizienz vollkommen unübersichtlich und verführen gerade Einsteiger zu merkwürdigen Programmierwegen - ich bin mir dessen bewusst, dass man das als Einsteiger anders sieht, und insofern könnte ich verstehen, wenn Du dem widersprechen würdest.
2.) Ich wollte den Rat befolgen, und alle Ranges in einem zusammenfassen.
suchealles1 = Range("A" & CStr(quellzei), "B" & CStr(quellzei), "C" & CStr(quellzei), "D" & CStr(quellzei))
Leider kommt sofort bei der Ausführung des Makros folgende Fehlermeldung
suchealles1 = Range("A" & CStr(quellzei), "B" & CStr(quellzei), "C" & CStr(quellzei), "D" & CStr(quellzei))
Leider kommt sofort bei der Ausführung des Makros folgende Fehlermeldung
Das bedeutet, dass VBA noch funktioniert. Das ist eine gute Nachricht.
Ich hatte den folgenden Vorschlag gemacht:
suchealles1 = Range("A" & CStr(quellzei), "N" & CStr(quellzei))
Viel Erfolg und einen schönen Restabend
netzwerkknecht auf Windows Intune: http://bit.ly/wide12hp
Hallo @all!
@netzwerkknecht
Insofern, ist es schon richtig, die einzelnen Ranges zu einem String zu verketten. Andernfalls wäre es natürlich möglich, dass ganze Range-Object in ein Array zu packen und per Schleife einen Array-Vergleich durchzuführen, was den Vorteil hätte den Vergleich schon bei Ungleichheit eines Wertes vorzeitig zu beenden, was wiederum der Performance zu Gute kommen würde.
Mit dieser Variante ist schonmal ein enormer Geschwindigkeitsgewinn zu erwarten:
Und mit dieser Variante sollte der Gesamt-Durchlauf nur zwischen 3-5 Sekunden dauern:
Gruß Dieter
@netzwerkknecht
suchealles1 = Range("A" & CStr(quellzei), "N" & CStr(quellzei))
Mal davon abgesehen, dass dies kein Range-Object ist, wird es Dir nicht gelingen, einem String ein Range-Array zuzuweisenInsofern, ist es schon richtig, die einzelnen Ranges zu einem String zu verketten. Andernfalls wäre es natürlich möglich, dass ganze Range-Object in ein Array zu packen und per Schleife einen Array-Vergleich durchzuführen, was den Vorteil hätte den Vergleich schon bei Ungleichheit eines Wertes vorzeitig zu beenden, was wiederum der Performance zu Gute kommen würde.
Mit dieser Variante ist schonmal ein enormer Geschwindigkeitsgewinn zu erwarten:
Dim WksQ As Worksheet, WksS As Worksheet, ValuesQ As Variant, ValuesS As Variant
Dim q As Long, s As Long, i As Integer
Set WksQ = Sheets(2): Set WksS = Sheets(1)
Application.ScreenUpdating = False
'For q = 2 To Anzahl
ValuesQ = Range(WksQ.Cells(q, "A"), WksQ.Cells(q, "N")).Value
'......
'For s = Anzahl To 2 Step -1 'Wenn Zeilen gelöscht werden, dann bei letzter Zeile beginnen
ValuesS = Range(WksS.Cells(s, "E"), WksS.Cells(s, "R")).Value
For i = 1 To UBound(ValuesQ, 2)
If ValuesQ(1, i) <> ValuesS(1, i) Then Exit For
Next
If i > UBound(ValuesQ, 2) Then
'Ist Gleich..."
End If
'......
'Next
'.....
'Next
Application.ScreenUpdating = True
Dim WksQ As Worksheet, WksS As Worksheet, ValuesQ As Variant, ValuesS As Variant
Dim Found As Range, q As Long, i As Integer
Set WksQ = Sheets(2): Set WksS = Sheets(1)
Application.ScreenUpdating = False
'For q = 2 To Anzahl
ValuesQ = Range(WksQ.Cells(q, "A"), WksQ.Cells(q, "N")).Value
'......
Set Found = WksS.Columns("E").Find(ValuesQ(1, 1), LookIn:=xlValues, LookAt:=xlWhole, MatchCase:=False)
If Not Found Is Nothing Then
ValuesS = Range(WksS.Cells(Found.Row, "E"), WksS.Cells(Found.Row, "R")).Value
For i = 2 To UBound(ValuesQ, 2)
If ValuesQ(1, i) <> ValuesS(1, i) Then Exit For
Next
If i > UBound(ValuesQ, 2) Then
'Ist Gleich..."
End If
'......
End If
'.....
'Next
Application.ScreenUpdating = True
Gruß Dieter
Zitat von @76109:
> suchealles1 = Range("A" & CStr(quellzei), "N" & CStr(quellzei))
Mal davon abgesehen, dass dies kein Range-Object ist, wird es Dir nicht gelingen, einem String ein Range-Array zuzuweisen
> suchealles1 = Range("A" & CStr(quellzei), "N" & CStr(quellzei))
Mal davon abgesehen, dass dies kein Range-Object ist, wird es Dir nicht gelingen, einem String ein Range-Array zuzuweisen
Uuuuah - das soll tatsächlich ein String sein - in dem Fall natürlich Kommando zurück. In einem solchen Szenario Strings zu verketten und zu vergleichen lag derart weit entfernt von meiner Vorstellungswelt, dass ich da erfasst habe, was mein Hirn mir vorgetäuscht hat... Danke für die Richtigstellung!
netzwerkknecht auf Windows Intune: http://bit.ly/wide12hp