Base gegen Access austauschen?

de-users
#11

Hallo Wolfgang,

Bevor ich lange mit den mdbtools testen würde hätte ich eher jemand
mit Access gefragt, der mir alle Tabellen schlicht in eine
Tabellenkalkulationsdatei gezogen hätte, aus der heraus ich mir dann
die Tabellen in Base neu gebildet hätte.

Ein SQL-Dump, den man im Texteditor per "Suchen und Ersetzen"
kompatibel mit einem vernünftigen Client-Server RDBMS (wie z.B.
PostgreSQL) machen kann ist da noch viel einfacher.

Nur geht das für den Nutzer, von dem Nino geschrieben hat, vermutlich am
Thema vorbei. Die meisten, die neu in LO-Base einsteigen wollen meinen
zuerst einmal die Lösung mit der internen HSQLDB. Da wird nicht an
irgendwelche Serverkonstruktionen gedacht.

Gruß

Robert

#12

Hallo Franklin,

Auch an der Stelle noch mal meine Frage von gestern wiederholt:
Laufen unter Firebird die alten LibO-HSQLDB-Datenbanken dann aber
ebenso unverändert weiter?

Vielleicht hast Du nicht alle Beiträge des Threads gelesen.

Zum einen ist noch gar nicht ausdiskutiert, welche Datenbank die in die
Tage gekommene HSQLDB ersetzen soll (die Diskussion dauert schon Jahre -
sie ist älter als LO selbst). Zum anderen muss natürlich für Nutzer der
alten Datenbank weiterhin eine Verbindung zur HSQLDB vorgehalten werden.
Schließlich gibt es Leute, die weiterhin zwischen verschiedenen
Officeversionen einen Austausch herbeiführen wollen. Da wird wohl,
ähnlich wie bei verschiedenen Dateiformaten von OpenOffice/LibreOffice
eine ganze Zeit lang mit zwei internen DBs gearbeitet werden.

Gruß

Robert

#13

Hallo Robert,

Hallo Franklin,

Auch an der Stelle noch mal meine Frage von gestern wiederholt:
Laufen unter Firebird die alten LibO-HSQLDB-Datenbanken dann aber
ebenso unverändert weiter?

Vielleicht hast Du nicht alle Beiträge des Threads gelesen.

Zum einen ist noch gar nicht ausdiskutiert, welche Datenbank die in die
Tage gekommene HSQLDB ersetzen soll (die Diskussion dauert schon Jahre -
sie ist älter als LO selbst). Zum anderen muss natürlich für Nutzer der
alten Datenbank weiterhin eine Verbindung zur HSQLDB vorgehalten werden.
Schließlich gibt es Leute, die weiterhin zwischen verschiedenen
Officeversionen einen Austausch herbeiführen wollen. Da wird wohl,
ähnlich wie bei verschiedenen Dateiformaten von OpenOffice/LibreOffice
eine ganze Zeit lang mit zwei internen DBs gearbeitet werden.

Ach so ... danke!

Robert

.... und tschüss

            Franklin

#14

>> Ist Firebird eine Datenbank?
>
> Die Transaktionssicherheit von Firebird ist jedenfalls weitaus
> vertrauenerweckender als die von MySQL.

Auch an der Stelle noch mal meine Frage von gestern wiederholt:
Laufen unter Firebird die alten LibO-HSQLDB-Datenbanken dann aber
ebenso unverändert weiter?

Nein.

Die Daten extrahiert man per SQL Dump und lädt sie in
Firebird/PostgreSQL neu. Die Formulare, Berichte, kann man
weiterverwenden.

PostgreSQL funktioniert schon heute "nativ" (SDBC-Treiber) mit LO Base.

"Eingebettete" Datenbanken halte ich im Bürobereich generell für
Quatsch, da sie das Grundprinzip der Wiederverwendung ad absurdum
führen. Wiederverwendung von Daten ist aber nunmal *die* "Raison d'être"
von Datenbanken.

MfG,

Wolfgang

#15

>> Bevor ich lange mit den mdbtools testen würde hätte ich eher jemand
>> mit Access gefragt, der mir alle Tabellen schlicht in eine
>> Tabellenkalkulationsdatei gezogen hätte, aus der heraus ich mir
>> dann die Tabellen in Base neu gebildet hätte.
>
> Ein SQL-Dump, den man im Texteditor per "Suchen und Ersetzen"
> kompatibel mit einem vernünftigen Client-Server RDBMS (wie z.B.
> PostgreSQL) machen kann ist da noch viel einfacher.

