Hallo zusammen,
mich interessieren Eure Tipps/Erfahrungen bei der Ablösung einer MS
ACCESS-Lösung in einer Fachabteilung (Controlling). Und zwar existiert
eine "historisch gewachsene" Datenbank mit Informationen über
Finanzbeteiligungen; Inhalte sind i.d.R. öffentlich zugänglich und in
dem Sinne "nur" gesammelt (z.B. Anschrift, Name Geschäftsführer, ggf.
Geschäftsführerhistorie, Anteilsquote und weitere Anteilseigner;
teilweise Umsatz / EBIT der letzten x Jahre). Der Output sind entweder
Übersichtslisten oder z.B. Exporte bzw. Direktzugriffe für Serienbriefe.
Die Lösung wurde vor >15 Jahren mal mit der damaligen ACCESS-Version
erstellt, ist mittlerweile durch viele Versionen und eben so viele Hände
bzgl. Betreuung gegangen und einfach nicht mehr zeitgemäß. Jetzt wird
eine Ersatzlösung gesucht; dabei ist zunächst sowohl eine anpassbare
fertige Lösung möglich wie auch die Selbsterstellung - und für beides
hätte ich gerne Tipps.
Das in der Fachabteilung vorhandene Know-How umfasst MS Office, insb.
Excel und VBA; sowie in Grundzügen Programmierung ("Pascal", z.T. Java)
sowie SQL. Das klingt nach wenig, das Interesse und auch die
Voraussetzungen sind aber da, sich auch in andere Techniken etc.
einzuarbeiten. Zumal die Anforderungen (Stand heute) nicht besonders
hoch sind:
- Das Datenbankschema ist vorhanden; der bisherige Umfang ließe sich
auch grundsätzlich mit Exceltabellen bewältigen
- In der Regel keine gleichzeitigen Zugriffe, überschaubarer
Personenkreis <-> keine "besonderen" Anforderungen an ein
Berechtigungskonzept
- Zugriff nur innerhalb des Unternehmensnetzwerks, und zwar vom
jeweiligen Arbeitsplatzrechner (Windows) aus - keine Cloud-Lösung, keine
App
- da nur Fachanwender und überschaubarer Funktionsumfang: Keine
aufwendige GUI
- keine Mehrsprachigkeit (aber Darstellung von Unicodezeichen wäre gut)
Vor ca. 20 Jahren(!) hatte ich mich mal mit JavaServerPages und
JavaServlets sowie EJB, Tomcat/Apache beschäftigt und kenne aus den
Zeiten noch OR-Mapping. Letztlich soll die entstehende Lösung aber vor
allem durch die Abteilung selbst wartbar und (in Grenzen)
weiterentwickelbar sein. Wenn es zudem bzgl. Lizenzmodell frei wäre und
kostenlos, wären das weitere Pluspunkte. Wichtig ist, dass sich
vielleicht relativ schnell erste Umsetzungserfolge zeigen - also z.B.
Aufruf einer Website mit ersten Abfragefunktionalitäten.
Würdet Ihr anhand dieser Infos überhaupt auf Weblösungen (HTML5/JS)
gehen? Oder lieber eine Desktopanwendung (Clients) und einen DB-Server
(MariaDB) empfehlen? Ich bin da mit meinem Wissen halt wirklich nicht
mehr aktuell... Mir helfen neben Stichworten auch kurze Begründungen
oder weiterführende Links.
Eine Bitte noch: Ich sehe auch, dass dieser Forenbeitrag bzw. die
geschilderten Probleme deutlich unter dem Anforderungsniveau anderer
Fachfragen liegen - mir ist aber kein besserer Platz für eine solche
Anfrage bekannt, da ich ja eben keinen Auftrag an Freelancer vergeben
möchte noch bzgl. "irgendwas" schon festgelegt bin - entsprechend hat
auch Googeln bisher nicht weitergeholfen. Vielen Dank Euch im Voraus!
V.M. schrieb: > Die Lösung wurde vor >15 Jahren mal mit der damaligen ACCESS-Version > erstellt, ist mittlerweile durch viele Versionen und eben so viele Hände > bzgl. Betreuung gegangen und einfach nicht mehr zeitgemäß. Was ist daran nicht zeitgemäß? Es wird wohl praktisch immer so sein, dass wenn man eine bestehende Lösung komplett neu aufbauen würde (clean slate), man Dinge heute anders machen würde. Solange die bestehende Lösung aber grundsätzlich funktioniert, macht man das normalerweise nicht, wenn man nicht gerade zu viel Zeit oder Geld hat. Also: Was soll die neue Lösung können, was die alte Lösung nicht kann? V.M. schrieb: > Würdet Ihr anhand dieser Infos überhaupt auf Weblösungen (HTML5/JS) > gehen? Oder lieber eine Desktopanwendung (Clients) und einen DB-Server > (MariaDB) empfehlen? Warum sollte man das alles tun, wenn man die Funktionalität gar nicht braucht?
V.M. schrieb: > - Das Datenbankschema ist vorhanden; der bisherige Umfang ließe sich > auch grundsätzlich mit Exceltabellen bewältigen Das wäre der Wechsel von einer Katastrophe zum SuperGAU. V.M. schrieb: > Aufruf einer Website mit ersten Abfragefunktionalitäten. > Würdet Ihr anhand dieser Infos überhaupt auf Weblösungen (HTML5/JS) > gehen? Oder lieber eine Desktopanwendung (Clients) und einen DB-Server > (MariaDB) empfehlen? Das ist die sinnvollste Lösung. Nimm das was dir besser liegt. Wenn es etwas einfacher sein kann, wäre Sqlite auch noch eine Idee. Heiner schrieb: > Was ist daran nicht zeitgemäß? Wann war MS Access denn jemals zeitgemäß???
IT-Abteilung schrieb: > Wann war MS Access denn jemals zeitgemäß??? Immer? Man kann ja von unseren Freunden aus Redmond halten, was man will, aber für eine kleine Datenbank im Einzelplatzbetrieb ohne irgendwelche Anforderungen an die Skalierbarkeit, von Laien oder zumindest Anwendern ohne großartige Vorkenntnisse verwendbar, bei Bedarf über VBA erweiterbar, ... Wo ist das Problem? Abgesehen von einer grundsätzlichen Abneigung gegenüber MS? Access kann das hier beschriebene Problem unzweifelhaft lösen und tut das aktuell sogar schon. Warum sollte man daran etwas ändern?
IT-Abteilung schrieb: >> - Das Datenbankschema ist vorhanden; der bisherige Umfang ließe sich >> auch grundsätzlich mit Exceltabellen bewältigen > > Das wäre der Wechsel von einer Katastrophe zum SuperGAU. Ich würde es eher so ausdrücken: Es wäre eine absolut sinnlose Verschlechterung der Situation. Access war ja wenigstens als DB (mit Frontend) gedacht, Excel aber niemals. > V.M. schrieb: [Webscheiß] > Das ist die sinnvollste Lösung. Bullshit. Ein Haufen mehr Komplexität für Null mehr Nutzen, statt dessen höhere Antwortzeiten und weniger komfortable Bedienung (letzteres nur vielleicht, hängt davon ab, wie gut oder schlecht die ursprüngliche Access-Anwendung programmiert war). > Wann war MS Access denn jemals zeitgemäß??? Immer, selbst heute noch. Kommt darauf an, was man damit macht. Ist sicher nicht gut für global verteilte Datenbanken mit Millionen von Nutzern auf der ganzen Welt und Datenbeständen im Exabyte-Bereich. Aber für die vom TO beschriebene Anwendung reicht es ganz sicher völlig aus. Genau das ist der Punkt: ich erkenne keinerlei Notwendigkeit für einen Wechsel IRGENDWOHIN. Wozu? Was genau soll das bringen?
Vermutlich gibt es in der Fachabteilung aktuell mindestens einen Doofen, der zu Hause seine Schnuersenkel nach Farbe in einer Exceltabelle verwaltet und mit Datenbanken nichts anzufangen weiss. Sonst wuerde so ein Thema niemals hochkochen. Sehr schoen in der Praxis zu sehen, was fuer "Workflows" von sogenannten Informatikern zusammengezimmert werden. In Anwendung "A" ausdrucken und in Anwendung "B" dann wieder eintippen.
Die groessten Gegner werden jene sein, die befuerchten ihre Homeuserlizenzen fuer Office zu verlieren. Schon Libre Office Base naeher angesehen?
1. Was bedeutet für dich denn zeitgemäss genau? 2. Welche Features fehlen? 3. Wie komplex sind die Daten? Anzahl Felder,Tabellen? 4. Wie viel Erfassungsformulare gibt es? 5. Welche Auswertungen werden gemacht? Du scheinst eine Web Lösung anzustreben, rutscht dann aber wieder teilweise in die Desktop Richtung - hat das mit den Anforderungen zu tun oder kennst du dich eben mit Web Sachen ein bisschen mehr aus?
cppbert3 schrieb: > Du scheinst eine Web Lösung anzustreben, rutscht dann aber wieder > teilweise in die Desktop Richtung Ich habe eine Firmensoftware mehr als 2 Jahrzehnte lang entwickelt und eingesetzt, bestehend aus Windows-Programmen, aber das würde ich Stand heute nicht mehr tun - eine browserbasierte Lösung hat den Vorteil auf fast jedem Client lauffähig zu sein, auch unter Linux oder auf einem Tablet, man muss sich nicht mehr mit immer neuen Windows-Updates herumschlagen. Ich glaube auch nicht, dass das mehr Arbeit ist als Desktopprogramme, qualifiziert muss man so oder so sein um die Software zu pflegen. Das Rollout einer neuen Version ist natürlich einfacher, wenn sich nur auf dem Server was ändert. Zeitweise hatte ich auch einen Terminalserver und Thin Clients im Einsatz, das ist ja auch eine serverbasierte lösung, aber aus verschiedenen Gründen aus der Mode gekommen. Ich hatte DBase und Nachfolger verwendet, aber heute kommt eigentlich nur noch SQL in Frage. MS Access war für eine Einkaufssoftware ebenfalls im Einsatz, aber da mussten wir mit regelmässigen Abstürzen mit Datenvernichtung leben, weil Access in der Praxis nicht mehrbenutzerfähig ist. Es wurde immer nachts ein Backup erstellt, aber wenn mal wieder kein Zugriff mehr möglich war war eben die Arbeit eines Tages umsonst (nicht kostenlos!). Georg
V.M. schrieb: > Know-How umfasst MS Office, insb. > Excel Man kann auch Exel/Calc mit z.B. postgresql verbinden (frag die Leute die das später benutzen müssen was wollen..)
V.M. schrieb: > Voraussetzungen sind aber da, sich auch in andere Techniken etc. > einzuarbeiten Sieh Dir doch mal APEX an https://apex.oracle.com/en/ Ist eine RAD Umgebung und wenn Oracle Express als DB verwendet wird kostenlos. Nachteil : funktioniert nur mit Oracle DB Gruß Uwe
Zusammenfassung: 15 Jahre lang haben Laien etwas gebastelt, das jetzt nicht mehr wartbar und tragbar ist und den Anschluss an die Gegenwart verloren hat. Nun sollen wieder Laien etwas neues bauen, irgendwie was modernes mit "Web", wovon keiner der Laien so richtig Ahnung hat, und das soll dann besser werden. Finde den Fehler.
V.M. schrieb: > - da nur Fachanwender und überschaubarer Funktionsumfang: Keine > aufwendige GUI Auch Fachanwender haben Anspruch auf eine intuitive Bedienung, Buttons, Listboxen, Menüs usw. gehören heute einfach dazu. Wenn du deine Anwender zu einer Bedienung per Kommandozeile mit kryptischen Parametern zwingst senkst du nur die Produktivität massiv ab. Gefallen würde das nur fanatischen Linuxanhängern. Georg
Experte schrieb: > 15 Jahre lang haben Laien etwas gebastelt, das jetzt nicht mehr wartbar > und tragbar ist und den Anschluss an die Gegenwart verloren hat. Ist das wirklich so? Genau das würde ich bezweifeln. Es mag sein, dass in dem Affenstall niemand mehr hinreichende Kompetenzen besitzt, um den gewachsenen Code zu begreifen. Wenn aber dieser Code aber funktioniert, beweist das nur eins: der derzeitige Personalbestand ist vollkommen überbezahlt. Denn: Wenn ein Programm tut, was es soll, sollte jeder Programmierer in der Lage sein, herauszubekommen, warum das so ist und wie genau das geschieht.
Engagement in der Fachabteilung in Ehren, aber die haben ja bestimmt andere Sachen zu tun, beispielsweise Controllingzeug wofür sie bezahlt werden. Wenn's eine ordentliche Lösung werden soll, dann würde ich es extern vergeben. Falls es auch eine Murxlösung tut, so scheint es mir zu sein, dann würde ich das bestehende Access etwas aufhübschen.
So eine webbasierte Loesung kann sich aber keiner so eben aus dem Aermel schuetteln. Ich kenne eine, die setzt auf dem MS SQL Server auf, und benutzt eine skalierbare Anzahl von Application Servern die die Arbeit machen. Fuer sowas braucht man eine erkleckliche Anzahl von Codierschweinchen, die einem so etwas zusammenzimmern. Und, so etwas wie eigentlich auch nie fertig, weil sich auch die Anforderungen an die Applikation aendern. Diese Software wird von ca. 500 Clients aus parallel genutzt. Da kann man sich auch die geforderte Leistungsfaehigkeit in etwa zusammenreimen... Die Antwortzeiten liegen im Bereich von 200 ms bis 1000 ms mit einem Maximum bei 300 ms. Sucht euch einen oder mehrere Freilandser und lasst den/die euren Kram in kleinen Schritten auf einen Neuentwurf portieren. Und der sollte wohl zweckmaessigerweise wieder Access verwenden. Und schnell wird das auch nichts. Also eher > 3 Monate. Das aber auch nur, wenn ein konsistentes und nicht staendigen Aenderungen unterworfenes Pflichten/Lastenheft existiert. Viel Erfolg!
1.Von einer funktionierenden DB zurück zu Excel kann nur ein Amateur raten. 2.Man sollte eher mal genauer nachdenken, was man wirklich braucht. Falls ein außenstehender Programmierer ans Werk gehen soll, müßte er recht genau wissen, wie die Abläufe in der Firma sind! Sonst baut er ein optisch schönes Tool was keiner gebrauchen kann!
Heiner schrieb: > IT-Abteilung schrieb: >> Wann war MS Access denn jemals zeitgemäß??? > > Immer? Man kann ja von unseren Freunden aus Redmond halten, was man > will, aber für eine kleine Datenbank im Einzelplatzbetrieb Mööt! Wenn ich den TO richtig verstanden habe, geht es gerade nicht um einen Einzelplatzbetrieb.
V.M. schrieb: > Die Lösung wurde vor >15 Jahren mal mit der damaligen ACCESS-Version > erstellt, ist mittlerweile durch viele Versionen und eben so viele Hände > bzgl. Betreuung gegangen und einfach nicht mehr zeitgemäß. Jetzt wird > eine Ersatzlösung gesucht; dabei ist zunächst sowohl eine anpassbare > fertige Lösung möglich wie auch die Selbsterstellung - und für beides > hätte ich gerne Tipps. Nun, Du schreibst zwar, daß keine parallelen Zugriffe notwendig seien, aber wenn ich das richtig verstehe, wird die Software doch von mehreren Menschen genutzt. Deswegen würde ich in solchen Fällen immer von der Verwendung einer dateibasierten Datenbank abraten und zu einer zentralisierten Lösung raten. Abgesehen davon, daß diese auch von mehreren Usern gleichzeitig genutzt werden kann -- was womöglich spätestens bei einem Wachstum der Abteilung und / oder der Umverteilung von Aufgaben notwendig werden kann -- bietet eine zentralisierte Lösung auch noch erhebliche Vorteile bei Themen wie dem Backup, der Wartung und der Pflege. Außerdem bietet eine zentralisierte Lösung in Deinem Fall noch einen weiteren großen Vorteil, nämlich den einer schrittweisen Migration. Aus eigener Erfahrung weiß ich, daß in selbstentwickelten Office-Lösungen häufig jeder Kollege seins macht und sich die Dinge, die er braucht, selbst einbaut. Diese ganzen verschiedenen Lösungen und Lösungswegen einzusammeln und in einer zentralisierten Software zu implementieren, ist nach meinen Erfahrungen eine ziemlich aufwändige Angelegenheit und führt gerne auch mal zu Konflikten. Konflikte unter den Kollegen sind aber das letzte, was man haben möchte, denn einerseits erschweren sie die Einführung neuer Software bis hin zu Kollegen, die die Mit- und Zusammenarbeit verweigern, andererseits bleiben diese Konflikte am Ende immer an dem hängen, der die neue Lösung entwickelt. Ich ganz persönlich würde daher ein schrittweises Vorgehen vorschlagen: im ersten Schritt wird ein zentrales SQL-RDBMS installiert und in Betrieb genommen, also zum Beispiel auch das Backup und idealerweise zudem ein Monitoring eingerichtet. Dann werden die Bestandsdaten und -Schemata auf dieses zentrale RDBMS migriert und den Kollegen ein Zugriff über ODBC ermöglicht; so können die Kollegen weiterhin mit der gewohnten Software (hier: MS-Office) arbeiten, aber eben auf einer zentralen DB. Danach kann man immer noch entscheiden, ob man eine ebenfalls zentralisierte Web-Anwendung bauen möchte. Da die Kollegen aber weiterhin arbeitsfähig sind, kann man sich sowohl mit der Entscheidung, als auch -- bei positiver Entscheidung -- einer Implementierung Zeit lassen und die Kollegen an einer eventuellen Implementierung aktiv beteiligen. Das erhöht die Akzeptanz der Anwender, sie werden sich dadurch ernst genommen fühlen und wesentlich engagierter einbringen. Der grundsätzliche Nachteil einer webbasierten Software ist, daß sie sich nicht so leicht in einen existierenden Workflow auf Basis von MS-Office integrieren läßt. Man kann aber mal einen Prototypen bauen, ihn den Kollegen vorstellen, und sie dann an einer Entscheidung beteiligen. Ja, man kann MS-Dateiformate zum Beispiel auch mit Python erzeugen, oder den Datentransfer von Web zu Office zum Beispiel über CSV-Dateien machen, aber ob und wie gut das funktioniert, hängt von den konkreten Anwendungsfällen ab. Was die zur Entwicklung einer webbasierten Software genutzten Technologien angeht, würde ich aktuell von Java abraten -- einerseits wegen der immer noch ungeklärten Lizenzsituation, andererseits sind Entwicklung und Betrieb von Webapplikationen in Java vergleichsweise aufwändig und möglicherweise nicht zukunftssicher. Heute gibt es beispielsweise keinen freien Web Application Server, der die aktuellen Standards unterstützt, und die kommerziellen Web Application Server wie IBM Websphere oder Redhat JBoss kosten einerseits Geld und neigen andererseits leider auch dazu, die aktuellen Standards... sagen wir, etwas unterschiedlich zu interpretieren. Freie Web Application Server wie Wildfly hingegen (auf dem JBoss basiert) neigen leider oft zu Instabilitäten durch Memory Leaks und Race Conditions, oder unterstützten die heute aktuellen Standards (noch) nicht vollständig, wie der beliebte Apache Tomcat. Meine ganz persönliche Empfehlung wäre daher, die Programmiersprache Python und das Micro-Webframework Flask zu verwenden. Die Entwicklung in einer nicht-typsicheren Sprache, die einen großen Teil der meistverwendeten Bibliotheken bereits an Bord hat, spart massiv Entwicklungszeit. Durch Bibliotheken wie Pandas zur Analyse und Bokeh zur Visualisierung, Weazyprint zur Erzeugung von PDFs und weitere Libraries läßt sich nahezu beliebiger Funktionsumfang integrieren, ohne ihn selbst entwickeln zu müssen, was wiederum Zeit spart. Und im Zweifelsfalle kann man mit Flask-Admin sogar automatisch Anzeigen und CRUD-Formulare aus seinem Datenbankmodell erzeugen, sofern man dieses mit dem OR-Mapper SQLAlchemy erzeugt hat... Gleichzeitig ist Python jedoch so einfach, daß interessierte Kollegen gleich bei der Einarbeitung und der Implementierung mitarbeiten können (Tipp: von vorneherein mit einem zentral installierten Versionskontrollsystem wie Git arbeiten!). Als SQL-RDBMS würde ich persönlich übrigens PostgreSQL empfehlen. Das ist stabil, performant und flexibel, bietet von allen mir bekannten RDBMS die umfangreichste Funktionalität (bis hin zur Möglichkeit eigener Erweiterungen und Datentypen), im Zweifelsfall ist es sogar möglich, Stored Procedures in Python zu schreiben... HTH, YMMV. ;-)
V.M. schrieb: > vor >15 Jahren mal Das übliche Problem. Vor Jahren mit einem kleinen irgendwas.xls angefangen und weil es "so schön ging", arbeitet jetzt die ganze Firma damit? Den Wildwuchs wieder einzufangen und in eine akzeptable DB-Lösung zu überführen macht Aufwand. Je exotischer die Lösung wird, desto abhängiger wird man von einzelnen SW-Entwicklern. Mit "mal schnell" wird wohl nix. Schau Dir erst mal ein paar ähnliche Referenzlösungen Deiner Entwickler an.
Vielen Dank für die zahlreichen Statements - das hilft mir sehr; gleichzeitig muss ich das für mich jetzt ein wenig sortieren. Wer noch weitere Ideen dazu hat, gerne her damit! Idealerweise hat jemand eine sehr ähnliche Situation gehabt und das dann gelöst und mag sich mal detailliert austauschen - welche Lösungsansätze haben im Nachhinein gut funktioniert, und welche waren dann doch Sackgassen?
V.M. schrieb: > Vielen Dank für die zahlreichen Statements - das hilft mir sehr; > gleichzeitig muss ich das für mich jetzt ein wenig sortieren. Wer noch > weitere Ideen dazu hat, gerne her damit! bisschen schwierig wenn du keine Fragen beantwortest - also nochmal und bitte so genau wie möglich 1. Was bedeutet für dich denn zeitgemäss genau? 2. Welche Features fehlen? 3. Wie komplex sind die Daten? (Anzahl Felder,Tabellen) 4. Wie viel Erfassungsformulare gibt es? 5. Welche Auswertungen werden gemacht? 6. Wie viele Nutzer - nicht zeitgleich - gibt es? > Idealerweise hat jemand eine sehr ähnliche Situation gehabt und das dann > gelöst und mag sich mal detailliert austauschen - welche Lösungsansätze > haben im Nachhinein gut funktioniert, und welche waren dann doch > Sackgassen? Wenn es wenige Tabellen sind und nur ein paar Eingabefehler, wenig Datenverbindungen, kleine Hierarchien und man Ahnung hat kann das wenige Stunden dauern - egal mit welcher Technologie - wenn man keine Ahnung hat (oder jemand ahnungslosen findet der es macht) ist es schwer abzuschätzen wie lange ihr braucht
cppbert schrieb: > und welche waren dann doch >> Sackgassen? Glaubst du jemand erzählt hier voller Stolz wie er gescheitert ist? Ausserdem ist das nicht so einfach zu definieren, in der Praxis funktioniert selbst das ungeeignetste Konzept, von unfähigen Programmierern realisiert und völlig undokumentiert immer noch gut genug, dass es 20 Jahre lang eingesetzt wird. Es ist dabei erstaunlich mit welcher Fantasie und Improvisationsgabe die Leute auch mit totalem Schrott noch zurechtkommen. Man gewöhnt sich halt dran. Georg
Schau dir mal Claris Filemaker Pro an.
Die Demo ist 14 Tage ohne Einschränkungen lauffähig. Läuft auf Windows,
MacOSX und iOS-Geräten. Die Linux-Version ist im Beta-Stadium.
Filemaker-Lösungen kann man lokal oder im Netzwerk betreiben. Der
Netzwerkzugriff ist per Client (lokale FM-Installation) und per
Webbrowser möglich. Die "Player"-Software für Mobilgeräte
("Filemaker-Go") ist kostenlos ... Eine Nutzung unter Anrdoid ist mit
Fremdsoftware möglich: https://filemaker.livecode.com/
Typische Arbeitsweise: Die Software wird in der IDE einer lokalen
Installation entwickelt (egal ob Mac oder Win) und dann auf den
FM-Server hochgeladen. Aber auch dort kann man jederzeit (entsprechede
Rechte vorausgesetzt) an GUI und DB-Struktur arbeiten. Anstatt VBA gibt
es eine eigene Skriptsprache, deren Funktionsumfang durch eigene
Funktionen oder Plugins erweitert werden kann.
An einen Filemaker-Server kann man mit externen Programmen per ODBC/SQL
"andocken", Filemaker kann z.B. Excel-Tabellen und CSV im- und
exportieren ... u.v.a.
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.