nicht genügend speicher - tausendmal gefragt...
Alexander Bierig
wir haben das Problem, dass wir zuverlässig wissen sollten, ob in
Exceltabellen identische Rechenergebnisse stehen.
Die Dateien haben denselben Aufbau, unterscheiden sich lediglich über ein im
Dateinamen mitgeführtes Datum, sowie aus dem Dateinamen erkennbaren
Themeninhalt.
In den einzelnen Mappen können durchaus 150 Tabellen mit bis zu 50.000
Zeilen auftreten.
Daher war die Idee, die Prüfung mittels Sverweis und Makro durchzuführen und
den Computer nächtelang selbst rechnen zu lassen.
Makro greift geöffnete(!) Mappen auf, schreibt deren Namen und den Partner
in ein Array.
dann wird das Array abgeklappert udn die Tabellen innerhalb der Mappen
werden jeweils mit ihren Namen in ein Array geschrieben.
Anschliessend werden dei Tabellen abgeklappert udn mittels SVERWEIS die
Werte der einen Tabelle in eine Spalte der Partnertabelle geschrieben, die
Differenz gebildet, die bei identischen Werten 0 ergeben muss.
Abschliessend klappern wir die Spalten in den 0 stehen muss je Tabelle ab
und vermeken (ebenfalls in einem Array) die abweichenden Tabellen/Mappenname
ind die Zeile der Abweichung. (um nach der Ursache zu forschen)
leeren das Array mit den Tabellennamen
wechseln zu nächsten Mappe...
bsp:
mappea_heute.xls mappea_gestern.xls
mappeabc_heute.xls mappeabc_gestern.xls
usw...
jede der Mappen ist innerlich mit derselben Tabellenzahl - und struktur (und
sogar den identischen Tabellennamen) unterwegs.
Dem Gedanken, die ganzen Mappen (zweimal 37 Mappen) in einem Rutsch zu
öffnen, liegt die Faulheit dahingehend zugrunde, dass man dann keine
Dateiverwaltung zusätzlich im Makro erstellen muss.
Das Problem ist eigentlich, dass wir den dahinterliegenden SQL-Server in
seinen Berechnungen umstellten/erweiterten und absolut sicher sein müssen,
dass wir in den angesprochenen 37 Bereichen keine Veränderung haben.
Makro läuft fehlerfrei und wunschgemäss.
ABER:
manche Mappen haben über 100MByte.
Und wenn ich z.Bsp 8 Mappen mit insgesamt 280 MByte aufmachen will, fällt
das Excel mit "nicht genügend Arbeitsspeicher" auf die Nase.
Wenn ich die Menge Mappen aufmache, die das Excel gerade ncoh zulässt,
fällts anschliessend bei seinen Berechnungen auf die Nase. Es muss also
"Luft" bleiben.
Das Excel aktualisiert dann nicht einmal mehr den Bildschirm.
Es sind keine Grafiken in den Mappen - nur Tabellen mit Zahlen und Texten
Also musste ich leider doch in Etappen vorgehen - es bleibt aber die
Neugierde:
Wo liegt da eine Grenze bei Excel 2K / XP was den Speicherbedarf angeht?
Genauer: Was ist die Resource, die dem Excel dabei ausgeht? Weil der
Speicher ist es nicht (bei 1,5 GiG RAM und beobachtbaren Verbrauch lt
Taskmanager).
Mit freundlichen Grüssen
Alex.
--
Wegen der Berge von Spam:
die Emailadresse lautet
alexander.at.taxi.minus.stuttgart.dot.de
Klaus Kammann
dieses und noch vieles mehr bekommt über F1 und Spezifikationen.
Aus welcher Datei führst du dein Makro aus?
Gruß
Klaus
Spezifikationen und Einschränkungen von Excel
Spezifikationen für Arbeitsblätter und Arbeitsmappen
Feature Maximaler Wert
Geöffnete Arbeitsmappen Durch den verfügbaren Speicher und die
Systemressourcen begrenzt
Arbeitsblattgröße 65.536 Zeilen mal 256 Spalten
Spaltenbreite 255 Zeichen
Zeilenhöhe 409 Punkte
Seitenwechsel 1000 horizontal und vertikal
Länge des Inhalts der Zelle (Text) 32.767 Zeichen. Nur 1.024 Zeichen
werden in einer Zelle angezeigt; alle 32.767 werden in der Formelleiste
angezeigt.
Blätter in einer Arbeitsmappe Durch den verfügbaren Speicher begrenzt
(Standardwert 3 Blätter)
Farben pro Arbeitsmappe 56
Zellformate pro Arbeitsmappe 4.000
Benannte Ansichten in einer Arbeitsmappe Durch den verfügbaren
Speicher begrenzt
Benutzerdefinierte Zahlenformate Durch den verfügbaren Speicher
begrenzt
Namen pro Arbeitsmappe Durch den verfügbaren Speicher begrenzt
Fenster pro Arbeitsmappe Durch die Systemressourcen begrenzt
Ausschnitte pro Fenster 4
Verknüpfte Blätter Durch den verfügbaren Speicher begrenzt
Szenarios Durch den verfügbaren Speicher begrenzt; in einem
Übersichtsbericht werden nur die ersten 251 Szenarios angezeigt
Sich ändernde Zellen pro Szenario 32
Anpassbare Zellen in Solver 200
Benutzerdefinierte Funktionen Durch den verfügbaren Speicher begrenzt
Zoom-Bereich 10 bis 400 Prozent
Berichte Durch den verfügbaren Speicher begrenzt
Sortierbezüge 3 in einem einfachen Sortiervorgang; bei sequenziellen
Sortiervorgängen unbegrenzt
Rückgängig-Stufen 16
Felder pro Datenformular 32
Benutzerdefinierte Symbolleisten pro Arbeitsmappe Durch den
verfügbaren Speicher begrenzt
Benutzerdefinierte Schaltflächen der Symbolleiste Durch den
verfügbaren Speicher begrenzt
Michael Schwimmer
"Alexander Bierig" schrieb:
> wir haben das Problem, dass wir zuverlässig wissen sollten, ob in
> Exceltabellen identische Rechenergebnisse stehen.
> Die Dateien haben denselben Aufbau, unterscheiden sich lediglich
> über ein im Dateinamen mitgeführtes Datum, sowie aus dem Dateinamen
> erkennbaren Themeninhalt.
> In den einzelnen Mappen können durchaus 150 Tabellen mit bis zu
> 50.000 Zeilen auftreten.
das Anlegen solcher Monstertabellen sollte IMO schon von Excel selbst
unterbunden werden. Wie du selbst siehst, gibt es bei solchen
Dateigrößen immer wieder Schwierigkeiten, die sogar bis zum Datenverlust
führen können.
Der Mangel an "Verfügbaren Speicher" ist auch nicht unbedingt ein
direktes Problem des Speicherausbaus des Rechners. Leider ist auch die
Seite von Philipp von Wartburg nicht mehr erreichbar, aber ich meine,
dass bei 2K der verfügbare Speicher für die Anwendung 8 MiB, Daten 1 GiB
und Datenverarbeitung 64 MiB beträgt.
Wenn ich dich richtig verstehe, willst du die Daten vergleichen, die
sich in Tabellen mit gleichem Namen aber in unterschiedlichen
Arbeitsmappen befinden.
Wie ist denn der Tabellenaufbau? Wenn der Aufbau ähnlich dem einer
Datenbank ist, mit Spaltenüberschriften und gleichen Datentypen in den
Spalten, könnte man möglicherweise mit ADO arbeiten. Das würde zumindest
das Problem mit dem Speicherbedarf der geöffneten Mappen umgehen.
Das heißt, man müsste sich jeweils ein Recordset mit dem Tabelleninhalt
verschiedener Mappen angelegen. Danach könnte man in aller Ruhe
Datensatz für Datensatz mit dem des anderen Recordsets vergleichen und
das Ergebnis in einer eigenen Tabelle zwischenspeichern.
Eine andere Möglichkeit besteht darin, nacheinander je zwei Dateien zu
öffnen, den Inhalt je einer Tabelle in zwei eigene zu kopieren und die
Mappen wieder zu schließen. Anschließend führt man den Vergleich durch.
MfG
Michael
--
Michael Schwimmer
Home : http://michael-schwimmer.de
Excel VBA ISBN 3-8273-2183-2
Reiner Wolff
moin Alexander,
*Michael Schwimmer* schrieb:
> "Alexander Bierig" schrieb:
>> wir haben das Problem, dass wir zuverlässig wissen sollten, ob in
>> Exceltabellen identische Rechenergebnisse stehen.
>> Die Dateien haben denselben Aufbau, unterscheiden sich lediglich
>> über ein im Dateinamen mitgeführtes Datum, sowie aus dem Dateinamen
>> erkennbaren Themeninhalt.
>> In den einzelnen Mappen können durchaus 150 Tabellen mit bis zu
>> 50.000 Zeilen auftreten.
>
> das Anlegen solcher Monstertabellen sollte IMO schon von Excel selbst
> unterbunden werden.
Wäre ich auch für, wo darf ich unterschreiben? ;-)
> Der Mangel an "Verfügbaren Speicher" ist auch nicht unbedingt ein
> direktes Problem des Speicherausbaus des Rechners. Leider ist auch die
> Seite von Philipp von Wartburg nicht mehr erreichbar, aber ich meine,
> dass bei 2K der verfügbare Speicher für die Anwendung 8 MiB, Daten 1 GiB
> und Datenverarbeitung 64 MiB beträgt.
Gutes Gedächtnis. Die Seite ist im Archiv wieder online gestellt unter:
http://web.archive.org/web/20040204105931/195.186.84.74/xlimits/speicher.htm
(allerdings funktionieren da bei mir die Bilder nicht)
> Wenn ich dich richtig verstehe, willst du die Daten vergleichen, die
> sich in Tabellen mit gleichem Namen aber in unterschiedlichen
> Arbeitsmappen befinden.
>
> Wie ist denn der Tabellenaufbau? Wenn der Aufbau ähnlich dem einer
> Datenbank ist, mit Spaltenüberschriften und gleichen Datentypen in den
> Spalten, könnte man möglicherweise mit ADO arbeiten. Das würde zumindest
> das Problem mit dem Speicherbedarf der geöffneten Mappen umgehen.
Ich will bei der Anzahl an Zeilen mal hoffen, dass die Daten in
Tabellenform vorliegen.
> Das heißt, man müsste sich jeweils ein Recordset mit dem Tabelleninhalt
> verschiedener Mappen angelegen.
Ich bin mal so frei und poste dazu ein bischen was aus meiner
Code-Bibliothek:
Sub ADOTabellenAuflisten()
Dim cn As ADODB.Connection
Dim rec As ADODB.Recordset
Dim strDatei As String
strDatei = "C:\Mappe1.xls"
Set cn = New ADODB.Connection
With cn
.Provider = "Microsoft.Jet.OLEDB.4.0"
.ConnectionString = "Data Source=" & strDatei & ";" & _
"Extended Properties=Excel 8.0;"
.Open
Set rec = cn.OpenSchema(adSchemaTables)
ThisWorkbook.Sheets(1).Cells(1, 1).CopyFromRecordset rec
rec.Close
Set rec = Nothing
End With
cn.Close
Set cn = Nothing
End Sub
Und nach dem cn.Open könntest Du auch einfach mittels rec.Open auf den
Tabelleninhalt zugreifen:
rec.Open "Select * From [Tabelle1$]", ...
Das alles auch ausführlich beschrieben unter:
How To Use ADO with Excel Data from Visual Basic or VBA
http://support.microsoft.com/default.aspx?scid=kb;en-us;Q257819
> Danach könnte man in aller Ruhe
> Datensatz für Datensatz mit dem des anderen Recordsets vergleichen und
> das Ergebnis in einer eigenen Tabelle zwischenspeichern.
Ich könnte mir auch vorstellen, dass es performanter sein könnte, die Daten
der einen Mappe erstmal mit CopyFromRecordset in die andere Arbeitsmappe zu
kopieren, um dann mit einem
rec.Open "Select distinct [" & strName & "$].* From [" & strName & "$]
Left Outer Join [Tabelle3$] On [" & strName & "$].[ich] = [Tabelle3$].[ich]
Where [Tabelle3$].[ich] Is Null", ...
direkt die Unterschiede angezeigt zu bekommen.
Das Problem dabei könnte allerdings sein, dass man die Datei vermutlich
zwischendurch speichern müsste ...
Oder man öffnet Recordsets zu beiden Mappen und speichert sie dann als
Textdatei in einem Verzeichnis, um dann darüber einen direkten
Join-Vergleich durchführen zu können. Da ist dann zwar die Festplatte
dauernd im zusätzlich im Zugriff, ich habe damit aber auch ganz gute
Erfahrungen beim Recordset-Vergleich gemacht.
Der Beispielcode dazu ist etwas länger, daher habe ich ihn einmal ganz nach
hinten gepackt.
Das war in meinen bisherigen Tests zumindest deutlich schneller, als die
Recordsets Feld für Feld und Datensatz für Datensatz zu vergleichen.
So, soweit meine hoffentlich hilfreichen Ergänzungen zu Michaels Beitrag.
Greetinx aus Kiel
Reiner
--
Ein Programm sollte nicht nur Hand und Fuss,
sondern auch Herz und Hirn haben.
(Michael Anton)
P.S.: Hier noch der Beispielcode:
Public Sub TextdateiRecordset()
'Zeigt am Beispiel einen "Join" über 2 ADODB.Recordsets
Dim cnn1 As ADODB.Connection
Dim cnn2 As ADODB.Connection
Dim cnnTxt As ADODB.Connection
Dim rs1 As ADODB.Recordset
Dim rs2 As ADODB.Recordset
Dim recErgebnis As ADODB.Recordset
Dim str As String
Dim i As Long
'Verbindungen öffnen
'zur 1ten Datenbank
Set cnn1 = New ADODB.Connection
cnn1.ConnectionString = ConnectionStringErmitteln()
cnn1.Open
'zur 2ten Datenbank
Set cnn2 = New ADODB.Connection
cnn2.ConnectionString = ConnectionStringErmitteln()
cnn2.Open
'Zu den Textdateien
Set cnnTxt = New ADODB.Connection
cnnTxt.ConnectionString = "Provider=Microsoft.Jet.OLEDB.4.0;Data
Source=c:\;Extended Properties=""text;HDR=Yes;FMT=Delimited"""
cnnTxt.Open
'Recordsets öffnen
Set rs1 = New ADODB.Recordset
rs1.Open "Select * From tblMitarbeiter", cnn1, adOpenForwardOnly,
adLockReadOnly
Set rs2 = New ADODB.Recordset
rs2.Open "Select * From tblStandort", cnn2, adOpenForwardOnly,
adLockReadOnly
'Recordsets speichern
str = ""
For i = 0 To rs1.Fields.Count - 1
str = str & rs1.Fields(i).Name & ";"
Next
str = str & vbNewLine & rs1.GetString(, , ";", vbNewLine)
WriteFile "C:\rs1.txt", str
str = ""
For i = 0 To rs2.Fields.Count - 1
str = str & rs2.Fields(i).Name & ";"
Next
str = str & vbNewLine & rs2.GetString(, , ";", vbNewLine)
WriteFile "C:\rs2.txt", str
'Den Join im Recordset aufrufen
Set recErgebnis = New ADODB.Recordset
recErgebnis.Open "Select Nachname, Vorname, Ortsname From [rs1.txt] As T1
Inner Join [rs2.txt] As T2 On T1.StONr = T2.StONr Where PNr = 000", cnnTxt,
adOpenForwardOnly, adLockReadOnly
Cells.ClearContents
Cells(1, 1).CopyFromRecordset recErgebnis
End Sub
'folgender Code von www.vb-tec.de entnommen
Sub WriteFile(ByRef Path As String, ByRef Text As String)
Dim FileNr As Long
'Wenn Datei unverändert, dann abbrechen (ggf. weglassen):
If FileExists(Path) Then _
If FileLen(Path) = Len(Text) Then _
If ReadFile(Path) = Text Then Exit Sub
'Text speichern:
FileNr = FreeFile
Open Path For Output As #FileNr
Print #FileNr, Text;
Close #FileNr
End Sub
Public Function FileExists(Path As String) As Boolean
Const NotFile = vbDirectory Or vbVolume
On Error Resume Next
FileExists = (GetAttr(Path) And NotFile) = 0
On Error GoTo 0
End Function
Function ReadFile(ByRef Path As String) As String
Dim FileNr As Long
'Falls nicht vorhanden, nichts zurückgeben:
On Error Resume Next
If FileLen(Path) = 0 Then Exit Function
On Error GoTo 0
'Datei einlesen:
FileNr = FreeFile
Open Path For Binary As #FileNr
ReadFile = Space$(LOF(FileNr))
Get #FileNr, , ReadFile
Close #FileNr
End Function
Michael Schwimmer
ich antworte ausnahmsweise mal auf mein eigenes Posting, da meine OE-
Tools Probleme mit deinem Posting haben.
>>> "Alexander Bierig" schrieb:
>>> In den einzelnen Mappen können durchaus 150 Tabellen mit bis zu
>>> 50.000 Zeilen auftreten.
>> das Anlegen solcher Monstertabellen sollte IMO schon von Excel selbst
>> unterbunden werden.
>Wäre ich auch für, wo darf ich unterschreiben? ;-)
Leider zu spät, die Petition an Microsoft ist schon unterwegs ;-))
>> Seite von Philipp von Wartburg nicht mehr erreichbar, aber ich meine,
>> dass bei 2K der verfügbare Speicher für die Anwendung 8 MiB, Daten 1
>> GiB und Datenverarbeitung 64 MiB beträgt.
> Gutes Gedächtnis. Die Seite ist im Archiv wieder online gestellt
> unter:
> <http://web.archive.org/web/20040204105931/195.186.84.74/xlimits/speic
> her.htm>
> (allerdings funktionieren da bei mir die Bilder nicht)
Danke für den Link. Ist zwar quälend langsam, und die Bilder fehlen, ich
habe mir aber trotzdem gleich einmal die Seiten offline verfügbar
gemacht. Pures Gold!
> Ich könnte mir auch vorstellen, dass es performanter sein könnte, die
> Daten der einen Mappe erstmal mit CopyFromRecordset in die andere
> Arbeitsmappe zu kopieren, um dann mit einem
Habe ich nicht probiert, aber ich verspreche mir davon nicht unbedingt
einen Geschwindigkeitsvorteil. Das Einfügen von Daten in ein Blatt ist
IMO nicht sehr schnell.
> Oder man öffnet Recordsets zu beiden Mappen und speichert sie dann
> als Textdatei in einem Verzeichnis, um dann darüber einen direkten
> Join-Vergleich durchführen zu können. Da ist dann zwar die Festplatte
Das gefällt mir gut!
> Das war in meinen bisherigen Tests zumindest deutlich schneller, als
> die Recordsets Feld für Feld und Datensatz für Datensatz zu
> vergleichen.
<Code geschnippt>
Mich stören eigentlich die zwei Textdateien, das erfordert wieder das
für mich etwas undurchsichtige Join. Außerdem ist DISTINCT nicht
unbedingt der richtige Weg. Der OP will doch die Differenz, mit DISTINCT
bekommt er trotzdem alle Datensätze einer Tabelle geliefert und nicht
nur die, die nur einmal vorhanden, also ungleich sind.
Hier auch etwas Code:
Option Explicit
Private Declare Function GetTempPath _
Lib "kernel32" Alias "GetTempPathA" ( _
ByVal nBufferLength As Long, _
ByVal lpBuffer As String _
) As Long
Sub CompareXL()
Dim adoConnection As New ADODB.Connection
Dim adoRecordset As New ADODB.Recordset
Dim astrSource(1 To 2) As String
Dim astrTabelle(1 To 2) As String
Dim strPath As String
Dim strFile As String
Dim strDest As String
Dim strResult As String
Dim strSpalte As String
Dim strGroup As String
Dim lngRet As Long
Dim lngFF As Long
Dim lngFields As Long
Dim lngFreeRow As Long
Dim i As Long
Dim k As Long
Dim varResult As Variant
Dim varData As Variant
' TempPfad ermitteln
strPath = String(255, 0)
lngRet = GetTempPath(255, strPath)
strPath = Left$(strPath, lngRet)
' Tempdatei
strFile = "RecVergleich.txt"
' Kompletten Pfad zusammensetzen
strDest = strPath & strFile
' Bestehende Datei löschen
If Dir(strDest) <> "" Then Kill strDest
' Zu vergleichende Mappen
astrSource(1) = "c:\Testdaten.xls"
astrSource(2) = "c:\Testdaten.xls"
' Zu vergleichende Tabellen
astrTabelle(1) = "Tabelle1"
astrTabelle(2) = "Tabelle2"
For i = 1 To 2
' Verbindung zur Datenbank herstellen
adoConnection.Open _
"Provider=Microsoft.Jet.OLEDB.4.0;" & _
"Data Source=" & astrSource(i) & _
";Extended Properties=Excel 8.0;"
' Abfrage aus Tabelle
adoRecordset.Open _
"SELECT * FROM [" & astrTabelle(i) & "$];", _
adoConnection, _
adOpenKeyset, _
adLockOptimistic
With adoRecordset
' Abfrageergebnis in String umwandeln
' Trennzeichen Semikolon, Sätze durch
' vbCrLf getrennt (CSV)
strResult = .GetString( _
adClipString, , ";", vbCrLf, "")
' Freie Nummer ermitteln
lngFF = FreeFile()
' Ausgabe des Strings in eine Datei
Open strDest For Binary As lngFF
If i = 1 Then
' Feldnamen in der Textdatei vergeben
For k = 0 To .Fields.Count - 2
' Spaltenüberschrift als Feldname benutzen
strSpalte = Cells(1, k + 1).Address(1, 0)
strSpalte = Left(strSpalte, _
InStr(1, strSpalte, "$") - 1)
' Feldname in Textdatei schreiben
Put lngFF, , strSpalte & ";"
' Feldnamen für Gruppierung speichern
strGroup = strGroup & "[" & strSpalte & "],"
Next
' Spaltenüberschrift als Feldname benutzen
strSpalte = Cells(1, k + 1).Address(1, 0)
strSpalte = Left(strSpalte, _
InStr(1, strSpalte, "$") - 1)
' Feldname in Textdatei schreiben
Put lngFF, , .Fields(1).Name & vbCrLf
' Feldnamen für Gruppierung speichern
strGroup = strGroup & "[" & strSpalte & "]"
End If
' Daten in Textdatei schreiben
Put lngFF, LOF(lngFF) + 1, strResult
Close
End With
' Alles Schließen
adoRecordset.Close
adoConnection.Close
Next ' Noch einmal mit nächster Mappe
' Verbindung zum Tempverzeichnis herstellen, da
' bei Textdateien das Verzeichnis die Datenbank
' ist. Trennzeichen=; , Feldnamen: Ja
adoConnection.Open _
"Provider=Microsoft.Jet.OLEDB.4.0;" & _
"Data Source=" & strPath & _
";Extended Properties=" & _
"""text;HDR=YES;FMT=Delimited(;)"""
' Abfrage: Tabellenname ist bei Textdateien
' der Dateiname. Anzahl ermitteln und Gruppieren.
' Ergebnis 2 bedeutet, dass Datensatz doppelt ist
adoRecordset.Open _
"SELECT COUNT ( * ) , " & _
strGroup & " FROM [" & _
strFile & "]" & _
" GROUP BY " & strGroup & ";", _
adoConnection, _
adOpenKeyset, _
adLockOptimistic
' Ergebnis in ein Array
varResult = adoRecordset.GetRows
' Schließen
adoRecordset.Close
adoConnection.Close
With Worksheets(1)
' Fehler in Tabelle1 ausgeben
' Felder ermitteln
lngFields = UBound(varResult, 1)
' Freie Zeile ermitteln
lngFreeRow = .Cells(Rows.Count, 1).End(xlUp).Row + 1
For i = 0 To UBound(varResult, 2)
' Alle Datensätze durchlaufen
If varResult(0, i) = 1 Then
' Ergebnisdatensatz nur einfach vorhanden
For k = 1 To lngFields
' Alle Felder ausgeben
.Cells(lngFreeRow, k) = varResult(k, i)
Next
' Dateinamen ausgeben
.Cells(lngFreeRow, k) = astrSource(1)
' Tabellenname ausgeben
.Cells(lngFreeRow, k + 1) = astrTabelle(1)
' Nächste freie Zeile
lngFreeRow = lngFreeRow + 1
End If
Next
End With
End Sub
Reiner Wolff
*Michael Schwimmer* schrieb:
> ich antworte ausnahmsweise mal auf mein eigenes Posting, da meine OE-
> Tools Probleme mit deinem Posting haben.
Ups, Probleme mit meinem Posting?
Womit denn genau?
Kann ich etwas daran abstellen?
>> Oder man öffnet Recordsets zu beiden Mappen und speichert sie dann
>> als Textdatei in einem Verzeichnis, um dann darüber einen direkten
>> Join-Vergleich durchführen zu können. Da ist dann zwar die Festplatte
>
> Das gefällt mir gut!
>
>> Das war in meinen bisherigen Tests zumindest deutlich schneller, als
>> die Recordsets Feld für Feld und Datensatz für Datensatz zu
>> vergleichen.
>
> <Code geschnippt>
>
> Mich stören eigentlich die zwei Textdateien, das erfordert wieder das
> für mich etwas undurchsichtige Join.
Ein Join (in diesem Fall wohl eher eine Inkonsistenz-Abfrage) wird
schneller sein als ein Vergleich pro Datensatz. Du solltest Dich mal mit
der SQL-Sprache auseinandersetzen (insbesondere, weil Du auch etwas mit
Datenbanken zu tun hast).
> Außerdem ist DISTINCT nicht unbedingt der richtige Weg.
Stimmt, distinct hat da nicht prinzipiell etwas zu suchen, allerdings muss
Alexander meine Beispiele sowieso kombinieren, um zur richtigen Lösung zu
kommen. Ich glaube, deswegen habe ich sie auch nur Beispiele und nicht
Lösung genannt ;-)
> Der OP will doch die Differenz, mit DISTINCT
> bekommt er trotzdem alle Datensätze einer Tabelle geliefert und nicht
> nur die, die nur einmal vorhanden, also ungleich sind.
Stimmt. Aber ich poste ungern einfach nur Lösungen, wenn ich selbst dafür
den Code auch noch umprogrammieren müßte. Ich versuche vielmehr, Leute zum
selber Denken anzuregen und ihnen dabei zu helfen.
Greetinx aus Kiel
Reiner
--
Es ist bemerkenswert, daß nur vielleicht 10% aller Programmierer
Programme ohne Verwendung von Flussdiagrammen erfolgreich schreiben
können. Unglücklicherweise glauben aber 90%, daß sie der Gruppe
dieser 10% angehören. (Rodnay Zaks)
Michael Schwimmer
Reiner Wolff schrieb:
> Ups, Probleme mit meinem Posting?
> Womit denn genau?
> Kann ich etwas daran abstellen?
daran kannst du nichts abstellen, die OE-Tools verschlucken sich ab und
an, warum, weiß der Geier.
Jetzt funzt es beispielsweise wie geschmiert ;-)
> Ein Join (in diesem Fall wohl eher eine Inkonsistenz-Abfrage) wird
> schneller sein als ein Vergleich pro Datensatz. Du solltest Dich mal
> mit der SQL-Sprache auseinandersetzen (insbesondere, weil Du auch
> etwas mit Datenbanken zu tun hast).
Mit Datenbanken habe ich beruflich eigentlich weniger zu tun, ich
steuere und überwache ein Hoch- Mittel- und Niederspannungsnetz. Die für
mich relevanten Daten sind im Leitsysten immer aktuell verfügbar.
Lediglich Archivdaten hole ich mir aus allen möglichen Oracle-
Datenbanken, aber wenn das einmal steht, sind weitere Anpassungen meist
nicht mehr nötig.
Es ist nicht so, dass ich Join grundsätzlich nicht verstehe, ich mag es
ganz einfach nicht. Wenn ich Ergebnisse aus verschiedenen Tabellen
benötige, verwende ich Join natürlich auch, obwohl es zumindestens bei
Access scheinbar auch ohne geht. Bei einer Klausur meiner Tochter wurde
ausdrücklich verlangt, Join nicht zu benutzen.
Mir ist auch momentan nicht klar, wie man mit Join direkt die Differenz
zweier Tabellen geliefert bekommt, das würde es natürlich enorm
vereinfachen.
Man muss aber bei dem gelieferten Recordset
adoRecordset.Open _
"SELECT COUNT ( * ) , " & _
strGroup & " FROM [" & _
strFile & "]" & _
" GROUP BY " & strGroup & ";", _
adoConnection, _
adOpenKeyset, _
adLockOptimistic
auch nicht alle Datensätze durchlaufen. Als Verbesserung könnte man ja
noch einen Filter setzen, der die Sätze mit einer Zwei im ersten Feld
ausblendet. Dan hat man nur noch die Unikate.
> > Außerdem ist DISTINCT nicht unbedingt der richtige Weg.
> Stimmt, distinct hat da nicht prinzipiell etwas zu suchen,
> allerdings muss Alexander meine Beispiele sowieso kombinieren, um
> zur richtigen Lösung zu kommen. Ich glaube, deswegen habe ich sie
> auch nur Beispiele und nicht Lösung genannt ;-)
Das ist schon klar, Hilfe zur Selbsthilfe!
> > Der OP will doch die Differenz, mit DISTINCT
> > bekommt er trotzdem alle Datensätze einer Tabelle geliefert und
> > nicht nur die, die nur einmal vorhanden, also ungleich sind.
>
> Stimmt. Aber ich poste ungern einfach nur Lösungen, wenn ich selbst
> dafür den Code auch noch umprogrammieren müßte. Ich versuche
> vielmehr, Leute zum selber Denken anzuregen und ihnen dabei zu
> helfen.
Gerade das Lösen macht mir ja so viel Spaß. Wenn man natürlich beruflich
viel damit zu tun hat, kann das aber sehr schnell lästig werden.
Alexander Bierig
Dir und all den anderen hier vielen Dank für die schnelle und prompte Hilfe.
Im Moment ist Quartalsabschluss - das bedeutet, dass wir im
Berichteerstellen ersticken, zusätzlich zum normalen Tagesgeschäft.. Daher
die etwas verspätete Antwort.
> dieses und noch vieles mehr bekommt über F1 und Spezifikationen.
> Aus welcher Datei führst du dein Makro aus?
ich bin hiergegangen und habe das Makro in eine leere Mappe gelegt.
Dann öffne ich die Mappe, wechsle zum Verzeichniss mit den Daten und öffne
alle darin befindlichen Mappen auf einen Rutsch (Markieren, Enter drücken)
Damit ist die Mappe mit dem Makro die erste in der Zählfolge unbd es
erscheinen alle Mappen in einem Excel (ist aber ohnehin irgendwo
einstellbar)
> Geöffnete Arbeitsmappen Durch den verfügbaren Speicher und die
> Systemressourcen begrenzt
> Arbeitsblattgröße 65.536 Zeilen mal 256 Spalten
....
> Felder pro Datenformular 32
> Benutzerdefinierte Symbolleisten pro Arbeitsmappe Durch den
> verfügbaren Speicher begrenzt
> Benutzerdefinierte Schaltflächen der Symbolleiste Durch den
> verfügbaren Speicher begrenzt
Genau da liegt die Crux ja vergraben.
Wie gesagt, Makro selbst läuft ja, (Stolze Brust: Keine Abweichungen in den
Daten)
Aber der Fehler kommt bei folgenden Systemen:
PIII; 1 GiG RAM; NT 4.0 SP6 .a; Office 97 Prof
Dual PIII; 1 GiG RAM; W2K SP3; Office 2003 prof
PIV; 1 GiG RAM; XP prof SP 2; Office XP prof
Celeron; 512 K RAM; XP prof SP 3; Office XP prof
PIII 512 K RAM; XP prof SP 2; Office 2003 prof
Und er ist absolut reproduzierbar. Der Speicherverbrauch leigt laut
Taskmanager des Gesamtsystems so bei etwas über 400 MByte - wenn der Fehler
dann kommt.
System lebt noch, aber Bildschirmanzeige kommt um den Excelrand nicht mehr
rum. Excel schliessen (aus-X-en) alles wieder OK.
Ich habe ja auch nach den Grenzen geguckt gehabt.
Es muss irgend eine interne Resource geben, seitens des Systems doer des
Excels, die ausgeht.
Alexander Bierig
Dir und all den anderen hier vielen Dank für die schnelle und prompte Hilfe.
Im Moment ist Quartalsabschluss - das bedeutet, dass wir im
Berichteerstellen ersticken, zusätzlich zum normalen Tagesgeschäft.. Daher
die etwas verspätete Antwort.
> > In den einzelnen Mappen können durchaus 150 Tabellen mit bis zu
> > 50.000 Zeilen auftreten.
>
> das Anlegen solcher Monstertabellen sollte IMO schon von Excel selbst
> unterbunden werden. Wie du selbst siehst, gibt es bei solchen
> Dateigrößen immer wieder Schwierigkeiten, die sogar bis zum Datenverlust
> führen können.
M.E ist gerade in kommerzeillem Einsatzgebiet eine der Stärken des Excels in
solchen Monstertabellen zu sehen.
Wir benutzen diese Daten nicht, um sie manuell durchzusehen, sondern um
daraus grafische Berichte zu erstellen (OK, sehr viele Grafiken aber
immerhin) Und wir komprimieren die in den Tabellen liegenen Daten noch
einmal in Übersichtstabellen.
Die Makros, welche das erledigen, greifen die Mappen allerdings sukzessiv
auf - ein kompletter Lauf dauert so ein - zwei Tage.
> Das heißt, man müsste sich jeweils ein Recordset mit dem Tabelleninhalt
> verschiedener Mappen angelegen. Danach könnte man in aller Ruhe
> Datensatz für Datensatz mit dem des anderen Recordsets vergleichen und
> das Ergebnis in einer eigenen Tabelle zwischenspeichern.
ehrlcih gesagt, bin ich nicht ganz überzeugt vom Geschwindigkeitsvorteil
zweier Rekordsets, welche über Join eine Sumemndifferenz bilden sollen
gegenüber einem Sverweismit einer Wenn-Bedingung (bei der Menge Tabellen)
Weil die Suche gin ja nur nach "Gibt es irgend eine einzige Abweichung? Egal
wie? Wenn ja den SQL-Programmierer (mich) hauen gehen"
> Eine andere Möglichkeit besteht darin, nacheinander je zwei Dateien zu
> öffnen, den Inhalt je einer Tabelle in zwei eigene zu kopieren und die
> Mappen wieder zu schließen. Anschließend führt man den Vergleich durch.
Wie ehrlich zugegeben - das wollte ich ja vermeiden, dass ich mich jetzt
noch ums korrekte Öffnen der richtigen Mappen kümmern muss
MfG Alex.
Alexander Bierig
vielen Dank für den Code.
> > das Anlegen solcher Monstertabellen sollte IMO schon von Excel selbst
> > unterbunden werden.
>
> Wäre ich auch für, wo darf ich unterschreiben? ;-)
hey Leute, ein Freund von mir mag Excel nciht: "Damit kann man auch Bilder
malen und Briefe schreiben"
Es ist natürlich keine Datenbank, aber m.E gerade für Berge von Daten ein
eigentlich (abgesehen von manchen zickigen Eigenheiten) ein echt wertvollen
Tool: FÜR GROSSE Datenmengen 8-))
> > dass bei 2K der verfügbare Speicher für die Anwendung 8 MiB, Daten 1 GiB
> > und Datenverarbeitung 64 MiB beträgt.
>
> Gutes Gedächtnis. Die Seite ist im Archiv wieder online gestellt unter:
>
http://web.archive.org/web/20040204105931/195.186.84.74/xlimits/speicher.htm
> (allerdings funktionieren da bei mir die Bilder nicht)
ist auch ätzend langsam aber toll die Seite. Es seiht nach diesen
Erklärungen ja fast so aus, als ob Excel für seine Zeier auf die
Zelleninhalte die Luft ausgeht...
> Ich will bei der Anzahl an Zeilen mal hoffen, dass die Daten in
> Tabellenform vorliegen.
NUR als tabellen - sie sind der Abzug einer etwas grösseren
SQL-Serverdatenbank.
> > Das heißt, man müsste sich jeweils ein Recordset mit dem Tabelleninhalt
> > verschiedener Mappen angelegen.
> rec.Open "Select distinct [" & strName & "$].* From [" & strName & "$]
> Left Outer Join [Tabelle3$] On [" & strName & "$].[ich] =
[Tabelle3$].[ich]
> Where [Tabelle3$].[ich] Is Null", ...
das distinct ist unnötig, innerhalb einer Tabelle ist jede Zeile absolut
eindeutig (über alle Felder betrachtet!)
> Oder man öffnet Recordsets zu beiden Mappen und speichert sie dann als
> Textdatei in einem Verzeichnis, um dann darüber einen direkten
> Join-Vergleich durchführen zu können. Da ist dann zwar die Festplatte
> dauernd im zusätzlich im Zugriff, ich habe damit aber auch ganz gute
> Erfahrungen beim Recordset-Vergleich gemacht.
ich gestehe, nachdem ich die Daten erst von einem SQL-Server geholt hatte
wollte ich die "quik'ndirty"-Schnelllösung ziehen (nachdem die Daten bereits
erstellt waren)
> Der Beispielcode dazu ist etwas länger, daher habe ich ihn einmal ganz
nach
> hinten gepackt.
>
> Das war in meinen bisherigen Tests zumindest deutlich schneller, als die
> Recordsets Feld für Feld und Datensatz für Datensatz zu vergleichen.
Ich habe auch etwas Bauchschmerzen, was die Geschwindigkeit des Erstellens
der Textdateien angeht, da zum Erstellen Zeilen/Feldweise übers Recordset
laufen muss (so wie ich den Code unten las) obwohl das Füllen des RS aus dem
Excel slebst ja schnell ist.
Ich gestehe aber, dass mir im Moment die zeit für den Vergleich mit meinen
Datenhaufen angeht. Excel ist ohne Bildschirmaktualisierung sehr schnell mit
dem Formeltext in die Zelle und anschliessenden Filldown/Copy/paste Werte
sowie einem Wenn(zelle1=zelle2 dann,sonst)
>
> So, soweit meine hoffentlich hilfreichen Ergänzungen zu Michaels Beitrag.
Deine Erklärungen waren sehr hilfreich - ich danke Dir.
>
> Greetinx aus Kiel
> Reiner
> --
> Ein Programm sollte nicht nur Hand und Fuss,
> sondern auch Herz und Hirn haben.
> (Michael Anton)
Grüsse aus dem wilden Süden
Reiner Wolff
*Alexander Bierig* schrieb:
>>> das Anlegen solcher Monstertabellen sollte IMO schon von Excel selbst
>>> unterbunden werden.
>> Wäre ich auch für, wo darf ich unterschreiben? ;-)
> hey Leute, ein Freund von mir mag Excel nciht: "Damit kann man auch Bilder
> malen und Briefe schreiben"
Ja, man *kann* sich auch eine Frikadelle ans Knie nageln ;-)
> Es ist natürlich keine Datenbank, aber m.E gerade für Berge von Daten ein
> eigentlich (abgesehen von manchen zickigen Eigenheiten) ein echt wertvollen
> Tool: FÜR GROSSE Datenmengen 8-))
Das ist ja eben Geschmackssache.
>> Ich will bei der Anzahl an Zeilen mal hoffen, dass die Daten in
>> Tabellenform vorliegen.
>
> NUR als tabellen - sie sind der Abzug einer etwas grösseren
> SQL-Serverdatenbank.
Wenn sie das sind, dann vergleiche die Daten auf dem SQL-Server. Dieser ist
dafür programmiert mit derartigen Mengen umzugehen. Du wirst vermutlich
damit die Abarbeitung deutlich beschleunigen. Excel mag ein tolles *Tool*
sein, aber der SQL-Server ist definitiv besser geeignet grosse Datenmengen
zu analysieren. Diese Aussage hängt aber natürlich sehr eng mit den
persönlichen Kenntnissen von Excel-Funktionen und T-SQL zusammen.
>>> Das heißt, man müsste sich jeweils ein Recordset mit dem Tabelleninhalt
>>> verschiedener Mappen angelegen.
>> rec.Open "Select distinct [" & strName & "$].* From [" & strName & "$]
>> Left Outer Join [Tabelle3$] On [" & strName & "$].[ich] =
>> [Tabelle3$].[ich]
>> Where [Tabelle3$].[ich] Is Null", ...
> das distinct ist unnötig, ...
Fein, dann wird der Abgleich schneller.
> ...innerhalb einer Tabelle ist jede Zeile absolut
> eindeutig (über alle Felder betrachtet!)
Über alle Felder betrachtet sicherlich, allerdings liefert 'Select *' die
internen Systemspalten nicht mit. Da eine Tabelle auf dem SQL-Server nicht
zwingend einen Primärschlüssel voraussetzt (auch wenn man immer einen
setzen sollte), stimmt Deine Aussage so nicht. Hoffentlich stimmt sie aber
für Deine Daten ;-)
>> Oder man öffnet Recordsets zu beiden Mappen und speichert sie dann als
>> Textdatei in einem Verzeichnis, um dann darüber einen direkten
>> Join-Vergleich durchführen zu können. Da ist dann zwar die Festplatte
>> dauernd im zusätzlich im Zugriff, ich habe damit aber auch ganz gute
>> Erfahrungen beim Recordset-Vergleich gemacht.
>
> ich gestehe, nachdem ich die Daten erst von einem SQL-Server geholt hatte
> wollte ich die "quik'ndirty"-Schnelllösung ziehen (nachdem die Daten bereits
> erstellt waren)
>> Der Beispielcode dazu ist etwas länger, daher habe ich ihn einmal ganz
>> nach hinten gepackt.
>> Das war in meinen bisherigen Tests zumindest deutlich schneller, als die
>> Recordsets Feld für Feld und Datensatz für Datensatz zu vergleichen.
> Ich habe auch etwas Bauchschmerzen, was die Geschwindigkeit des Erstellens
> der Textdateien angeht, da zum Erstellen Zeilen/Feldweise übers Recordset
> laufen muss (so wie ich den Code unten las) obwohl das Füllen des RS aus dem
> Excel slebst ja schnell ist.
Ok, wenn Du Zweifel an der Geschwindigkeit hast, probier's aus! Wenn Excel
so schnell mit SVerweis ist, warum dauert es dann 2 Tage?
Ausserdem brauchen wir uns darüber ja nicht mehr unterhalten, da der
Abgleich ja auf den SQL-Server gehört ;-)
> Ich gestehe aber, dass mir im Moment die zeit für den Vergleich mit meinen
> Datenhaufen angeht. Excel ist ohne Bildschirmaktualisierung sehr schnell mit
> dem Formeltext in die Zelle und anschliessenden Filldown/Copy/paste Werte
> sowie einem Wenn(zelle1=zelle2 dann,sonst)
Sehr schnell ist wohl relativ.
Derartige Bearbeitungszeiträume eines Automatismus wäre für mich untragbar.
>> So, soweit meine hoffentlich hilfreichen Ergänzungen zu Michaels Beitrag.
> Deine Erklärungen waren sehr hilfreich - ich danke Dir.
Bitte, gern geschehen.
Greetinx aus Kiel
Reiner
--
All Computers wait at the same speed !
Michael Schwimmer
"Alexander Bierig" schrieb:
> Dir und all den anderen hier vielen Dank für die schnelle und
> prompte Hilfe.
> Im Moment ist Quartalsabschluss - das bedeutet, dass wir im
> Berichteerstellen ersticken, zusätzlich zum normalen Tagesgeschäft..
> Daher die etwas verspätete Antwort.
in einer Newsgroup ist das kein Problem ;-)
> > > In den einzelnen Mappen können durchaus 150 Tabellen mit bis zu
> > > 50.000 Zeilen auftreten.
> > das Anlegen solcher Monstertabellen sollte IMO schon von Excel
> > selbst unterbunden werden. Wie du selbst siehst, gibt es bei
> > solchen Dateigrößen immer wieder Schwierigkeiten, die sogar bis
> > zum Datenverlust führen können.
> M.E ist gerade in kommerzeillem Einsatzgebiet eine der Stärken des
> Excels in solchen Monstertabellen zu sehen.
Gerade im kommerziellem Bereich, wo ein Datenverlust und aufgewendete
Zeit bares Geld kosten, sollte so etwas ein asolutes Tabu sein.
> Wir benutzen diese Daten nicht, um sie manuell durchzusehen, sondern
> um daraus grafische Berichte zu erstellen (OK, sehr viele Grafiken
> aber immerhin) Und wir komprimieren die in den Tabellen liegenen
> Daten noch einmal in Übersichtstabellen.
Dann würde ich auch nur die fertigen, komprimierten Berichte speichern,
und den Rest ganz schnell wieder löschen.
> Die Makros, welche das erledigen, greifen die Mappen allerdings
> sukzessiv auf - ein kompletter Lauf dauert so ein - zwei Tage.
Ein bis zwei Tage? IMO inakzeptabel!
Warum sich nicht die Daten direkt aus der Datenbank holen, anstatt
diese vorher in Excel Tabellen zwischenzuspeichern?
Und selbst wenn sich das nicht vermeiden lässt, dann sicherlich nicht
150 Tabellenblätter in einer Mappe speichern, das ist ein Designfehler.
Bei uns (EVU) fallen auch jede Menge Daten an. Allein die
Viertelstundenwerte eines Messwertes benötigen über 35000 Datensätze im
Jahr, und es werden Zigtausende verschiedener Messwerte in Oracle-
Datenbanken abgelegt.
Wenn ich irgendwelche Daten benötige, hole ich mir mit Excel nur die
absolut notwendigen Daten. Das sind dann die Daten eines Tag, einer
Woche, eines Monats, ein Quartals und maximal eines Jahres.
Es käme aber niemand auf die Idee, diese extrahierten Daten dann
dauerhaft als Excel-Datei zu speichern, das wäre dann unnötige
Redundanz in Reinform. Datenhaltung- und Sicherung, das ist alleinige
Aufgabe der Datenbank.
> ehrlcih gesagt, bin ich nicht ganz überzeugt vom
> Geschwindigkeitsvorteil zweier Rekordsets, welche über Join eine
> Sumemndifferenz bilden sollen gegenüber einem Sverweismit einer
> Wenn-Bedingung (bei der Menge Tabellen)
Datenbanken sind auf große Datenmengen und auf solche Abfragen
spezialisiert, die Verarbeitungsgeschwindigkeit gegenüber irgendwelchen
Methoden von Excel dürfte um ein vielfaches höher liegen.
Selbst wenn man nur auf Excel-"Datenbanken" mit ADO zugreift, sollte
man mit einer vernünftigen SQL-Abfrage erheblich schneller sein. Anders
als mir, sollte dir das als SQL-Programmierer doch richtig leicht
fallen. Ich würde auf jeden Fall probieren, so etwas in SQL zu
erschlagen.
> Weil die Suche gin ja nur nach "Gibt es irgend eine einzige
> Abweichung? Egal wie? Wenn ja den SQL-Programmierer (mich) hauen
> gehen"
Eventuell schon beim Erstellen Checksummen bilden und erst einmal nur
diese vergleichen.
Aber bei Abweichungen auch nicht gleich den SQL-Programmierer hauen,
immer erst einmal den Fehler auf die interne Darstellung von
Gleitkommazahlen bei Rechnern schieben ;-)
> > Eine andere Möglichkeit besteht darin, nacheinander je zwei
> > Dateien zu öffnen, den Inhalt je einer Tabelle in zwei eigene zu
> > kopieren und die Mappen wieder zu schließen. Anschließend führt
> > man den Vergleich durch.
> Wie ehrlich zugegeben - das wollte ich ja vermeiden, dass ich mich
> jetzt noch ums korrekte Öffnen der richtigen Mappen kümmern muss
Da wirst du IMO nicht herumkommen.
chris
Hab hier gefunden was ich schon lange suchte, nur - wie schaffe ich
einen select über die Spalte A?? Select [A$] from [Tabelle1$]; ist es
auf jeden Fall nicht. Auch die Überschrift nimmt er nicht, was mache
ich falsch??
Danke!
Christian Meier
Melanie Breden
chris schrieb:
> Hab hier gefunden was ich schon lange suchte,
und das war? :-)
> nur - wie schaffe ich
> einen select über die Spalte A?? Select [A$] from [Tabelle1$]; ist es
> auf jeden Fall nicht. Auch die Überschrift nimmt er nicht, was mache
> ich falsch??
Generell geht das mit:
Columns("A").Select
Oder wenn du von einem anderen Sheet zur Tabelle1 wechseln willst:
Application.GoTo Worksheets("Tabelle1").Columns("A")
Was genau willst du machen, wenn die ganze Spalte markiert ist?
--
Mit freundlichen Grüssen
Melanie Breden
- Microsoft MVP für Excel -
http://excel.codebooks.de (Das Excel-VBA Codebook)
#Excel-Auftragsprogrammierung#
Reiner Wolff
*chris* schrieb:
> Hab hier gefunden was ich schon lange suchte, nur - wie schaffe ich
> einen select über die Spalte A?? Select [A$] from [Tabelle1$]; ist es
> auf jeden Fall nicht. Auch die Überschrift nimmt er nicht, was mache
> ich falsch??
Wenn ich mich recht erinnere kannst Du mit einem Select nicht direkt die
ganze Spalte angeben. Als Workaround kannst Du aber von der ersten bis zur
letzten Zeile den Bereich angeben:
SELECT * FROM [Sheet1$A1:$A65535]
HTH
Greetinx aus Kiel
Reiner
--
REALITY.SYS is corrupt. Reboot universe? (y/n)