Nur geht das für den Nutzer, von dem Nino geschrieben hat, vermutlich
am Thema vorbei. Die meisten, die neu in LO-Base einsteigen wollen
meinen zuerst einmal die Lösung mit der internen HSQLDB. Da wird
nicht an irgendwelche Serverkonstruktionen gedacht.

Das ganze Konzept von Datenbanken, die inklusive dem
Datenbank-Managementsystem und den Formularen, Berichten etc. in ein
einziges "Dokument" "eingebettet" sind ist imho einfach Unfug.

Das ist genau das Problem sowohl mit Access als auch mit LO Base; daß
es Benutzer, die noch keine Ahnung haben, in völlig falsche Bahnen
lenkt. Anstatt von vorneherein einen Ansatz zu verfolgen, der
zweckmäßig ist.

MfG,

Wolfgang

#16

Hallo Wolfgang,

Das ganze Konzept von Datenbanken, die inklusive dem
Datenbank-Managementsystem und den Formularen, Berichten etc. in ein
einziges "Dokument" "eingebettet" sind ist imho einfach Unfug.

Das ist genau das Problem sowohl mit Access als auch mit LO Base; daß
es Benutzer, die noch keine Ahnung haben, in völlig falsche Bahnen
lenkt. Anstatt von vorneherein einen Ansatz zu verfolgen, der
zweckmäßig ist.

Mag Deine Erfahrung mit Base sein. Ich kenne viele, die Base in dem
Zustand, wie es jetzt ist, mit der internen Datenbank erfolgreich
nutzen. Was für den einen Unfug ist, ist für den anderen eben genau das,
was passend ist.

Gruß

Robert

#17

Hallo Wolfgang,
>
> Das ganze Konzept von Datenbanken, die inklusive dem
> Datenbank-Managementsystem und den Formularen, Berichten etc. in ein
> einziges "Dokument" "eingebettet" sind ist imho einfach Unfug.

^^^^^^^^^^^^^^^^^^^^^^und wie das Ganze "technisch" gelöst, insbesondere
gespeichert ist, ändert m.E. am Konzept zunächst einmal nichts.

>
> Das ist genau das Problem sowohl mit Access als auch mit LO Base; daß
> es Benutzer, die noch keine Ahnung haben, in völlig falsche Bahnen
> lenkt. Anstatt von vorneherein einen Ansatz zu verfolgen, der
> zweckmäßig ist.
>
Mag Deine Erfahrung mit Base sein. Ich kenne viele, die Base in dem
Zustand, wie es jetzt ist, mit der internen Datenbank erfolgreich
nutzen. Was für den einen Unfug ist, ist für den anderen eben genau das,
was passend ist.

Solange es um 1-Benutzer-Betrieb geht, sehe ich da auch keinerlei
Probleme.

#18

Wieso führen ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^?
Versteh' ich nich' ?:expressionless:

#19

Ich kenne viele, die Base in dem Zustand, wie es jetzt ist, mit der
internen Datenbank erfolgreich nutzen. Was für den einen Unfug ist,
ist für den anderen eben genau das, was passend ist.

Das Grundprinzip der Wiederverwendung von Daten muß man halt erst
einmal kapiert haben, bevor man überhaupt wissen kann, wofür EDV gut
sein kann. Die üblichen Datenmüllhalden auf Büro-PCs und -Servern
sprechen da recht deutlich für sich bzw. gegen die EDV-Kompetenz des
typischen Nutzers. Und gegen die des typischen IT-Managers bzw.
Windows-"Admins" übrigens auch.

MfG,

Wolfgang

#20

> "Eingebettete" Datenbanken halte ich im Bürobereich generell für
> Quatsch, da sie das Grundprinzip der Wiederverwendung ad absurdum
Wieso führen ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^?
Versteh' ich nich' ?:expressionless:

Daten, die in *ein* Dokument "eingebettet", sind, lassen sich nur
umständlich an anderer Stelle wiederverwenden. Und wenn man dann nach
hundert mal exportieren per SQL-Dump und neu laden die letztendlich
gleichen Daten an hundert verschiedenen Stellen "eingebettet" hat,
werden sie zwangsläufig inkonsistent, d.h. zu Datenmüll. Deshalb hält
man Daten immer an einem einzigen Ort zentral.

