Kleinschrittige Anleitung Base: Welches Beispielprojekt wäre gewünscht?

Ich habe für das Handbuch Base im ersten Kapitel eine einfache Testdatenbank “Beispiel_Sport.odb” beschrieben - in kleinen Schritten von der Tabellenerstellung bis zum Ausdruck in Berichten. Der Sprung anschließend zu den folgenden Kapiteln scheint für viele Nutzer noch zu groß zu sein. Da ich Zeit investieren kann hier die Frage:
Welches Thema würdest Du nehmen? Welche Probleme sollten dabei detailliert in kleinen Schritten erklärt werden?
Als Anregung möchte ich auf die Datenbanken und Beschreibungen auf meiner Homepage verweisen.
Es wird natürlich Themengebiete geben, von denen ich wnig Ahnung habe, aber es soll ja auch nur darum gehen: Welche weitergehende Beschreibung würde die Lernkurve vom ersten Beispiel im Handbuch zu den folgenden Kapiteln vielleicht verringern. Die fachliche Überprüfung zum Themengebiet könnten wir dann anderweitig in Angriff nehmen.

Gruß

Robert

Je kleiner die Anleitungsschritte desto mehr ähnelt es der Methode “Malen nach Zahlen”.

Der Unterschied besteht aber darin, dass für die Lage von Punkt 2 gegenüber Punkt 1 eine Begründung geliefert wird. Das könnte dazu führen, dass anschließend die Zahlen selbst aufs Blatt geschrieben werden und verbunden werden. Und daraus können dann wieder Kunstwerke entstehen.

1 Like

Es ist halt wirklich schwierig. Jeder Jeck ist anders, und ich glaube mittlerweile, dass die Mehrheit der Menschen nicht zum Ingenieur geboren ist. Die Übertragung eines zu lösenden Alltagsproblems in ein relationales Datenmodell ist eine mentale Ingenieursleistung. Der Abstraktions-Muskel ist trainierbar, aber wir haben es heute mit einer völlig anderen IT-Kultur zu tun als noch in den 90igern als Millionen von PC-Käufern auch echte Papierbücher über MS Office beim Aldi kauften. Mein Einstieg in die Materie war Lotus 1-2-3 für MS-DOS. 300 Seiten Dokumentation in einem Karton mit 3 Disketten. Und natürlich habe auch ich diese Tabellenkalkulation wie eine Datenbank benutzt, ohne zu ahnen was ich mir und meinen Nachfolgern damit antue.
Wie auch immer, Deine Base- Tutorials sind für eine bestimmte Personengruppe das Beste was man sich antun kann wenn man überhaupt bereit ist, sich Base anzutun (“the drunken cousin of LO components”). Von meiner eigenen Autodidakten-Karriere ausgehend, hätte ich persönlich vor 20 Jahren (da war meine Flucht aus Windows/Office/VBA) mit diesen Schriften nicht ganz so viel anfangen können. Was mir persönlich damals sehr geholfen hat war ein deutschsprachiges Tutorial über relationale Datenbanken im Allgemeinen, heruntergebrochen auf ein paar Tabellen einer Patientenkartei, ohne auf Formulare oder Berichte mehr einzugehen als mit ein paar Access-Sceenshots. Da ging es um Normalformen, adäquate Datentypen und andere Regeln, die man nur ausnamsweise brechen sollte nachdem man ihren Sinn und Zweck verstanden hat.
Ich verstehe die grundlegende Funktion von Base-Formularen so, dass sie seit mehr als 20 Jahren (StarOffice 5?) das absolute Minimum an Werkzeugen bereitstellen, um 1-1, 1-n und m-n-Relationen in einer UI abzubilden. Mehr ist nicht unbedingt nötig, weniger ist kaum möglich, und dieses Wenige erfordert in besonderem Maße, dass die zugundeliegende Tabellenstruktur regelkonform ist. Es ist mit diesem reduzierten Werkzeugkasten möglich, bedienbare (aber nicht schöne) Formulare mit Unterformularen für jede der 3 genannten Beziehungen in beide Richtungen zu erstellen.
Für OpenOffice.org 2 hätte ich mir schon einige Verbesserungen bei der Datenbank-Funktionalität gewünscht, aber Base empfinde ich bis heute als große Enttäuschung. Nein, eigentlich ist es mehr eine Täuschung weil es dem Anfänger nur ein Fake-Cockpit präsentiert, mit dem die darunterliegende Maschine nicht zu kontrollieren ist. Glücklicherweise hatten Ocke Jansen und Frank Schönheit noch genug Zeit, ein paar grundlegende Verbesserungen einzupflegen bevor Sun Microsystems platt gemacht wurde. Diese unsäglichen “Assistenten” sind von Beginn an unverändert unbrauchbar (Ausnahme: Berichtassistent).

