15
Verwaltungsprogramm in Access - Performance
Einer meiner Kunden hat sich (von einem anderen Dienstleister) ein Verwaltungsprogramm (Kunden, Artikel, Rechnungen) in Access programmieren lassen.
Nun wird immer wieder über die Performance geklagt und alles auf den Server geschoben.
Wir haben den Server gerade erst neu installiert.
Windows SBS 2008 Premium, HP ML350 G5, Quad-Core, 8GB RAM, RAID-10.
Das einzige was am Server liegt ist die Access-Datenbank (mdb).
Diese wird vom Client aus aufgerufen.
Das eigentliche "Programm" (auch mdb) liegt am Client.
So wie ich das als Access-Laie sehe ist das doch ein reiner File-Zugriff auf den Server.
Das heitß, die Server-Performance spielt (kaum) eine Rolle.
Richtig?
Ich nehme an es wäre für die Performance auch besser die Datenbank nicht filebasiert (mdb) zu haben sondern auf einen SQL-Server zu legen?
Richtig?
Vielen Dank im voraus für Eure Tipps!
Grüße, FFK
Windows SBS 2008 Premium, HP ML350 G5, Quad-Core, 8GB RAM, RAID-10.
Das einzige was am Server liegt ist die Access-Datenbank (mdb).
Diese wird vom Client aus aufgerufen.
Das eigentliche "Programm" (auch mdb) liegt am Client.
So wie ich das als Access-Laie sehe ist das doch ein reiner File-Zugriff auf den Server.
Das heitß, die Server-Performance spielt (kaum) eine Rolle.
Richtig?
Ich nehme an es wäre für die Performance auch besser die Datenbank nicht filebasiert (mdb) zu haben sondern auf einen SQL-Server zu legen?
Richtig?
Vielen Dank im voraus für Eure Tipps!
Grüße, FFK
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 119729
Url: https://administrator.de/contentid/119729
Printed on: April 19, 2024 at 23:04 o'clock
15 Comments
Latest comment
Deine Annahme ist richtig. Bei Access-Datenbanken spielt die Performance des Clients eine Rolle. Auch ist bei einer Auslagerung auf einen Fileserver die Netzwerksanbindung wichtig, da immer die komplette Datenbank zum Client übertragen wird. Ein SQL Server kann die Hardware des Servers nutzen (vor allem wenn so viel wie möglich in Stored Procedures gesteckt wird) und spart Bandbreite, da er nur die angefragten, bzw. geänderten Daten übers Netz schickt. Die Frage ist nur, ob Eure Software ohne weiteres auf einen SQL-Server umgestellt werden kann. Wenn die Accessdb jedoch in FE und BE aufgeteilt ist (scheint Deiner Beschreibung nach so zu sein) und SQL statt ausschließlich VB verwendet wurde, könnte es mit ein wenig Aufwand möglich sein.
Grüße p
Nachtrag: Wie ist denn die Performance von dem Programm, wenn es auf einem der Clients lokal ausgefürt wird, also die Datenbankdatei nicht übers Netz geht?
Grüße p
Nachtrag: Wie ist denn die Performance von dem Programm, wenn es auf einem der Clients lokal ausgefürt wird, also die Datenbankdatei nicht übers Netz geht?
Zitat von @perseues:
Deine Annahme ist richtig. Bei Access-Datenbanken spielt die
Performance des Clients eine Rolle. Auch ist bei einer Auslagerung
auf einen Fileserver die Netzwerksanbindung wichtig, da immer die
komplette Datenbank zum Client übertragen wird. Ein SQL Server
kann die Hardware des Servers nutzen (vor allem wenn so viel wie
möglich in Stored Procedures gesteckt wird) und spart Bandbreite,
da er nur die angefragten, bzw. geänderten Daten übers Netz
schickt. Die Frage ist nur, ob Eure Software ohne weiteres auf einen
SQL-Server umgestellt werden kann. Wenn die Accessdb jedoch in FE und
BE aufgeteilt ist (scheint Deiner Beschreibung nach so zu sein) und
SQL statt ausschließlich VB verwendet wurde, könnte es mit
ein wenig Aufwand möglich sein.
Deine Annahme ist richtig. Bei Access-Datenbanken spielt die
Performance des Clients eine Rolle. Auch ist bei einer Auslagerung
auf einen Fileserver die Netzwerksanbindung wichtig, da immer die
komplette Datenbank zum Client übertragen wird. Ein SQL Server
kann die Hardware des Servers nutzen (vor allem wenn so viel wie
möglich in Stored Procedures gesteckt wird) und spart Bandbreite,
da er nur die angefragten, bzw. geänderten Daten übers Netz
schickt. Die Frage ist nur, ob Eure Software ohne weiteres auf einen
SQL-Server umgestellt werden kann. Wenn die Accessdb jedoch in FE und
BE aufgeteilt ist (scheint Deiner Beschreibung nach so zu sein) und
SQL statt ausschließlich VB verwendet wurde, könnte es mit
ein wenig Aufwand möglich sein.
Danke für Deine Erläuterungen!
Was meinst Du mit FE und BE?
FrontEnd und BackEnd?
Nachtrag: Wie ist denn die Performance von dem Programm, wenn es auf
einem der Clients lokal ausgefürt wird, also die Datenbankdatei
nicht übers Netz geht?
einem der Clients lokal ausgefürt wird, also die Datenbankdatei
nicht übers Netz geht?
Habe ich noch nicht getestet.
Werde ich aber tun!
Danke nochmals!
Grüße, FFK
Danke für Deine Erläuterungen!
Was meinst Du mit FE und BE?
FrontEnd und BackEnd?
Was meinst Du mit FE und BE?
FrontEnd und BackEnd?
Genau. Die Anwendungslogik steckt dabei in dem am Client installiertem Teil.
Wenn die Clients wenig RAM und eine schlechte Netzanbindung haben und die Datenbank mehrere hundert MB groß ist, kann es schon eng werden.
Grüße p
Hi !
Das typische Erlebnis und teilweise auch tägliche Brot eines Administrators, der es mit mülliger Software zu tun hat, weil der Softwareanbieter kein Geld in die Weiterbildung seiner Mitarbeiter (auch und gerade auf der Führungsebene) stecken will. Wo es doch heute hervorragende Datenbankserver für kleines bis kein Geld (Opensource) gibt.
Ein leidiges Thema....
Da die meisten Softwarefirmen auf dem hohen Ross sitzen (und damit meist auch einfahren...gottseidank, solche Software wird weniger) und meist nicht mit sich reden lassen, wirst Du wohl ein schnelleres Netzwerk, schnellere Clients oder gar beides hinstellen müssen. Habt Ihr denn keine Bestandsaufnahme des Netzwerks gemacht, als Ihr den Server erneuert habt?
mrtux
Zitat von @itdienstleister:
Das einzige was am Server liegt ist die Access-Datenbank (mdb).
Diese wird vom Client aus aufgerufen.
Das einzige was am Server liegt ist die Access-Datenbank (mdb).
Diese wird vom Client aus aufgerufen.
Das typische Erlebnis und teilweise auch tägliche Brot eines Administrators, der es mit mülliger Software zu tun hat, weil der Softwareanbieter kein Geld in die Weiterbildung seiner Mitarbeiter (auch und gerade auf der Führungsebene) stecken will. Wo es doch heute hervorragende Datenbankserver für kleines bis kein Geld (Opensource) gibt.
Ein leidiges Thema....
Da die meisten Softwarefirmen auf dem hohen Ross sitzen (und damit meist auch einfahren...gottseidank, solche Software wird weniger) und meist nicht mit sich reden lassen, wirst Du wohl ein schnelleres Netzwerk, schnellere Clients oder gar beides hinstellen müssen. Habt Ihr denn keine Bestandsaufnahme des Netzwerks gemacht, als Ihr den Server erneuert habt?
mrtux
Performance von Access-DBs.
Da gibt es seit min. 15 Jahren so eine Formel (!), daß ab 5 User nur noch mit SQL-Datenbanken gearbeitet werden kann... Blödsinn.
Ich habe ein Netzwerk mit Access 2.0 und 2000-DB bei einem Kunden in Betreuung und Programmierung auf einem Novell-Server. Da gab es auch so versch. Einstellungen, die den Netzwerk-Transport betrafen, da würde ich auch mal ansetzen.
Ob der BE auf dem Client oder im Netz liegt sollte i.d.R. egal sein.
Access 2.0 ist nach wie vor rattenschnell, alles andere ist eher lahm.
Man kann bei der Programmierung und bei der Definition der Tabellen etc. (Indizies) Performance rauskitzeln.
Ich arbeite bis jetzt auch nur mit Jet-DBs (file-basierter Zugriff) und kann eine durchaus brauchbare Speed erzeugen.
Wenn die Abfragen aber so konstruiert sind, daß immer alle Daten über den Draht müssen, dann wird es lahm. Gerade letztens hatte ich da so ein Aha-Erlebnis, wo ich eine Abfrage enorm beschleunigen konnte, weil ich Where-Abfragen an anderer Stelle definiert habe.
Wie ist denn die Programmierfirma auf den Bolzen gekommen, daß es am Server liegt ? Haben die eine Referenz-Installation auf einem anderem Netzwerk laufen, wo es schneller läuft ?
Da gibt es seit min. 15 Jahren so eine Formel (!), daß ab 5 User nur noch mit SQL-Datenbanken gearbeitet werden kann... Blödsinn.
Ich habe ein Netzwerk mit Access 2.0 und 2000-DB bei einem Kunden in Betreuung und Programmierung auf einem Novell-Server. Da gab es auch so versch. Einstellungen, die den Netzwerk-Transport betrafen, da würde ich auch mal ansetzen.
Ob der BE auf dem Client oder im Netz liegt sollte i.d.R. egal sein.
Access 2.0 ist nach wie vor rattenschnell, alles andere ist eher lahm.
Man kann bei der Programmierung und bei der Definition der Tabellen etc. (Indizies) Performance rauskitzeln.
Ich arbeite bis jetzt auch nur mit Jet-DBs (file-basierter Zugriff) und kann eine durchaus brauchbare Speed erzeugen.
Wenn die Abfragen aber so konstruiert sind, daß immer alle Daten über den Draht müssen, dann wird es lahm. Gerade letztens hatte ich da so ein Aha-Erlebnis, wo ich eine Abfrage enorm beschleunigen konnte, weil ich Where-Abfragen an anderer Stelle definiert habe.
Wie ist denn die Programmierfirma auf den Bolzen gekommen, daß es am Server liegt ? Haben die eine Referenz-Installation auf einem anderem Netzwerk laufen, wo es schneller läuft ?
Hi !
Ahh, die Formel kannte ich bisher noch gar nicht, ab 10 Arbeitsplätzen installiere ich dann wieder Dbase, damit es den Leuten nicht zu wohl wird.
Was auch zum Thema Weiterbildung gehört, wenn eine Abfrage "ungeschickt" formuliert wurde, kann die im Extremfall auch einen SQL-Server in die Knie zwingen.
Wo wir dann wieder bei der Qualität von Softwareentwicklung sind und unsere Argumente gar kein Gegensatz darstellen müssen.
mrtux
Zitat von @BigWumpus:
Da gibt es seit min. 15 Jahren so eine Formel (!), daß ab 5
User nur noch mit SQL-Datenbanken gearbeitet werden kann...
Blödsinn.
Da gibt es seit min. 15 Jahren so eine Formel (!), daß ab 5
User nur noch mit SQL-Datenbanken gearbeitet werden kann...
Blödsinn.
Ahh, die Formel kannte ich bisher noch gar nicht, ab 10 Arbeitsplätzen installiere ich dann wieder Dbase, damit es den Leuten nicht zu wohl wird.
Man kann bei der Programmierung und bei der Definition der Tabellen
etc. (Indizies) Performance rauskitzeln.
etc. (Indizies) Performance rauskitzeln.
Was auch zum Thema Weiterbildung gehört, wenn eine Abfrage "ungeschickt" formuliert wurde, kann die im Extremfall auch einen SQL-Server in die Knie zwingen.
Wo wir dann wieder bei der Qualität von Softwareentwicklung sind und unsere Argumente gar kein Gegensatz darstellen müssen.
mrtux
Moin alle,
es wäre schade, wenn dieser durchaus interessante Thread durch Spekulationen, urban legends und unzulässige Verallgemeinerungen vor einer Annäherung an eine Lösung aus dem Ruder läuft.
Es sind (aus meiner Sicht) die beiden wichtigsten Vor-Klärungsfragen gestellt und verstanden worden:
Erst nach Antworten darauf lässt sich doch darüber nachdenken, wo wahrscheinlich der Flaschenhals ist und
Bitte lasst also itdienstleister erst mal recherchieren.
Wohlgemerkt - ich halte alle Kommentatoren hier für kompetent und erfahren, aber der Beitrag droht aus dem Ruder zu laufen.
Grüße
Biber
es wäre schade, wenn dieser durchaus interessante Thread durch Spekulationen, urban legends und unzulässige Verallgemeinerungen vor einer Annäherung an eine Lösung aus dem Ruder läuft.
Es sind (aus meiner Sicht) die beiden wichtigsten Vor-Klärungsfragen gestellt und verstanden worden:
Wie ist denn die Performance von dem Programm, wenn es auf einem der Clients lokal ausgefürt wird, also die Datenbankdatei nicht übers Netz geht? [von perseues ]
Wie ist denn die Programmierfirma auf den Bolzen gekommen, daß es am Server liegt ? Haben die eine Referenz-Installation auf einem anderem Netzwerk laufen, wo es schneller läuft ? [von BigWumpus]
Erst nach Antworten darauf lässt sich doch darüber nachdenken, wo wahrscheinlich der Flaschenhals ist und
- ob sich die Performance verbessern lässt, ohne die Appz an sich überhaupt anzufassen
- das Netzwerk suboptimal auf die Erfordernisse von einer MSAccess "Client/Server"-Lösung konfguriert ist
- oder ob die Appz selbst vielleicht nur von jemand zusammengeklickt wurde, der SQLs noch heute als Fachbegriff für die Vermarktung eines Kino-Hits als Endlos-Serie hält.
Bitte lasst also itdienstleister erst mal recherchieren.
Wohlgemerkt - ich halte alle Kommentatoren hier für kompetent und erfahren, aber der Beitrag droht aus dem Ruder zu laufen.
Grüße
Biber
Zitat von @BigWumpus:
Wie ist denn die Programmierfirma auf den Bolzen gekommen, daß
es am Server liegt ? Haben die eine Referenz-Installation auf einem
anderem Netzwerk laufen, wo es schneller läuft ?
Wie ist denn die Programmierfirma auf den Bolzen gekommen, daß
es am Server liegt ? Haben die eine Referenz-Installation auf einem
anderem Netzwerk laufen, wo es schneller läuft ?
Wohl kaum ... das ist eine für den Kunden programmierte Individual-Software (Datenbank).
Zitat von @perseues:
Wenn die Clients wenig RAM und eine schlechte Netzanbindung haben und
die Datenbank mehrere hundert MB groß ist, kann es schon eng
werden.
Wenn die Clients wenig RAM und eine schlechte Netzanbindung haben und
die Datenbank mehrere hundert MB groß ist, kann es schon eng
werden.
Ich habe jetzt nachgesehen:
Die Datenbank/Anwendung besteht aus einer mdw und zwei mdb's (6 und 16MB groß).
Leider konnte ich die Performance noch nicht testen, wenn die DB am Client lokal liegt.
Grüße, FFK
Servus,
was ist denn nun aus deiner Recherche geworden?
Gruss
was ist denn nun aus deiner Recherche geworden?
- Und als Nachfrage, sind da auch bilder in die DB eingebunden?
- Komprimieren/Reparieren der Access DB durchgeführt?
Gruss
Zitat von @60730:
was ist denn nun aus deiner Recherche geworden?
was ist denn nun aus deiner Recherche geworden?
Ich war noch nicht beim Kunden vor Ort.
Konnte daher die Performance noch nicht testen wenn alle Dateien am Client liegen.
* Und als Nachfrage, sind da auch bilder in die DB eingebunden?
Nein.
* Komprimieren/Reparieren der Access DB durchgeführt?
Nein.
(Da es nicht meine Anwendung ist, sehe ich auch weiterhin von solchen Möglichkeiten ab - das gibt Ärger mit dem anderen Dienstleister)
Wie ich aber schon am 13.07. geschrieben habe:
Die Datenbank/Anwendung besteht aus einer mdw und zwei mdb's (6 und 16MB groß).
Also nicht gerade gigantisch viel ...
Ich halte Euch auf dem Laufenden wenn sich etwas neues ergibt!
Grüße, FFK
Servus,
ganz ehrlich - das ist eine ganz schlechte Einstellung...
Rede mit dem anderen Dienstleister, wenn du einen neuen Server aufgestellt hast (und der ne andere IP/ anderen Namen - als der vorgänger hat) - was ich leider annehmen muß - weils nicht geschrieben steht.
Und du dir die Dbs nicht angesehen hast/willst - wer sagt dir dann, dass intern nicht ein Weg hart verdrahtet war und jetzt via x y oder z aussen rum aufgelöst werden muß - und so die performance in den Keller zieht?
Gruß
(Da es nicht meine Anwendung ist, sehe ich auch weiterhin von solchen Möglichkeiten ab - das gibt Ärger mit dem anderen Dienstleister)
ganz ehrlich - das ist eine ganz schlechte Einstellung...
Rede mit dem anderen Dienstleister, wenn du einen neuen Server aufgestellt hast (und der ne andere IP/ anderen Namen - als der vorgänger hat) - was ich leider annehmen muß - weils nicht geschrieben steht.
Und du dir die Dbs nicht angesehen hast/willst - wer sagt dir dann, dass intern nicht ein Weg hart verdrahtet war und jetzt via x y oder z aussen rum aufgelöst werden muß - und so die performance in den Keller zieht?
Gruß
Ganz ehrlich - Du bist auch ein professioneller Nörgler!
Außerdem hast Du im Zitat nicht alles erfasst!
Ich sagte nicht, daß ich nicht mit dem anderen Dienstleister rede.
Ich sagte nur, daß ich nicht in fremden Datenbanken herumkomprimiere/repariere.
Der neue Server hat die gleiche IP und den gleichen Namen wie der alte.
Laut dem anderen Dienstleister (der kein Profi-Programmierer ist) liegt es "am Server und an der Arbeitsspeicherauslastung am Server".
Das kommt mir aber komisch vor - daher meine Fragen.
Grüße, FFK
Außerdem hast Du im Zitat nicht alles erfasst!
Ich sagte nicht, daß ich nicht mit dem anderen Dienstleister rede.
Ich sagte nur, daß ich nicht in fremden Datenbanken herumkomprimiere/repariere.
Der neue Server hat die gleiche IP und den gleichen Namen wie der alte.
Laut dem anderen Dienstleister (der kein Profi-Programmierer ist) liegt es "am Server und an der Arbeitsspeicherauslastung am Server".
Das kommt mir aber komisch vor - daher meine Fragen.
Grüße, FFK
Hallo FFK,
mal was grundsätzliches zu Access-Datenbanken.
Für eine Access-DB ist die Zugriffsgeschwindigkeit der Server-Festplatte und das Netzwerk entscheidend. Der RAM-Speicher des Servers wird gar nicht von Access genutzt!
Ein Backend auf dem Server dient nur als Datenspeicher, mehr nicht!
Regelmäßiges Defrag auf dem Server ist zwingend notwendig! Es steigert die Performance bei DBs erheblich! Bitte nicht das vom Server verwenden!!!
Wie schon gesagt wurde: regelmäßiges Komprimieren der DB ist genau so wichtig und gut für die Performance.
Komprimieren und anschließendes Defragmentieren ist optimal.
Aber:
Bei 90% aller Performance-Probleme ist die schlechte Programmierung die Bremse.
Häufig hilft auch die Anpassung der Grundeinstellungen in Access am Client.
Clients mit vollem TEMP-Verzeichnis, nicht defragmentiert und nur mit 512 KB Ram sind tödlich langsam bei Datenbanken. Beim Client wichtig: RAM und schnelle Festplatte (für die Auslagerung der Daten wenn diese die RAM-Kapazität übersteigen).
Netzwerktechnisch solltest du keine dynamischen IPs haben. Die Performance kann durch manuelles umstellen auf Fullduplex gesteigert werden (je nach verwendetem Switch). QoS sollte ausgeschaltet sein!
Auch Antivirusprogramme (und dann noch auf beiden Seiten) können die Performance erheblich belasten!!
Tipp1: deaktivieren hilft da nicht, nur deinstallieren
Tipp2: Norton, Kaspersky, McAffee sind als Performancebremsen bekannt
btw die Größe der DB-Dateien auf dem Client haben keine Auswirkungen. Das Frontend holt ja nur die Daten und zeigt sie an. Da aber per Programmierung definiert werden kann/muss wie viel Daten geholt werden, ist das das Entscheidende.
ym2c
Grüße aus Schönberg (Lübeck)
Wolfgang
(Netwolf)
mal was grundsätzliches zu Access-Datenbanken.
Für eine Access-DB ist die Zugriffsgeschwindigkeit der Server-Festplatte und das Netzwerk entscheidend. Der RAM-Speicher des Servers wird gar nicht von Access genutzt!
Ein Backend auf dem Server dient nur als Datenspeicher, mehr nicht!
Regelmäßiges Defrag auf dem Server ist zwingend notwendig! Es steigert die Performance bei DBs erheblich! Bitte nicht das vom Server verwenden!!!
Wie schon gesagt wurde: regelmäßiges Komprimieren der DB ist genau so wichtig und gut für die Performance.
Komprimieren und anschließendes Defragmentieren ist optimal.
Aber:
Bei 90% aller Performance-Probleme ist die schlechte Programmierung die Bremse.
Häufig hilft auch die Anpassung der Grundeinstellungen in Access am Client.
Clients mit vollem TEMP-Verzeichnis, nicht defragmentiert und nur mit 512 KB Ram sind tödlich langsam bei Datenbanken. Beim Client wichtig: RAM und schnelle Festplatte (für die Auslagerung der Daten wenn diese die RAM-Kapazität übersteigen).
Netzwerktechnisch solltest du keine dynamischen IPs haben. Die Performance kann durch manuelles umstellen auf Fullduplex gesteigert werden (je nach verwendetem Switch). QoS sollte ausgeschaltet sein!
Auch Antivirusprogramme (und dann noch auf beiden Seiten) können die Performance erheblich belasten!!
Tipp1: deaktivieren hilft da nicht, nur deinstallieren
Tipp2: Norton, Kaspersky, McAffee sind als Performancebremsen bekannt
btw die Größe der DB-Dateien auf dem Client haben keine Auswirkungen. Das Frontend holt ja nur die Daten und zeigt sie an. Da aber per Programmierung definiert werden kann/muss wie viel Daten geholt werden, ist das das Entscheidende.
ym2c
Grüße aus Schönberg (Lübeck)
Wolfgang
(Netwolf)
Servus Wolfgang,
ich muß an dieser Stelle meinem Ruf als Professioneller Nörgler alle Ehre machen - sonst macht es ein anderer und bezweifelt dein Fachwissen
Oder andersherum ich kaufe ein M und verschenke ein K
zurück
ich muß an dieser Stelle meinem Ruf als Professioneller Nörgler alle Ehre machen - sonst macht es ein anderer und bezweifelt dein Fachwissen
Oder andersherum ich kaufe ein M und verschenke ein K
Clients mit vollem TEMP-Verzeichnis, nicht defragmentiert und nur mit
512 MB Ram sind tödlich langsam bei Datenbanken. Beim Client
wichtig: RAM und schnelle Festplatte (für die Auslagerung der
Daten wenn diese die RAM-Kapazität übersteigen).
Grüße aus Schönberg (Lübeck)
Wolfgang
(Netwolf)
512 MB Ram sind tödlich langsam bei Datenbanken. Beim Client
wichtig: RAM und schnelle Festplatte (für die Auslagerung der
Daten wenn diese die RAM-Kapazität übersteigen).
Grüße aus Schönberg (Lübeck)
Wolfgang
(Netwolf)
zurück
Hallo Timo,
ich würde das nie als Fachwissen bezeichnen, es ist halt die Erfahrung
Konstruktive Kritik ist immer willkommen. Nur so kann man sich weiter entwickeln und aus seinen Fehlern lernen.
Mein Motto:
Wo gearbeitet wird, passieren Fehler. Wo keine Fehler passieren .....
Grüße noch aus Schönberg (Lübeck)
Wolfgang
(Netwolf)
ich würde das nie als Fachwissen bezeichnen, es ist halt die Erfahrung
Konstruktive Kritik ist immer willkommen. Nur so kann man sich weiter entwickeln und aus seinen Fehlern lernen.
Mein Motto:
Wo gearbeitet wird, passieren Fehler. Wo keine Fehler passieren .....
Grüße noch aus Schönberg (Lübeck)
Wolfgang
(Netwolf)