*Das* Grundprinzip jeglicher Datenbankarbeit lautet demzufolge:

"Es kann immer nur *eine* Wahrheit geben".

MfG,

Wolfgang

#21

Hallo,

da gebe ich Dir vollkommend Recht.

Das Grundprinzip der Wiederverwendung von Daten muß man halt erst einmal kapiert haben, bevor man überhaupt wissen kann, wofür EDV gut sein kann. Die üblichen Datenmüllhalden auf Büro-PCs und -Servern sprechen da recht deutlich für sich bzw. gegen die EDV-Kompetenz des typischen Nutzers. Und gegen die des typischen IT-Managers bzw. Windows-"Admins" übrigens auch. MfG, Wolfgang

Gruß Christian

#22

Hallo Wolfgang,

wenn Du mit dem Prinzip einer eingebetteten Datenbank nichts zu tun
haben willst, dann lass es doch. Nutze Base eben einfach anders, z.B.
mit externen Datenbanken. Oder nutze Base gar nicht. Aber versuche bitte
nicht, eines der wesentlichen Programmmodule auch noch allen anderen
Leuten madig zu machen. Jeder von uns weiß, dass eine eingebettete
Datenbank keine Multiuserdatenbank ist. Ich nutze Base mit der
eingebetteten Datenbank jedenfalls weiter - beruflich, privat und
ehrenamtlich zur Vereinsverwaltung.

Bleib Du bei Deiner einen Wahrheit; ich nehme so etwas für mich nicht in
Anspruch. Ich benutze das Werkzeug, das ich für mich als sinnvoll erachte.

Gruß

Robert

#23

Hallo Wolfgang,

> Ich kenne viele, die Base in dem Zustand, wie es jetzt ist, mit der
> internen Datenbank erfolgreich nutzen. Was für den einen Unfug ist,
> ist für den anderen eben genau das, was passend ist.

Das Grundprinzip der Wiederverwendung von Daten muß man halt erst
einmal kapiert haben, bevor man überhaupt wissen kann, wofür EDV gut
sein kann.

Das kommt aber stark darauf an, wofür der entsprechende User seinen
Datenbestand braucht! Wenn jemand nur eine kleine Datenbank für
gelegentliche Serienbriefe braucht, oder er/sie damit eine Sammlung von
100-200 Büchern verwalten möchte, dann ist die interne Datenbank völlig
ausreichend! Wenn dann irgendwann mehrere Benutzer die daten verwenden
sollen, kann man immer noch auf eine Multiuser-DB-System umsteigen.

Zur Verwaltung von 50 Adressen für eine Einzelperson, halte ich MySQL
oder Datenbanken ähnlichen Kalibers für völlig überzogen.

Die üblichen Datenmüllhalden auf Büro-PCs und -Servern
sprechen da recht deutlich für sich bzw. gegen die EDV-Kompetenz des
typischen Nutzers. Und gegen die des typischen IT-Managers bzw.
Windows-"Admins" übrigens auch.

ich gebe dir Recht, wenn es darum geht, sauber formatierte Tabellen zu
erstellen, und die Leute das dann mit einer Tabellenkalkulation lösen,
obwohl keine einzige Berechnung ausgeführt wird. oder wenn
Tabellenkalkulationen statt Datenbanken verwendet werden, obwohl die
Anzahl der Datensätze bereits die Tausender-Grenze überschritten hat.

Aber die Verwendung einer Datenbank zu kritisieren, nur weil es nicht
die Schwerlast-Version ist, halte ich für überzogen! ich kaufe mir ja
auch keinen Lastwagen, weil ich einmal im Monat eine Getränkekiste
transportieren muss.

Wichtig ist doch nur, dass ich meine Daten aus der Software wieder
herausbekomme, wenn ich denn tatsächlich in die nächste Liga wechseln
möchte.

Gruß,
Michael

#24

Aber versuche bitte nicht, eines der wesentlichen Programmmodule auch
noch allen anderen Leuten madig zu machen.

Das mache ich ja auch gar nicht. Nur man sollte halt schon genau lesen,
was ich schreibe und was nicht. Anstatt einfach irgend etwas zu
unterstellen.

Es geht ausschließlich um die richtige Benutzung von Base. Und natürlich
müßten die LO/OO Entwickler mal mittelfristig darauf kommen, daß sie mit
"eingebetteten" Datenbanken letztendlich ihrem eigenen Projekt in den
Fuß schießen, wenn z.B. Benutzer durch Anwendungsfehler ihre Daten
verlieren und danach auf LO/OO verzichten.