@RobertG ,
Base ist nicht gerade meine große Welt.
Früher hatte ich mal mittelgroße Access DB’s erstellt, das war beruflich bedingt.
Seit meiner Rente (aua, auch schon ewig her), habe ich mit Base/HSQLDB begonnen.
Sind alles kleinere Werke und funktionieren gut.
Im Gegensatz zu @Villeroy bin ich der Meinung, dass die Assisten ganz gut tauglich sind (für den Hausgebrauch).

So nun zu Deiner Frage. Du schreibst “Beispielprojekt”, was für mich schon wieder etwas voluminös klingt. Deshalb von mir eine etwas andere Betrachtungsweise.
Wie wäre es mit ein paar Hightlights/Spotlights, wie auch immer.

  1. Bilder
    Wie werden Bilder eingebunden in die DB. Hierzu habe ich schon einige Fragen/Antworten hier gelesen (irgenwelche Felder und Links).
  2. Formulare
    Wie wird ein Startformular aufgebaut, dass andere Formulare aufruft.

Mir ist schon klar, dass als Grundlage hier auch jeweils eine BeispielDB erforderlich ist.

Einzelne kurzgefasste Themen haben den Vorteil, dass man nicht ein mehrere-hundert Seiten Dokument durchforsten muss.

Base ist ja nur das Frontend. Wenn dein Datenbank-Backend bereits Bilder als Binärdaten gespeichert hat, dann hast Du eventuell ein Problem weil ein Base-Formular die gesamte Menge an darstellbaren Daten in den RAM lädt und möglicherweise abstürzt. Wenn also die ersten 40 Datensätze 40 Bilder mit hunderten Megabytes enthalten, dann mag das noch angehen. Wenn man dann aber zum letzten von tausenden Datensätzen navigiert gibt es wohl massive Probleme mit dem Arbeitsspeicher. Ich habe das aber seit vielen Jahren nicht mehr getestet. “Die Leute” speichern ja grundsätzlich Fototapeten in astronomischer Auflösung mit maximaler Farbtiefe.

Die Empfehlung lautet daher, möglichst Verweise auf Bilddateien als Text zu speichern, also nur Dateinamen. Dann wird immer nur das eine Bild des aktuellen Datensatzes in ein Picture Control geladen. Bei umfassenden Berichten mit vielen Datensätzen kann das aber wieder problematisch sein (würde ich mal annehmen) weil der Bericht ja alle Bilder ausgeben soll.

Da die eingebetteten Formulare und Berichte nicht per URL adressierbar sind, muss für diese triviale Aufgabe ein Makro verwendet werden.
In unserem Betrieb speichere ich alle Formulare in Writer- oder Calc-Dokumenten. Die sind dann als Desktop-Links auch aus dem lokalen Netzwerk zu laden. Ein Startformular würde dann einfach URL Buttons oder Hyperlinks benutzen. Sofern wir irgendwelche Berichte verwenden, sind das Calc-Dokumente mit verknüpften DB-Abfragen und/oder Pivots. Beliebt sind auch kombinerte Formulare und Berichte in Calc-Dokumenten. Auf einem Sheet Suchkriterien in ein Formular eingeben, und auf dem nächsten Sheet erscheint das Resultat als verknüpfter Datenbankbereich oder Pivot. Funktioniert viel besser als mit Calc’s Tabellendaten weil die Datensätze immer klar begrenzt sind. Eine Datenbankabfrage kann immer dieselben Spaltennamen verwenden, und geht immer von der erste Zeile bis zur letzten Zeile. Es gibt nie das Problem, dass ein Pivot oder eine Formel den korrekten Bezug verliert. Es gibt auch nicht all die Probleme, die man gemeinhin mit IF(A1="";…) aufzufangen versucht.