Ich habe übrigens in der Vergangenheit hier bereits mehrfach darauf
hingewiesen, daß ich Base (natürlich nur im Zusammenhang mit einem
anständigen Client/Server-RDBMS wie eben PostgreSQL) für DIE
"Killer"-Anwendung in LO/OO halte. Denn Writer ist für ernsthafte
Schreibarbeit mangels typographischer Fähigkeiten nicht zu gebrauchen,
Calc ist wie so ziemlich jede Tabellenkalkulation (mit Ausnahme des
nicht mehr existenten Lotus Improv vielleicht) nur mit einer Datenbank
als "Speicherebene" zu gebrauchen und Impress ist auch nichts
wirkliches im Vergleich zu LyX/LaTeX mit Beamer und Impressive. Draw
habe ich noch nicth ausprobiert. Es müßte schon an Omnigraffle resp.
Inkscape herankommen, um brauchbar zu sein. Wobei das eigentlich zwei
weitesgehend unterschiedliche Anwendungsbereiche sind.

Übrigens ist Base eine Anwendung, für die MS mit Access nichts
Vergleichbares zu bieten hat, da die dort "eingebettete" Datenbank
horrend unzuverlässig ist und andere Client/Server-RDBMS als MS SQL
Server nicht vernünftig unterstützt werden. Und MS SQL Server läuft zum
einen nicht auf etwas anderem als auf MS (Keine Rückmeldung) und kostet
andererseits für echte Anwendungen Geld, von diversen weiteren
haarsträubenden "Features" ganz abgesehen.

Vom Support echter Skriptsprachen (notwendige Voraussetzung für eine
echte Skriptsprache: ein interaktiver Kommandozeilen-Interpreter) den
LO/OO bietet mal ganz zu schweigen, der ebenso wie Base selbst eines
der bestgehüteten Geheimnisse von LO/OO ist. Weshalb ich eben nicht
verstehe, warum die LO/OO-Entwickler so lange gebraucht haben, ein
Base-Handbuch herauszubringen und warum nach wie vor kein Handbuch für
PyUno vorliegt.

Mit PyUno, das ganz nebenbei die Nutzung der immensen Modulbibliotheken
für Python erlaubt, und Calc und Writer quasi als "Reporting"-Framework
zusammen könnte LO/OO Base dank der "nativen" Unterstützung für
PostgreSQL eben zu einer "Killer"-Anwendung im Unternehmensumfeld
werden.

Wenn es mal jemand an maßgeblicher Stelle des Projektes kapieren
würde, was der Begriff "Competitive Advantage" bedeutet
(Managementsprech kann manchmal nützlich sein).

Von Unternehmen z.B. im Finanzbereich wäre sicherlich auch einiges an
Mitteln für entsprechende Entwicklungs- und/oder Dokumentationsprojekte
zu holen. Nicht umsonst existiert z.B. Applixware (historisch das erste
"Office"-Paket für Unix-Systeme) praktisch ausschließlich nur noch
aufgrund eben dieses Marktes (und seiner Skriptfähigkeiten, die aber
kein Vergleich zu Python sind).

MfG,

Wolfgang

#25

Zur Verwaltung von 50 Adressen für eine Einzelperson, halte ich MySQL
oder Datenbanken ähnlichen Kalibers für völlig überzogen.

MySQL benutzt man für *gar nichts*, wenn man auf seine Daten Wert legt.

Und PostgreSQL is in der default-Konfiguration auf allem lauffähig, was
ich je ausprobiert habe. Zweifellos auf Hardware, auf der LO4 definitiv
nicht benutzbar ist.

Wichtig ist doch nur, dass ich meine Daten aus der Software wieder
herausbekomme, wenn ich denn tatsächlich in die nächste Liga wechseln
möchte.

Eben. Deshalb extern halten (damit die Daten vor Korruption durch
Anwendungsfehler geschützt sind), und zwar in einer
*transaktionssicheren* und *zuverlässigen* Datenbank.

MfG,

Wolfgang

#26

Hallo Wolfgang,

Aber versuche bitte nicht, eines der wesentlichen Programmmodule auch
noch allen anderen Leuten madig zu machen.

Das mache ich ja auch gar nicht...

Es geht ausschließlich um die richtige Benutzung von Base.

ACK

Und natürlich
müßten die LO/OO Entwickler mal mittelfristig darauf kommen, daß sie mit
"eingebetteten" Datenbanken letztendlich ihrem eigenen Projekt in den
Fuß schießen, wenn z.B. Benutzer durch Anwendungsfehler ihre Daten
verlieren und danach auf LO/OO verzichten.

und hier machst du LO dann doch wieder madig!

Denn Writer ist für ernsthafte
Schreibarbeit mangels typographischer Fähigkeiten nicht zu gebrauchen,
Calc ist wie so ziemlich jede Tabellenkalkulation (mit Ausnahme des
nicht mehr existenten Lotus Improv vielleicht) nur mit einer Datenbank
als "Speicherebene" zu gebrauchen und Impress ist auch nichts
wirkliches im Vergleich zu LyX/LaTeX mit Beamer und Impressive. Draw
habe ich noch nicth ausprobiert. Es müßte schon an Omnigraffle resp.
Inkscape herankommen, um brauchbar zu sein. Wobei das eigentlich zwei
weitesgehend unterschiedliche Anwendungsbereiche sind.

... entschuldige, aber wer zwingt irgend jemanden einen solchen unbenutzbaren Mist - wie du ja oben ausführst - einzusetzen? Niemand!
Ich versteh dich nicht. Alles an LO taugt in deinen Augen nicht und hat bessere Alternativen. Dann benütze doch die Alternativen.

Übrigens ist Base eine Anwendung, für die MS mit Access nichts
Vergleichbares zu bieten hat, da die dort "eingebettete" Datenbank
horrend unzuverlässig ist und andere Client/Server-RDBMS als MS SQL
Server nicht vernünftig unterstützt werden. Und MS SQL Server läuft zum
einen nicht auf etwas anderem als auf MS (Keine Rückmeldung) und kostet
andererseits für echte Anwendungen Geld, von diversen weiteren
haarsträubenden "Features" ganz abgesehen.

taugt als auch nicht???

Vom Support echter Skriptsprachen (notwendige Voraussetzung für eine
echte Skriptsprache: ein interaktiver Kommandozeilen-Interpreter) den
LO/OO bietet mal ganz zu schweigen, der ebenso wie Base selbst eines
der bestgehüteten Geheimnisse von LO/OO ist. Weshalb ich eben nicht
verstehe, warum die LO/OO-Entwickler so lange gebraucht haben, ein
Base-Handbuch herauszubringen und warum nach wie vor kein Handbuch für
PyUno vorliegt.

Wer bitte sind die LO/OO-Entwickler??? Die Handbücher werden zu einem Großteil von den Anwendern selbst geschrieben oder übersetzt.
Ich bin mir nicht sicher ob du LO überhaupt kennst? Wer LO entwickelt und das Ganze bezahlt wird.

Wenn es mal jemand an maßgeblicher Stelle des Projektes kapieren
würde, was der Begriff "Competitive Advantage" bedeutet
(Managementsprech kann manchmal nützlich sein).

Na wenn du das weisst, warum nicht mitmachen und selbst zu einem "Maßgeblichen" werden.

Von Unternehmen z.B. im Finanzbereich wäre sicherlich auch einiges an
Mitteln für entsprechende Entwicklungs- und/oder Dokumentationsprojekte
zu holen.

Na dann geh doch mal mit dem Hut rum!
Sorry, da muss ich wirklich schmunzeln. Du glaubst wirklich, wenn du mit diesen Features daher kommst, schmeissen die ihr "Running System" weg und steigen auf ein OpenSource-Projekt um?
Träum' weiter ...
Scriptsprachen interessieren Unternehmen und den Finanzbereich doch nur ganz peripher.
Die haben Ihre "Tippsen und Tippser" vor MS-Office sitzen, das hatten die in der Schule und im Beruf. Wenn du denen was anderes als MS Produkte vorsetzt sind die fertig mit der Welt. Das ist die Realität und nix anderes.
Das ist das, was ich in 40 Jahren Berufsleben kennen gelernt habe, Massenträgheit :wink:

#27

und hier machst du LO dann doch wieder madig!

Falsch.

Ich versteh dich nicht. Alles an LO taugt in deinen Augen nicht

Falsch.

Scriptsprachen interessieren Unternehmen und den Finanzbereich doch
nur ganz peripher.

Du hast keine Ahnung, offenkundig.

Wie geschrieben; Applixware existiert überhaupt nur noch deswegen. Wie
zahlreiche andere Anwendungen.