Sehr viele Probleme mit dem Frontend kommen daher, dass der Formularassistent und der Abfrageassistent nur einen kleinen Bruchteil der Möglichkeiten abdeckt und “die Leute” dann glauben, das sei nun alles was geht.
Ich nehme an, dass Calc’s Formelassistent jede mögliche Formel darstellen kann. Davon ist der Abfrageassistent extrem weit entfernt. Ich glaube auch kaum, dass das möglich ist.

@Villeroy ,
erstmal vielen Dank für Deine ausführlichen Erklärungen.
Damit hatte ich jetzt nicht gerechnet, da Deine ausführlichen Beschreibungen IMHO hier Off-topic zur Frage von @RobertG stehen.
Meine beiden Themen waren ja nur als Anregung und Beispiel für @RobertG gedacht.
Aber zuviel Information hat ja noch nie geschadet und @RobertG kann es evtl. gleich mitverwenden… :grinning:


…und “die Leute” dann glauben, das sei nun alles was geht.

Das ist bei mir nicht der Fall.
Aber das, was die Assistenten hergeben, reicht für meine Zwecke allemal aus.
Meine kleinen Mini-DB’s kriegt ja sonst auch niemand in die Finger.

Naja, es ist insofern on topic als es auf so triviale Fragen keine trivialen Antworten gibt weil Base so defizitär ist. Es kann Bilder nicht anständig handhaben und es kann seine eigenen eingebetteten Objekte nicht ohne Makro-Code öffnen. Daher sind Roberts Anleitungen so überaus gewissenhaft und detailliert. Zum Teil hat man es mit endlosen Ketten von Work-Arounds zu tun zusätzlich zu den ganz normalen Abwägungen und Prozeduren. Am Ende steht trotz alledem ein ganz brauchbares Resultat wenn man sich von einer regelkonformen Datenbankstruktur über sinnvolle Abfragen zu einer geschickten Kombination von Formular-Bausteinen vorgearbeitet hat. Immer schön speichern und gelegentliche Crashes beim Formularentwurf tolerieren :grinning:
Für unseren Kleinbetrieb ist Base die wichtigste LO Komponente. Alle regelmäßig genutzten Vorlagen und Dokumente sind mit irgendeiner Datenbank verbunden. Erstaunlich ist, wie gut das funktioniert wenn man die Entwurfsphase erstmal abgeschlossen hat. Ab und zu muss ich mal ad-hoc eine Empfängerliste für einen Serienbrief aus verschiedenen Datenquellen kompilieren. Das kopiere ich in Calc zusammen und verbinde dann das Dokument mit einer bestehenden odb-Datenquelle. Die Mitarbeiterin ruft dann die passende Briefvorlage auf und wählt Bearbeiten>Datenquelle … um die Serienbrieffelder mit der richtigen Quelle zu verbinden.

@Villeroy ,
na da kannst Du ja und Deine anderen Mitstreiter froh sein, dass Du so tief in der Materie drinsteckst.
Ich gehe mal davon aus, das die allermeisten Kleinbetriebe das in dieser Form nicht umsetzen können/könnten.
Weiterhin viel Erfolg.

Will ja außer mir auch gar keiner. Ist ja nicht von Microsoft. Wenn ich die ganzen “VBA-Lösungen” sehe dann frage ich mich auch, wer all diese Code-Wüsten je produziert hat. Ich verwende seit Jahren die selben 200 Zeien Makro-Code, meistens um Verknüpfungen zu aktualisieren.