Und Python wird im Finanzbereich allmählich fast so verbreitet wie
in den Naturwissenschaften.

MfG,

Wolfgang

#28

Hallo Wolfgang,

und hier machst du LO dann doch wieder madig!

Falsch.

Nein, genau so kommt es über. Vielleicht meinst Du das nicht so, aber da
ist Edgar wohl sicher nicht der Einzige, der das so wahrnimmt.

Ich versteh dich nicht. Alles an LO taugt in deinen Augen nicht

Falsch.

Auch da erweckst Du bei anderen den Eindruck, den Du eigentlich nicht
erwecken möchtest - wenn ich Dich denn richtig verstehe.

Auch Du bist Teil der Gemeinschaft, die LO nutzt. Auch Du kannst Teil
der Gemeinschaft sein, die LO voran treibt und zu einem Produkt macht,
dass Deinen Anforderungen genügt.

Wir können sicher Leute gebrauchen, die die Sache voran treiben. Deshalb
habe ich mich mit meinem "beschränkten Wissen" hingesetzt und das
Handbuch für Base in großen Teilen selbst verfasst - weil nichts
entsprechendes existierte. Und deswegen fühle ich mich bei solchen Mails
auch etwas angegriffen, weil Du eben den Sinn des ganzen Unterfangens
"interne Datenbank" anzweifelst, ohne selbst etwas anderes in die Wege
zu leiten - denn auch Du bist ein Teil des ganzen Projektes.

Das ist die letzte Mail, die ich dazu in diesem Thread schreiben werde.
Ich helfe lieber anderen, mit Base gut zurecht zu kommen (siehe dazu:
http://de.openoffice.info/viewforum.php?f=8 und
http://www.libreoffice-forum.de/viewforum.php?f=10 ) statt hier das
Hickhack weiter mit zu machen.

Gruß

Robert

#29

Hallo,

ich als langjähriger Benutzer von Datenbanken fand die ganz Diskussion nur Lustig.

Es gibt in meinen Augen nur wenige Kriterien warum ich mich für Intern oder Extern entscheiden muss.

Was will ich in 10 Jahren, wenn sich die Technik weiter entwickelt hat, mit meinen Daten machen.

Die größe der Dateien spielt heute so weit ich weiß keine Rolle mehr.

Externe Datenbank kann ich, sobald sie nach irgend einem Standard abgespeichert ist mit den aktuellen Programmen ohne Probleme weiter bearbeiten, selbst wenn der Hersteller meiner Software nicht mehr existiert.
Ein- oder Mehrbenutzerumgebung ist bei externen Datenbanken oft leichter zu handeln.
Datensicherung wird einfacher, weil ja unabhängig von dem Programm.
Netzwerkauslagerung auch einfacher weil der Client der das Programm hat nur auf die Datenbank zugreifen muß.
Ich kann auf den Client verschiedene Programme haben die die Gleiche Datenbank bearbeiten.
Die Bandbreite die für das Ganze in meinem Netzwerk dafür gebraucht wird, ist kleiner.

Interne Datenbank. Alles ist zueinander angepasst. Einbenutzerumgebung überhaupt kein Thema.
Mehrbenutzer kann aber auch realisiert werden. Ist halt nur Erziehungssache. Wer dran arbeitet macht das Programm auf, arbeitet dran und macht es dann wieder zu. Während dem kann kein anderer sie öffnen ohne Fehlermeldung. Oder er öffnet sich das Ganze nur zum lesen, dann kann ein anderer dran arbeiten.
Die Clients müssen halt etwas größer sein, weil sie sich ja das Programm aus dem Netz laden. An sich heute aber nur ein Thema das Preises für die Clients.
Die erste Administration wird etwas komplizierter weil man sich um die Caches kümmern muß.
Für das erste Mal laden brauche ich eben die Bandbreite im Netzwerk, sonst können alle erst mal Kaffe trinken gehen.

Also kann sich jeder aussuchen was er braucht.

Gruß
Christian

#30

Hallo Wolfgang

Du hast keine Ahnung, offenkundig.

offenkundig!
Denn ich bin ja auch nur die rechte Hand vom Chef in einem mittelständigen Betrieb mit einem Umsatz von 1,5 Mio.
Also eine ganz kleine Nummer nur und kann also nur von ganz da unten aus dem Sumpf quaken!
*Meister ich verneige mich!*