[de-users] Re: Datenbank .dbf konvertieren nach .odb
On Mon 13 Feb 2012 11:08:06 CET, Bernhard Kanold bkan...@t-online.de wrote: Aus START = Windows Explorer = Dokumente rufe ich im Ordner ODB - Dateien die Datenbank x.dbf auf. Es erscheint ein Bildschirm : Titel = DBaseimport - Zeichensatz , mit Dropdown Menue. Ich wähle hier den Zeichensatz : Westeuropa (DOS/OS2) - 850/International. Dann öffnet sich die Datenbank x.dbf im Tabellenformat. Was muß ich tun, um die .dbf Datenbank umzuwandeln in eine .odf Datenbank und diese dann in den Ordner ODB - Datei aufzunehmen, um dann ABFRAGEN, FORMULARE und BERICHTE zu gestalten?? danke für Anweisungen im Voraus. B.Kanold Hallo, ich würde es so probieren: dbf in csv konvertieren z.B. mit diesem Programm: http://www.heise.de/software/download/convert/41526 die csv-Datei direkt in Base importieren oder wenn das Schwierigkeiten macht einfach in Calc einlesen und die Tabelle dann in Base in Tabellenfenster kopieren. mfg Alois ddd -- - To unsubscribe send email to users-unsubscr...@de.openoffice.org For additional commands send email to sy...@de.openoffice.org with Subject: help
[de-users] Re: Datenbank .dbf konvertieren nach .odb
Hallo Bernd, Unter Windows 7 läuft OOo 3.3 Aus START = Windows Explorer = Dokumente rufe ich im Ordner ODB - Dateien die Datenbank x.dbf auf. Falscher Ansatz, um eine Datenbank mit allen Funktionen zu erhalten. OpenOffice → Neu → Datenbank → Verbindung zu einer bestehenden Datenbank herstellen → dBase Du gründest eine *.odb-Datenbank, die auf Deine extrene *.dbf-Datei zugreift. Die *.dbf-Datei bleibt also bestehen und in sie wird auch reingeschrieben. Die Abfragen, Formulare und Berichte stehen aber in der *,odb-Datenbank. Gruß Robert -- - To unsubscribe send email to users-unsubscr...@de.openoffice.org For additional commands send email to sy...@de.openoffice.org with Subject: help
[de-users] Re: Datenbank Base 3.3
Hans-Otto Klöckner schrieb: Hallo, 1. Gibt es irgendwo ein Handbuch, speziell zu Base? http://www.galileocomputing.de/katalog/buecher/titel/gp/titelID-2158?GalileoSession=59769417A4-sr8.RXiw http://www.cul.de/oobasic.html Gruß Michael -- - To unsubscribe send email to users-unsubscr...@de.openoffice.org For additional commands send email to sy...@de.openoffice.org with Subject: help
[de-users] Re: Datenbank Base 3.3
michael schrieb: Hans-Otto Klöckner schrieb: Hallo, 1. Gibt es irgendwo ein Handbuch, speziell zu Base? http://www.galileocomputing.de/katalog/buecher/titel/gp/titelID-2158?GalileoSession=59769417A4-sr8.RXiw http://www.cul.de/oobasic.html Sorry: Leicht falsche Baustelle! Hier der richtige Link: http://www.galileocomputing.de/katalog/buecher/titel/gp/titelID-1939 Gruß Michael -- - To unsubscribe send email to users-unsubscr...@de.openoffice.org For additional commands send email to sy...@de.openoffice.org with Subject: help
[de-users] Re: Datenbank Base 3.3
Hallo Hans-Otto, 1. Gibt es irgendwo ein Handbuch, speziell zu Base? Vielleicht hilft Dir auch der Link zu der zugrundeliegenden HSQLDB? http://hsqldb.org/doc/guide/ 2. Von DBase 5 war ich gewohnt in einer bestehenden Tabelle Spalten beliebig zu löschen und/oder neue einzufügen sowie die Reihenfolge der Spalten durch ziehen und ablegen zu ändern. Wie geht das bei Base? Beleibig Löschen geht so lange, wie Du die Felder nicht mit anderen Tabellen verknüpft hast. Das musst Du mit der rechten Maustaste über der Tabelle - Tabelle bearbeiten erledigen. Durch Ziehen und Ablegen eine Reihenfolge zu ändern geht in der GUI nicht (meine ich zumindest, habe ich mich aber auch nie lange mit aufgehalten, da ich die eigentlichen Tabellen zu Eingaben nicht nutze). Die entsprechende Position über die SQL-Syntax herzustellen steht auf der oben angegebenen Seite: ALTER TABLE tablename ADD columnname Datatype BEFORE existingcolumn Aber ehrlicherweise sei auch hier darauf hingewiesen: Reihenfolgen spielen keine Rolle, da sie in den Formularen sowieso beliebig erstellt werden können. Und relationale Datenbanken sind ohne Formulare sowieso nicht vernünftig bedienbar - es sei denn, Du kennst alle Fremdschlüssel auswendig. Gruß Robert -- - To unsubscribe send email to users-unsubscr...@de.openoffice.org For additional commands send email to sy...@de.openoffice.org with Subject: help
[de-users] Re: Datenbank OOo-Base
Hallo Rainer, Im englischsprachigen Forum http://user.services.openoffice.org findest Du ebenfalls viel Information zum Thema, einschließlich einiger Tutorials von Benutzern. Screenshots und kleine Dateianhänge sind dort willkommen, da sie in der Regel sehr hilfreich bei der gemeinsamen Problemlösung sind. Letzteres gilt auch für das deutsche http://de.openoffice.info Ich werde nicht müde zu betonen, dass OOo Base nicht die Anwendung ist, die sich die meisten Leute erhoffen. Base ist kein vollständiges Datenbankprogramm. Die Qualität liegt sehr weit hinter den anderen Komponenten, und abgesehen von unverbundenen dBase-Dateien kann es nichts erzeugen, was von anderen Programmen aus zugreifbar wäre. Auf Dauer fährst Du sicher besser, irgendein geeignetes Datenbankprogramm zu verwenden, das dann auch mittels Base in diese Office-Suite eingebunden werden kann. Als Brücke zu existierenden Datenbanken anderer Hersteller leistet Base sehr gute Dienste. Es ermöglicht die Ausgabe von Datenbankdaten in ODF oder PDF, Serienbriefe, Tabellenkalkulationen auf Grundlage von konsistenten Daten und vieles mehr. Gruß, Andreas S. - To unsubscribe, e-mail: users-unsubscr...@de.openoffice.org For additional commands, e-mail: users-h...@de.openoffice.org
Re: [de-users] Re: Datenbank-Beispiel für Ba se
Ja, bitte fangt an - werde begeisterter Schüler sein ! gruß, claus Am 16.02.2010 13:30, schrieb Ernst Hügli: Hallo Andreas Am 16.02.2010 12:40, schrieb Andreas Saeger: Ich behaupte, dass es mit dem gegebenen Wekzeugsatz irrational ist, ein Datenbankprodukt zu erstellen, für das andere Leute gerne Geld auf den Tisch legen würden. Die erste Frage wäre: Wo kann ich das an meine Bedürftnisse anpassen? Antwort: Installiere einen Datenbankserver deiner Wahl, implementiere die erforderlichen Strukturen, Views, stored Procedures, Trigger und Zugangsberechtigungen, wenn Deine Datenbank dann fertig ist, programmiere schließlich ein Frontend hinter die archaische Formularstruktur von OOo Base. Ach so, danke. Ich dachte Base wäre ein Datenbankprogramm. Nein, ist es nicht wirklich. Einmal mehr: Du machst nieder, Du zeigst, was alles nicht geht - aber wo ist Dein Ansatz einer Lösung? Jammern kann jeder, aber das löst keine Probleme. Vor allem: Du sprichst schon wieder von einem Luxusschloss - kein Architekt, kein Baumeister wird so anfangen. Ich behaupte nicht, Du habest Unrecht - aber wenn es so ist: könnte nicht gerade das *ein* Lernziel sein? Und den Lernenden dadurch aufzeigen, welche Alternativen sie haben? *Was* sie mit Base lösen können, wo die Grenzen sind, und wo sie nach Alternativen (Programmieren *oder* einen anderen DB-Server aufschalten) suchen müssen bzw. wann sie einen Experten einschalten müssen. Gerade in dem Falle kann es nützlich sein, wenn im Gespräch mit dem Experten der User über ein Grundverständnis für DB's verfügt - das Gespräch wird in jedem Falle fruchtbarer. Ich behaupte aber, die wenigsten werden so weit in Base und DB's eindringen, dass die Beschränkungen für sie zum Problem werden. Denen aufzuzeigen, wo ihre Grenzen sind, könnte ja auch ein Lernziel sein. Gerade, damit nicht die Haltung aufkommt: Ich brauche nur das richtige Programm, dann kann ich *alle* Probleme selber lösen. *Das* ist aber kein Base-spezifisches Problem. Was glaubst Du, wieviele Leute meinen, bloss weil sie ein bisschen in Writer tippen können seien sie die geborenen Layouter und Buchdrucker. Und verstossen gegen soviele Regeln wie nur möglich. Bloss: Writer ist etwas geduldiger und grosszügiger gegen Fehlmanipulationen bzw. typische Fehler als Base. Ich dachte, ein Ziel könnte sein, den Anwendern an einem gut durchdachten (da stimme ich Euch Experten bei!), interessanten, einfachen Beispiel (das aber das Potential für komplexere Fragestellungen und Entwicklungen hat) durch gute Begleitung und Dokumentation einen Einstieg in DB's zu ermöglichen. Ich stimme Euch absolut bei: was in der Entwicklung nicht angedacht ist, kann später - wenn überhaupt - nur noch schwer korrigiert werden. Aber wenn das eine derart *zentrale* Aussage ist: warum soll sie nicht auch Gegenstand des Lernprozesses sein? Wo ist der Beinbruch, wenn der User - vielleicht frustriert, aber motiviert - erkennt, dass sein ursprüngliches Konzept nicht weiter entwickelt und demnach entsorgt werden muss, weil er zu wenig an die Details der Nutzung gedacht hat? Es ist eine Frage der Kommunikation, ob er das als Chance oder als Frust erlebt. Ich betone nochmals, was André Schnabel schon geschrieben hat: es geht nicht darum, eine produktive DB zu entwickeln, die mit käuflichen Produkten konkurrieren kann. Das wäre eine Selbstüberschätzung. Sondern es geht darum, Interessierten an einem Beispiel einen Einstieg in DB-Entwicklung zu ermöglichen. Und zwar eben so, dass sie nicht an Base gebunden sind. Sondern so, dass sie ihr Wissen auch auf eine andere Umgebung übertragen können. Von daher hat man auch nicht die Pflicht, *alles* zum voraus schon zu planen - ein guter Lehrer zeichnet sich dadurch aus, dass er ein Problem zunächst so weit abstrahiert, dass es für die SchülerInnen verständlich ist. Im Laufe des Lernprozesses kann man dann Stück um Stück die Komplexität erhöhen. Mein Ziel als Lehrer besteht aber oftmals darin, den SchülerInnen ein Verständnis für die Thematik und ein Grundvokabular mitzugeben und sie dann mit der Bemerkung zu entlassen: ihr seid nicht in der Lage, die Probleme selber zu lösen, aber ihr seid in der Lage, die Probleme zu erkennen, einzugrenzen und mit einem minimalen Sachverstand mit einem Experten über die Lösung zu reden. In diesem Sinne könnte ein Lernziel ja auch darin bestehen aufzuzeigen, dass es durchaus Sinn macht, für gute, professionelle Software Geld auszugeben, und dass unter der sog. Freeware nebst einigen Perlen auch viel Schrott zu finden ist - einfach, weil diese programmierer keine Chance hätten, ihr produkt gegen gutes Geld zu verkaufen. Wenn wir das im Bereich von DB's hinkriegen würden, hätten wir unglaublich viel erreicht, und einige immer wiederkehrende Threads in dieser Liste würden (hoffentlich) verschwinden - ich weiss, ich bin ein unverbesserlicher Optimist. Noch was zum Thema Planung: man kann Planung (so notwendig sie im
[de-users] Re: Datenbank-Beispiel für Base
Ernst Hügli wrote: Hallo Michael Am 16.02.2010 11:03, schrieb michael: Auch hier hilft nur detailliertes Wissen über die Bedingungen der Praxis. Tut mir leid, wenn ich jetzt sehr hart auf Deine Mail antworte. Aber mir scheint, von ein paar wenigen Ausnahmen abgesehen, sind die Datenbankexperten hier vor allem eins: grosse Schwätzer, aber k(l)eine Macher. Ihr wisst alle ganz genau, warum etwas nicht geht. Aber einen Ja, genau. Da kann ich Dir *eigentlich* nur zustimmen, muss aber hinzufügen, dass Du dennoch falsch gewickelt bist. Das Problem ist nicht so sehr, dass dieses oder jenes nicht gemacht werden könnte oder schon gemacht wurde, sondern dass Base in dem Moment zu einer _Entwicklungsplattform_ wird, wo Du eine Datenbank mit Eingabeformularen erstellst. Du benutzt dass Programm, um etwas zu erzeugen, das später von einem angenommenen Benutzer benutzt werden soll. Auf user.services.openoffice.org kann man Beispieldatenbanken heraufladen, und ich tue dies ausdauernd mehrmals pro Woche. Dies hilft nur einer Minderheit von Fragestellern weiter. Zum einen weil ein Teil der Fragesteller nicht in der Lage ist, angebotene Lösungswege auf das eigene Problem zu übertragen, zum anderen weil die Leute von der einen oder anderen Datenbank derart verwöhnt sind, dass sie es partout nicht akzeptieren können, wenn gewisse Selbstverständlichkeiten in Base etwas umständlicher darstellbar sind (gerade weil die Entwicklungsplattform einfacher gestrickt ist, ist vieles schwieriger). Fast jede Beispieldatenbank, selbst die ganz einfach gestrickten, übersteigen ab einem sehr frühen Punkt die Fähigkeiten der angebotenen Assistenten (Wizards), so dass schon bei ganz gewöhnlichen Standardaufgaben die Kommandozeile (ExtrasSQL...), die direkte Abfrage von der Datenbank (SQL-Editor) und manuelles Formulardesign zum Einsatz kommt. Zu Makros nur soviel, da ich sonst völlig abschweife: Der exzessive Einsatz von Makros verdeutlicht mehr Probleme als er zu lösen in der Lage ist. Das Verständnisproblem potenziert sich sich dadurch. Oft entsteht der Eindruck, dass man programmieren muss, um überhaupt eine brauchbare Datenbank zu bekommen. Auch auf die Gefahr hin, dass ich jetzt selber falsch gewickelt bin: Ich behaupte, dass es mit dem gegebenen Wekzeugsatz irrational ist, ein Datenbankprodukt zu erstellen, für das andere Leute gerne Geld auf den Tisch legen würden. Die erste Frage wäre: Wo kann ich das an meine Bedürftnisse anpassen? Antwort: Installiere einen Datenbankserver deiner Wahl, implementiere die erforderlichen Strukturen, Views, stored Procedures, Trigger und Zugangsberechtigungen, wenn Deine Datenbank dann fertig ist, programmiere schließlich ein Frontend hinter die archaische Formularstruktur von OOo Base. Ach so, danke. Ich dachte Base wäre ein Datenbankprogramm. Nein, ist es nicht wirklich. - To unsubscribe, e-mail: users-unsubscr...@de.openoffice.org For additional commands, e-mail: users-h...@de.openoffice.org
Re: [de-users] Re: Datenbank-Beispiel für Ba se
Hallo Andreas Am 16.02.2010 12:40, schrieb Andreas Saeger: Ich behaupte, dass es mit dem gegebenen Wekzeugsatz irrational ist, ein Datenbankprodukt zu erstellen, für das andere Leute gerne Geld auf den Tisch legen würden. Die erste Frage wäre: Wo kann ich das an meine Bedürftnisse anpassen? Antwort: Installiere einen Datenbankserver deiner Wahl, implementiere die erforderlichen Strukturen, Views, stored Procedures, Trigger und Zugangsberechtigungen, wenn Deine Datenbank dann fertig ist, programmiere schließlich ein Frontend hinter die archaische Formularstruktur von OOo Base. Ach so, danke. Ich dachte Base wäre ein Datenbankprogramm. Nein, ist es nicht wirklich. Einmal mehr: Du machst nieder, Du zeigst, was alles nicht geht - aber wo ist Dein Ansatz einer Lösung? Jammern kann jeder, aber das löst keine Probleme. Vor allem: Du sprichst schon wieder von einem Luxusschloss - kein Architekt, kein Baumeister wird so anfangen. Ich behaupte nicht, Du habest Unrecht - aber wenn es so ist: könnte nicht gerade das *ein* Lernziel sein? Und den Lernenden dadurch aufzeigen, welche Alternativen sie haben? *Was* sie mit Base lösen können, wo die Grenzen sind, und wo sie nach Alternativen (Programmieren *oder* einen anderen DB-Server aufschalten) suchen müssen bzw. wann sie einen Experten einschalten müssen. Gerade in dem Falle kann es nützlich sein, wenn im Gespräch mit dem Experten der User über ein Grundverständnis für DB's verfügt - das Gespräch wird in jedem Falle fruchtbarer. Ich behaupte aber, die wenigsten werden so weit in Base und DB's eindringen, dass die Beschränkungen für sie zum Problem werden. Denen aufzuzeigen, wo ihre Grenzen sind, könnte ja auch ein Lernziel sein. Gerade, damit nicht die Haltung aufkommt: Ich brauche nur das richtige Programm, dann kann ich *alle* Probleme selber lösen. *Das* ist aber kein Base-spezifisches Problem. Was glaubst Du, wieviele Leute meinen, bloss weil sie ein bisschen in Writer tippen können seien sie die geborenen Layouter und Buchdrucker. Und verstossen gegen soviele Regeln wie nur möglich. Bloss: Writer ist etwas geduldiger und grosszügiger gegen Fehlmanipulationen bzw. typische Fehler als Base. Ich dachte, ein Ziel könnte sein, den Anwendern an einem gut durchdachten (da stimme ich Euch Experten bei!), interessanten, einfachen Beispiel (das aber das Potential für komplexere Fragestellungen und Entwicklungen hat) durch gute Begleitung und Dokumentation einen Einstieg in DB's zu ermöglichen. Ich stimme Euch absolut bei: was in der Entwicklung nicht angedacht ist, kann später - wenn überhaupt - nur noch schwer korrigiert werden. Aber wenn das eine derart *zentrale* Aussage ist: warum soll sie nicht auch Gegenstand des Lernprozesses sein? Wo ist der Beinbruch, wenn der User - vielleicht frustriert, aber motiviert - erkennt, dass sein ursprüngliches Konzept nicht weiter entwickelt und demnach entsorgt werden muss, weil er zu wenig an die Details der Nutzung gedacht hat? Es ist eine Frage der Kommunikation, ob er das als Chance oder als Frust erlebt. Ich betone nochmals, was André Schnabel schon geschrieben hat: es geht nicht darum, eine produktive DB zu entwickeln, die mit käuflichen Produkten konkurrieren kann. Das wäre eine Selbstüberschätzung. Sondern es geht darum, Interessierten an einem Beispiel einen Einstieg in DB-Entwicklung zu ermöglichen. Und zwar eben so, dass sie nicht an Base gebunden sind. Sondern so, dass sie ihr Wissen auch auf eine andere Umgebung übertragen können. Von daher hat man auch nicht die Pflicht, *alles* zum voraus schon zu planen - ein guter Lehrer zeichnet sich dadurch aus, dass er ein Problem zunächst so weit abstrahiert, dass es für die SchülerInnen verständlich ist. Im Laufe des Lernprozesses kann man dann Stück um Stück die Komplexität erhöhen. Mein Ziel als Lehrer besteht aber oftmals darin, den SchülerInnen ein Verständnis für die Thematik und ein Grundvokabular mitzugeben und sie dann mit der Bemerkung zu entlassen: ihr seid nicht in der Lage, die Probleme selber zu lösen, aber ihr seid in der Lage, die Probleme zu erkennen, einzugrenzen und mit einem minimalen Sachverstand mit einem Experten über die Lösung zu reden. In diesem Sinne könnte ein Lernziel ja auch darin bestehen aufzuzeigen, dass es durchaus Sinn macht, für gute, professionelle Software Geld auszugeben, und dass unter der sog. Freeware nebst einigen Perlen auch viel Schrott zu finden ist - einfach, weil diese programmierer keine Chance hätten, ihr produkt gegen gutes Geld zu verkaufen. Wenn wir das im Bereich von DB's hinkriegen würden, hätten wir unglaublich viel erreicht, und einige immer wiederkehrende Threads in dieser Liste würden (hoffentlich) verschwinden - ich weiss, ich bin ein unverbesserlicher Optimist. Noch was zum Thema Planung: man kann Planung (so notwendig sie im Bereich von DB's auch ist) auch übertreiben. John Lennon hat mal ganz treffend gesagt: Life is what happens when you
Re: [de-users] Re: Datenbank-Beispiel für Base
Am Dienstag 16 Februar 2010 13:30:01 schrieb Ernst Hügli: schnipp (Roman gekürzt) Also: warum nicht losgehen, einige der von Robert, von Mechtilde, oder von anderen hier vorgeschlagenen oder bereitgestellten Beispiele nehmen, und so weiter entwickeln, dass es für ein Greenhorn möglich ist, in die Geheimnisse von DB's einzutauchen. Bist Du, Andreas, seid Ihr anderen DB-Experten dazu bereit, oder wollen wir statt dessen lieber weiter über die Grenzen und Beschränktheiten von Base meditieren und unseren Frust loswerden? ich will Dir mal erklären, was ein User macht, der sich für sich erstmalig eine Datenbank entwickeln will: Er kauft sich ein Buch, und sei es über Access, und macht sich grundsätzlich mit Datenbanken vertraut. Wenn er die Materie begriffen hat, fängt er an, sich eine Datenbankanwendung zu basteln. Im beruflichen Bereich bekommt er zu 99,9% Datenbanken gestellt und wird darin eingearbeitet. Gruß Thomas Mit wieder etwas mehr Hoffnung grüsst Ernst - To unsubscribe, e-mail: users-unsubscr...@de.openoffice.org For additional commands, e-mail: users-h...@de.openoffice.org
[de-users] Re: Datenbank-Beispiel für Base
Ernst Hügli wrote: Hallo Andreas Am 16.02.2010 12:40, schrieb Andreas Saeger: Ich behaupte, dass es mit dem gegebenen Wekzeugsatz irrational ist, ein Datenbankprodukt zu erstellen, für das andere Leute gerne Geld auf den Tisch legen würden. Die erste Frage wäre: Wo kann ich das an meine Bedürftnisse anpassen? Antwort: Installiere einen Datenbankserver deiner Wahl, implementiere die erforderlichen Strukturen, Views, stored Procedures, Trigger und Zugangsberechtigungen, wenn Deine Datenbank dann fertig ist, programmiere schließlich ein Frontend hinter die archaische Formularstruktur von OOo Base. Ach so, danke. Ich dachte Base wäre ein Datenbankprogramm. Nein, ist es nicht wirklich. Einmal mehr: Du machst nieder, Du zeigst, was alles nicht geht - aber wo ist Dein Ansatz einer Lösung? Jammern kann jeder, aber das löst keine Probleme. Vor allem: Du sprichst schon wieder von einem Luxusschloss - kein Architekt, kein Baumeister wird so anfangen. Es gibt wirklich sehr, sehr viele Datenbankentwickler für die es ungemein attraktiv *wäre*, ihre fertige Desktop-Datenbank von Access, FileMaker oder ähnlichem nach OOo zu portieren, ganz einfach wegen der Plattformunabhängigkeit und Lizenzkostenfreiheit der zugrundeliegenden Software. Ich behaupte nicht, Du habest Unrecht - aber wenn es so ist: könnte nicht gerade das *ein* Lernziel sein? Und den Lernenden dadurch aufzeigen, welche Alternativen sie haben? *Was* sie mit Base lösen können, wo die Grenzen sind, und wo sie nach Alternativen (Programmieren *oder* einen anderen DB-Server aufschalten) suchen müssen bzw. wann sie einen Experten einschalten müssen. Gerade in dem Falle kann es nützlich sein, wenn im Gespräch mit dem Experten der User über ein Grundverständnis für DB's verfügt - das Gespräch wird in jedem Falle fruchtbarer. Gibt es in rauhen Mengen. Scheint aber nicht zu helfen wenn Point-And-Click die einzig bekannte Methode ist, einem Computer etwas zu entlocken. Sinngemäß zitiert: Ich habe keinen Bock auf einen akademischen Kurs in Datenbankphilosophie sondern ich will wissen, wie ich an's Ziel komme! als Gegenantwort auf eine recht simple Antwort wie eine Datenbank mittels Primärschlüsseln editierbar gemacht werden kann, falls das die Datenbankverbindung überhaupt hergibt. Ich behaupte aber, die wenigsten werden so weit in Base und DB's eindringen, dass die Beschränkungen für sie zum Problem werden. Denen aufzuzeigen, wo ihre Grenzen sind, könnte ja auch ein Lernziel sein. Gerade, damit nicht die Haltung aufkommt: Ich brauche nur das richtige Programm, dann kann ich *alle* Probleme selber lösen. *Das* ist aber kein Base-spezifisches Problem. Was glaubst Du, wieviele Leute meinen, bloss weil sie ein bisschen in Writer tippen können seien sie die geborenen Layouter und Buchdrucker. Und verstossen gegen soviele Regeln wie nur möglich. Bloss: Writer ist etwas geduldiger und grosszügiger gegen Fehlmanipulationen bzw. typische Fehler als Base. Und genau das kann mit einer Entwicklungsumgebung nicht mehr funktionieren, obwohl MS Access hier ähnliche Maßstäbe setzt wie Word/Excel (Access macht das für mich). Damals(tm), als ich das gleiche Drama mit MS Access durchlitt, hat mir erst ein wenig nackte Theorie das Aha-Erlebnis gebracht. Von da an habe ich überhaupt begriffen, was das Tool von mir verlangt bevor es in die Lage versetzt ist, mir zu helfen. Die Base-Komponente und ihre zahlreichen Fehler sind ein viel größeres Problem als die Beschränkungen. Die ganze Anwendung ist faulig. Man kann wesentlich mehr erreichen, als die grafische Oberfläche nahelegt. Leider beinhaltet wesentlich mehr auch ein paar triviale Selbstverständlichkeiten, für die man bereits zum Texteditor greifen muss. Die Art und Weise wie der grafische Abfragedesigner durch immer andere Fehler funktionierende Abfragen in kaputte verwandelt hat schon etwas unterhaltsameres. Dabei beherrscht der ganze Abfragedesigner nicht mehr SQL als ein blutiger Anfänger nach einem halbtägigen Einführungskurs selber beherrschen könnte, was es andereseits recht leicht macht, das Ding komplett zu ignorieren. Von daher: Aber na klar, Du stößt schon gleich am Anfang and die Grenzen von Base. Macht aber nix, wenn Du Dich auf die _einfachen_Grundlagen_der_Beschreibungssprache_SQL_ einlassen kannst. Der Formularassistent kann wesentliche Aspekte einer ganz einfachen Relation zwischen zwei Tabellen nicht abbilden, weil er keine Listenfelder drauf hat. Dabei kann man im Handbetrieb fast alle denkbaren Relationen über viele Tabellen hinweg in brauchbare Formulare gießen (dazu sollte man dann aber besser die Assistenten für Steuerelemente abschalten!). Der Anfänger will aber zuallererst sein Formular erstellen, sieht aber nur den extrem limitierten Assistenten oder ein aber leeres Writer-Dokkument, bei dem die wichtigste Werkzeugpalette auch noch konsequent ausgeblendet wird: die Symbolleiste Formulardesign. All dies und die Tatsache, dass
Re: [de-users] Re: Datenbank-Beispiel für Ba se
Hallo Ernst, ein Anfang wäre zum Beispiel, wenn du allen hier mitteilst, woran es an den aufgezeigten Beispielen fehlt. Welche Art der Weiterentwicklung hast du dir denn vorgestellt? Viele Grüße Jan Am 16.02.2010 13:30, schrieb Ernst Hügli: Hallo Andreas Am 16.02.2010 12:40, schrieb Andreas Saeger: Ich behaupte, dass es mit dem gegebenen Wekzeugsatz irrational ist, ein Datenbankprodukt zu erstellen, für das andere Leute gerne Geld auf den Tisch legen würden. Die erste Frage wäre: Wo kann ich das an meine Bedürftnisse anpassen? Antwort: Installiere einen Datenbankserver deiner Wahl, implementiere die erforderlichen Strukturen, Views, stored Procedures, Trigger und Zugangsberechtigungen, wenn Deine Datenbank dann fertig ist, programmiere schließlich ein Frontend hinter die archaische Formularstruktur von OOo Base. Ach so, danke. Ich dachte Base wäre ein Datenbankprogramm. Nein, ist es nicht wirklich. Einmal mehr: Du machst nieder, Du zeigst, was alles nicht geht - aber wo ist Dein Ansatz einer Lösung? Jammern kann jeder, aber das löst keine Probleme. Vor allem: Du sprichst schon wieder von einem Luxusschloss - kein Architekt, kein Baumeister wird so anfangen. Ich behaupte nicht, Du habest Unrecht - aber wenn es so ist: könnte nicht gerade das *ein* Lernziel sein? Und den Lernenden dadurch aufzeigen, welche Alternativen sie haben? *Was* sie mit Base lösen können, wo die Grenzen sind, und wo sie nach Alternativen (Programmieren *oder* einen anderen DB-Server aufschalten) suchen müssen bzw. wann sie einen Experten einschalten müssen. Gerade in dem Falle kann es nützlich sein, wenn im Gespräch mit dem Experten der User über ein Grundverständnis für DB's verfügt - das Gespräch wird in jedem Falle fruchtbarer. Ich behaupte aber, die wenigsten werden so weit in Base und DB's eindringen, dass die Beschränkungen für sie zum Problem werden. Denen aufzuzeigen, wo ihre Grenzen sind, könnte ja auch ein Lernziel sein. Gerade, damit nicht die Haltung aufkommt: Ich brauche nur das richtige Programm, dann kann ich *alle* Probleme selber lösen. *Das* ist aber kein Base-spezifisches Problem. Was glaubst Du, wieviele Leute meinen, bloss weil sie ein bisschen in Writer tippen können seien sie die geborenen Layouter und Buchdrucker. Und verstossen gegen soviele Regeln wie nur möglich. Bloss: Writer ist etwas geduldiger und grosszügiger gegen Fehlmanipulationen bzw. typische Fehler als Base. Ich dachte, ein Ziel könnte sein, den Anwendern an einem gut durchdachten (da stimme ich Euch Experten bei!), interessanten, einfachen Beispiel (das aber das Potential für komplexere Fragestellungen und Entwicklungen hat) durch gute Begleitung und Dokumentation einen Einstieg in DB's zu ermöglichen. Ich stimme Euch absolut bei: was in der Entwicklung nicht angedacht ist, kann später - wenn überhaupt - nur noch schwer korrigiert werden. Aber wenn das eine derart *zentrale* Aussage ist: warum soll sie nicht auch Gegenstand des Lernprozesses sein? Wo ist der Beinbruch, wenn der User - vielleicht frustriert, aber motiviert - erkennt, dass sein ursprüngliches Konzept nicht weiter entwickelt und demnach entsorgt werden muss, weil er zu wenig an die Details der Nutzung gedacht hat? Es ist eine Frage der Kommunikation, ob er das als Chance oder als Frust erlebt. Ich betone nochmals, was André Schnabel schon geschrieben hat: es geht nicht darum, eine produktive DB zu entwickeln, die mit käuflichen Produkten konkurrieren kann. Das wäre eine Selbstüberschätzung. Sondern es geht darum, Interessierten an einem Beispiel einen Einstieg in DB-Entwicklung zu ermöglichen. Und zwar eben so, dass sie nicht an Base gebunden sind. Sondern so, dass sie ihr Wissen auch auf eine andere Umgebung übertragen können. Von daher hat man auch nicht die Pflicht, *alles* zum voraus schon zu planen - ein guter Lehrer zeichnet sich dadurch aus, dass er ein Problem zunächst so weit abstrahiert, dass es für die SchülerInnen verständlich ist. Im Laufe des Lernprozesses kann man dann Stück um Stück die Komplexität erhöhen. Mein Ziel als Lehrer besteht aber oftmals darin, den SchülerInnen ein Verständnis für die Thematik und ein Grundvokabular mitzugeben und sie dann mit der Bemerkung zu entlassen: ihr seid nicht in der Lage, die Probleme selber zu lösen, aber ihr seid in der Lage, die Probleme zu erkennen, einzugrenzen und mit einem minimalen Sachverstand mit einem Experten über die Lösung zu reden. In diesem Sinne könnte ein Lernziel ja auch darin bestehen aufzuzeigen, dass es durchaus Sinn macht, für gute, professionelle Software Geld auszugeben, und dass unter der sog. Freeware nebst einigen Perlen auch viel Schrott zu finden ist - einfach, weil diese programmierer keine Chance hätten, ihr produkt gegen gutes Geld zu verkaufen. Wenn wir das im Bereich von DB's hinkriegen würden, hätten wir unglaublich viel erreicht, und einige immer wiederkehrende Threads in dieser Liste würden (hoffentlich)
[de-users] Re: Datenbank-Beispiel für Base
Mechtilde wrote: Soweit ich das noch in Erinnerung habe ist das eine ganz einfache Version, die sowas wie ein Waren-/Kunden-System abbildet. Hallo, Nordwind.mdb ist für mich so eine Art Leistungsschau für MS Access. Sie enthält so gut wie gar keine Makros und liefert mannigfaltige, sehr lehrreiche Beispiele wie Relationen erst in einer Datenbank definiert und dann in Formularen zugänglich gemacht werden können (Editieren über Tabellengrenzen hinweg). Sicher kann man mit vielfachem Zeitaufwand, wesenlich mehr Makro-Code und Handarbeit auch in Base eine Nordwind.odb erstellen. Dennoch schätze ich mal, dass Base in so einem Vergleich immer schlecht dasteht. Base und Access sind einfach nicht wirklich miteinander vergleichbar. In Base ist alles auf Officedokumente orientiert. Der Kern aus OOo 1.x setzte immer eine bereits vorhandene relationale Datenbank voraus, aus welcher Datensätze in Dokumente importiert werden sollen. Daran hat sich bis heute nur sehr wenig geändert. Hast Du eine funktionierende Serverdatenbank, dann liefert Base eine hervorragende Datenquelle für Officedokumente und der SRB fügt den nötigen Schuss Professionalität und Blendwerk hinzu. Die Werkzeuge, die in Version 2.x hinzugekommen sind, um eine Datenbank aus dem Nichts zu erzeugen sind allerdings bis heute derart fehlerhaft, unvollständig und unglaublich irreführend fehlimplementiert, dass meiner Meinung nach ein Einstieg in die Welt der Relationalen Datenbank über Base/HSQLDB praktisch unmöglich ist. Was sinvolle Beispieldatenbanken angeht, so findet man mannigfaltige Inspirationen im Calc-Support. Sobald die Leute Word/Writer beiseite legen, suchen sie geradezu verzweifelt nach einer Möglichkeit, ihre Daten zu organisieren und stolpern umgehend in die Tabellenkalkulation, wo sie Papiertabellen in die 67 Millionen Quadratzellen große Spielmatrix übertragen ohne die (doch recht komplizierten) Spielregeln dieser Matrix auch nur im Ansatz zu kennen (auch Calc/Excel unterscheiden Datentypen und können mit normalisierten Tabellenbereichen mehr anfangen als mit freihändigen Datensammlungen über hunderte Sheets und Dateien). - Arbeitszeiteiterfassung im Schichtdienst - Rechnung.xlt ist eine Rechnungsvorlage in Excel mit optionaler Datenbankanbindung. Sieht man immer noch sehr oft als Kassensoftware für Krauterläden. - Immer und immer wieder jegliche Art von Zusammenstellungen (Artikel zu Lieferungen, Teile zu Maschinen, Menschen zu Firmen, Dinge zu Sammlungen...). - Ja, Terminkalender ebenfalls. Eine *einfache* Terminplanung in Base würde wohl die meisten Leute optisch nicht ansprechen. Kreuztabellen sind nun mal wirklich Calc's Domäne (Mensch x Stunde, Tag x Monat,...). Die Leute sind oft mit formatierten Tabellenblättern zufriedengestellt, in die sie analog zu Papierplänen hineinschreiben. - Auffallend viele Online-Gamer versuchen ihre Strategie mittels einer Datenbankanwendung zu optimieren. Durchaus vergleichbar mit Resourcenplanung in der Geschäftswelt. Bei Calc ist sofort Ende der Fahnenstange wenn Gruppen von Spielern, alle möglichen Punktsysteme und Währungseinheiten für verschiedene Ausstattungsmerkmale über die Zeit variabel sind. - Ach ja, Sporttabellen sind ein ganz großes Thema. Die Fußball-WM in ZA schreit förmlich nach einer Desktop-Datenbank, in die man auch Tipps zum Spielausgang eintragen kann. Eine Datenbank, in die man in 4 Jahren die nächsten Gruppenaufstellungen binnen Minuten eingeben kann anstatt sie aus Browsern nach Calc zu kopieren, was regelmäßig in Weinkrämpfen endet. - Und zum Schluss das aller-allerwichtigste: Es wäre einfach zu schön, wenn Base CSV-Dateien editierbar machen könnte, so dass dieselben Trennzeichen und Zahlenformate wieder auf der Festplatte landen. Schließlich ist CSV ein Datenbankaustauschformat, kommt meistens auch aus irgendwelchen Datenbanken, die nicht im verfügbaren Netzwerk bereit stehen. Tabellenkalkulationen sind per se ungeeignet als Texteditoren, weil ihre Funktion darauf beruht, alles als Fließkommazahl zu interpretieren. Selbstverständlich muss eine Tabellenkalkulation Texttabellen einlesen können (und Calc kann das besser als Excel) aber als Tabelleneditor muss das in die sprichwörtliche Hose gehen. Die Einbindung via HSQLDB ist schon mal großartig, scheitert aber an Datumswerten sofern sie nicht ISO sind, Dezimaltrennern sofern sie nicht Punkt sind, und es gibt noch weitere Einschränkungen. - To unsubscribe, e-mail: users-unsubscr...@de.openoffice.org For additional commands, e-mail: users-h...@de.openoffice.org
[de-users] Re: Datenbank Base
Höhne wrote: Ich habe mich mit OpenOffice das erste Mal beschäftigt und will mit Base meine Datenbanken verwalten, die ich bisher in Access ausgeführt habe. Ich habe eine Datenbank in Base geladen, diese ließ sich auch ohne Probleme darstellen, aber nicht bearbeiten. Die Zellen lassen sich nicht mit Buchstaben füllen, einfügen und löschen von Zeilen oder Spalten geht nicht. oder speichern, speichern unter ist grau usw. Ich habe unter Base dann eine kleine Datenbank erstellt, auch hier ging nicht z.B. einfügen und löschen von Zeilen. Vielen Dank für die Antwort. MfG Höhne Hallo, Base kann immer nur Datensätze einer Tabelle bearbeiten und auch nur dann wenn der Primärschlüssel dieser Tabelle in dem Datensatz enthalten ist. In Access fehlt oft der Primärschlüssel. Ich glaube, Du kannst Base verwenden, um im Tabellenentwurf ein Feld als Primärschlüssel zu deklarieren oder auch ein Auto-ID-Feld hinzufügen. Generell gilt: Datenverarbeitung mit Base ist OK, aber sei vorsichtig wenn Du die Struktur einer externen Datenbank änderst (Relationen +Tabellenentwurf). Also: Backup, Backup und Backup oder die Änderungen in Access vornehmen. - To unsubscribe, e-mail: users-unsubscr...@de.openoffice.org For additional commands, e-mail: users-h...@de.openoffice.org
[de-users] Re: Datenbank Base
Robert geht davon aus, dass Du die Access-DB in eine HSQLDB kopiert hast. Ich ging davon aus dass Du Base mit einer Access-DB verbunden hast. Die Statuszeile des Datenbankfensters gibt Aufschluss über die verwendete Datenbank. - To unsubscribe, e-mail: users-unsubscr...@de.openoffice.org For additional commands, e-mail: users-h...@de.openoffice.org
[de-users] Re: Datenbank nicht gefunden
Volker Heggemann vol...@... writes: Hallo Sergio, Ich habe seit ca 7 Monaten folgende 2 Probleme: 1) DB A mit Fehlermeldung: [Microsoft][ODBC Manager] Der Datenquellenname wurde nicht gefunden, und es wurde kein Standardtreiber angegeben 2) Die Verbindung zu Datenquelle B konnte nicht hergestellt werden. H\OpenOffice\Base\B ist kein zulässiger Pfad . ??? Was soll man davon halten? Seit 7 Monaten ist es ohne gegangen! Ich bin langsam verzweifelt. Wer hat Ideen? Oder muss ich auf MS Office zurück? Da würde ich spontan JA antworten. Es wäre hilfreich zu erfahren ob es denn unter MS Office funktioniert. Hast du schon geguckt, ob unter Systemsteuerung Verwaltung Datenquelle (ODBC) die Einträge richtig sind? Siehe auch http://www.ooowiki.de/MicrosoftAccess mfG Regina Hallo Regina, Ich habe kurz in das Procedere reingeschaut. Es scheint mir äusserst wirksam zu sein. D.h. ich muss die Datenbanken nochmals unter OOo neu erstellen. Ich glaube, dass das die Lösung ist. Ich bin jetzt eine Woche abwesend, werde aber nach meiner Rückkehr sofort an die Arbeit gehen. Und gebe dann Bericht. Vielen Dank für den guten Tip MfG Sergio Wenn das schon alles war, was geholfen hat... Einfach die Datenbank neu erstellen. Das kann ja nicht die wichtigste und umfangreichste Datenbank sein? - aber trotz dem: Du solltest auch den ODBC Treiber für Deine Datenbank aktualisieren, und wenn du von MS Office weg willst, auf eine andere Datenbank umstellen. Wenn du vorher alles mit Access gemacht hast, dann erkundige Dich vorher, ob das mit der Openoffice Datenbank geht, was du brauchst. Ggf. ist es noch günstiger eine andere externe Datenbank Engine zu nutzen. mfg Volker Hallo Regina, Vielen Dank nochmals für Deinen guten Tipp. Ich habe sie wieder, meine Datenbanken! Für Volker, Ich musste nicht die Daten der Datenbanken nochmals neu eingeben. Ich musste nur die Access-Datenbanken nochmals neu in OOo einbinden. Und natürlich müssen allfällige Abfragen und Berichte neu definiert werden.Und da die Access-DB's unter OOo gepflegt worden sind, sind sie auch auf dem letzten Stand. Das Procedere ist unter dem obigen ooowiki-Artikel nachzulesen. Mfg Sergio - To unsubscribe, e-mail: users-unsubscr...@de.openoffice.org For additional commands, e-mail: users-h...@de.openoffice.org
Re: [de-users] Re: Datenbank nicht gefunden
Hallo Sergio, Ich habe seit ca 7 Monaten folgende 2 Probleme: 1) DB A mit Fehlermeldung: [Microsoft][ODBC Manager] Der Datenquellenname wurde nicht gefunden, und es wurde kein Standardtreiber angegeben 2) Die Verbindung zu Datenquelle B konnte nicht hergestellt werden. H\OpenOffice\Base\B ist kein zulässiger Pfad . ??? Was soll man davon halten? Seit 7 Monaten ist es ohne gegangen! Ich bin langsam verzweifelt. Wer hat Ideen? Oder muss ich auf MS Office zurück? Da würde ich spontan JA antworten. ;-) Es wäre hilfreich zu erfahren ob es denn unter MS Office funktioniert. Hast du schon geguckt, ob unter Systemsteuerung Verwaltung Datenquelle (ODBC) die Einträge richtig sind? Siehe auch http://www.ooowiki.de/MicrosoftAccess mfG Regina Hallo Regina, Ich habe kurz in das Procedere reingeschaut. Es scheint mir äusserst wirksam zu sein. D.h. ich muss die Datenbanken nochmals unter OOo neu erstellen. Ich glaube, dass das die Lösung ist. Ich bin jetzt eine Woche abwesend, werde aber nach meiner Rückkehr sofort an die Arbeit gehen. Und gebe dann Bericht. Vielen Dank für den guten Tip MfG Sergio Wenn das schon alles war, was geholfen hat... Einfach die Datenbank neu erstellen. Das kann ja nicht die wichtigste und umfangreichste Datenbank sein? - aber trotz dem: Du solltest auch den ODBC Treiber für Deine Datenbank aktualisieren, und wenn du von MS Office weg willst, auf eine andere Datenbank umstellen. Wenn du vorher alles mit Access gemacht hast, dann erkundige Dich vorher, ob das mit der Openoffice Datenbank geht, was du brauchst. Ggf. ist es noch günstiger eine andere externe Datenbank Engine zu nutzen. mfg Volker - To unsubscribe, e-mail: users-unsubscr...@de.openoffice.org For additional commands, e-mail: users-h...@de.openoffice.org
[de-users] Re: Datenbank nicht gefunden
Regina Henschel rb.hensc...@... writes: Hallo Sergio, Sergio Kirschbaum schrieb: Hi, Basis: Windows XP Home, SP3, OOo 3.1.1 Ursprung der Datenbanken: MS Access, Einbau einer neuen Festplatte mit klonen von der alten, Diverse Partitions: OOo Programm auf F, Daten auf G Ich habe seit ca 7 Monaten folgende 2 Probleme: 1) DB A mit Fehlermeldung: [Microsoft][ODBC Manager] Der Datenquellenname wurde nicht gefunden, und es wurde kein Standardtreiber angegeben 2) Die Verbindung zu Datenquelle B konnte nicht hergestellt werden. H\OpenOffice\Base\B ist kein zulässiger Pfad . Zu 1): Ich habe das ganze WWW durchsurft, aber irgendwie nichts vernünftiges gefunden obwohl viel darüber geschrieben wurde. ZU 2): Ich habe eine Partition H, habe aber nie etwas in Zusammenhang mit OOo darauf abgelegt. Als Pfad unter Extras/Optionen/Datenbanken habe ich überall G als Datenpartition angegeben. Die Registrierung zeigt ebenfall auf G. Wo werden diese Verknüpfungen sonst noch festgehalten (Registry?)? Ich bin langsam verzweifelt. Wer hat Ideen? Oder muss ich auf MS Office zurück? Hast du schon geguckt, ob unter Systemsteuerung Verwaltung Datenquelle (ODBC) die Einträge richtig sind? Siehe auch http://www.ooowiki.de/MicrosoftAccess mfG Regina Hallo Regina, Ich habe kurz in das Procedere reingeschaut. Es scheint mir äusserst wirksam zu sein. D.h. ich muss die Datenbanken nochmals unter OOo neu erstellen. Ich glaube, dass das die Lösung ist. Ich bin jetzt eine Woche abwesend, werde aber nach meiner Rückkehr sofort an die Arbeit gehen. Und gebe dann Bericht. Vielen Dank für den guten Tip MfG Sergio - To unsubscribe, e-mail: users-unsubscr...@de.openoffice.org For additional commands, e-mail: users-h...@de.openoffice.org
[de-users] Re: Datenbank, intern: Filterung von Datensätzen
Hallo Joern, dein Problem interessiert mich, aber leider habe ich nur wenig Erfahrung mit Starbasic/OOBasic. Kannst du bitte das komplette Makro senden, dann versuche ich mit Stichworten zu googlen und eine Loesung zu finden. viele Gruesse Martin Jenniges martinjenni...@skynet.be Jörn Schwarz schrieb: ich habe ein kleines Problem bei der Filterung der Datensätze einer Adressdatenbank. Mit dem Befehl FilterName (A*') filtere ich alle Datensätze, deren Feld Name mit dem Buchstaben A beginnt. Das funktioniert einwandfrei (und für jeden Buchstaben habe ich mir ein Makro erstellt). Wenn das geschehen ist, kann ich mich allerdings mit den Navigationssymbolen nicht durch die gefilterten Datensätze bewegen. Das geht erst, wenn ich vorher in ein beliebiges Feld klicke. - To unsubscribe, e-mail: users-unsubscr...@de.openoffice.org For additional commands, e-mail: users-h...@de.openoffice.org
[de-users] Re: Datenbank: Werk eines Komponisten
Ernst Hügli schrieb: Das Werkzeug PHPmyAdmin bietet beim Anlegen einer Tabelle YEAR als Datentyp an - neben DATE, DATETIME, TIMESTAMP, TIME Selbstverständlich schreibe ich das nicht im Sinne von aber Ich berichte nur über diese Entdeckung. Das Interface von PHPmyAdmin zum Anlegen von Tabellen ist drastisch umfangreicher als jenes von Base. Ich habe mich ein bisschen schlau gemacht in dieser Sache. Obschon dieses Thema eigentlich abgehakt ist, komme ich nochmals darauf zurück, weil ich denke, man kann an diesem Beispiel wunderschön sehen, wie Design, Struktur und Implementation zusammenspielen müssen: Nach meinen Informationen kann man in einem mit PHPMyAdmin angelegten Feld vom Typ YEAR Jahrzahlen zwischen 1901 und 2155 ablegen. Was bedeutet das? Intern wird eine Zahl von genau 1 Byte Länge, also ein sog. TINY INTEGER gespeichert mit Werten zwischen 0 und 255 (= 2^8 - 1). Dies bedeutet: für die *Darstellung* am Bildschirm wird zum gespeicherten Wert einfach 1900 addiert (ich vermute mal, dass $ nicht benutzt wird). So weit so gut. Jetzt aber kommt die alles entscheidende Frage: wofür willst Du die Datenbank später einsetzen (können)? Und zusätzlich: will man Nutzern der DB im Jahr 2155 das Jahr-2155-Problem verschaffen? [...] Schlussfolgerung: obschon mit YEAR ein spezifischer Feldtyp für Jahre verfügbar ist, würde ich den Typ SMALL INTEGER (2 Byte, Werte zwischen 0 und 65'535) vorziehen. Sowohl der Mehrverbrauch an Speicher wie auch die reduzierte Performance fallen gegenüber der erhöhten Flexibilität in Deinem Anwendungsfall nicht ins Gewicht. Dafür musst Du im Gegenzu sicher eine noch zu definierende Gültigkeitsprüfung implementieren, damit nicht plötzlich Werte wie 21'456 oder ähnlich eingegeben werden - bei SMALL INTEGER würde das DB-System einen solchen Wert widerstandslos akzeptieren. Herzlichen Dank für die exzellente Darlegung der Zusammehänge, Ernst. Man kann Deine Schüler nur beglückwünschen, einen so kundigen und vor allem didaktisch begabten Lehrer für DB zu haben. In Deinen Unterricht würde ich mich gerne reinsetzen :) Das würde nicht nur mehr Freude bereiten als sich selbst in DB einzuarbeiten, es wäre auch ungleich effektiver. Schöne Grüße, Andreas -- OOo 3.1 http://borumat.de/openoffice-writer-tipps - To unsubscribe, e-mail: users-unsubscr...@de.openoffice.org For additional commands, e-mail: users-h...@de.openoffice.org
[de-users] Re: Datenbank: Werk eines Komponisten
Ernst Hügli schrieb: Erlaube mir ein paar allgemeine Bemerkungen zu Deinem Anliegen. Du hast zwei Probleme: zum einen will Dein Freund, der Komponist, ein Werkzeug, das ihm erlaubt, seine Werke zu katalogisieren. Zum anderen willst Du DB lernen. Tut mir leid, aber als einer, der selber Berufsmittelschüler u.a. auch in DB unterrichtet, muss ich Dir sagen: vergiss es, diese beiden Probleme in einem Aufwaschen lösen zu wollen! Du wirst scheitern. Wenn es so einfach wäre wie Du zu glauben scheinst, dann würden professionelle DB-Entwickler woll kaum ein FH- oder Uni-Studium benötigen. Kleiner Zwischenbericht, auch um zu unterstreichen, dass ich nie vermutet habe, dass es leicht werde, DB zu lernen, geschweige denn, dass es leicht werde, diese konkrete DB für meinen Freund zu /versuchen/ zu verwirklichen oder ich es mir leicht machen würde, indem ich die Komplexität der Wirklichkeit ausblende: Von Anfang an hatte ich meinen Freund über mehrere Wochen hin neutral und dezent gefragt, ob das nun wirklich alle Daten seien, die er mit seinem Werk in Verbindung bringen möchte - wenn er an die Zukunft denke, an Nachhaltigkeit. Da nach einiger Zeit nix mehr kam, habe ich mich auf kreative Suggestivfragen ;) verlegt. Bist Du sicher, dass Du nie Werke von Dir überarbeiten wirst und auch eine solche Variante dann bereitstellen möchtest? Hhmm, doch, ja. Wenn ich älter sein werde, kann das gut sein. Für mich heißt das, ich muss verstehen, wie man eine Historie perfekt in einer DB abbildet. 3. Normalform. Herausfordernd. So wie der meiste andere Grundlagenstoff auch, z.B. die Integritätsbedingungen. Gibt es verschollene Werke? Falls ja: möchtest Du dokumentieren, dass es sie gab? Hhmm. Stimmt. Gute Idee. Bei einigen Werken ist Dein Wunsch, dass der Musiker improvisiert. Daher kann es zu diesen Stücken keine genaue Angabe zur Dauer geben. Wie sind die Angaben zur Dauer überhaupt zu verstehen? Gibt es mehr als zwei verschiedene Typen dieser Angaben? Oder doch nur die beiden Angaben 'genau' und 'völlig unbestimmt'? Gibt es eventuell bei den Improvisationen 'Orientierungswerte'? Anders: was soll alles in die DB? Darüber muss ich nachdenken. Was bedeutet es genau, wenn ein Werk 'verschollen' ist? Kennst Du dann nur noch den Namen? Gibt es noch Fragmente der Noten? Kennst Du das Jahr der Fertigstellung? Das ist ganz verschieden. Gibt es Werke, wo Du mit der Komposition beginnst, sie dann mehrere Jahre lang reift und Du sie dann erst vollendest? Falls ja. Findest Du diese Information wichtig? Zweimal: ja. Bisher gibt es zu jedem Werksteil genau eine einziges Audio-Datei. Wird es nicht in Zukunft möglicherweise mehr als eine Interpretation eines Werksteiles geben, die Du dann auch in der Datenbank verzeichnen möchtest? Du hast Recht. Ich habe meinem Freund gezeigt, wie man Audio-Dateien mit MP3-Tags versieht. Es stellt sich also die Frage, wie und ob man die Inhalte der Tags mit der Werksdatenbank verknüpfen kann. Zu manchen Werken hast Du Kommentare verfasst. Manchmal hast Du einen weiteren Kommentar einige Jahre später verfasst. Betrachtest Du diese Kommentare als Deinem Werk zugehörig? Ja. Du willst Dich mit Deiner künftigen Website an Nutzer richten, die entweder Englisch oder Deutsch sprechen. Hast Du daher auch vor, Merkmale wie z.B. zur 'Gattung' in beiden Sprachen aufzuführen? Ja. Ich habe Dir erzählt, dass wir Deine Noten auch blinden Musikern zugänglich machen können. Dazu muss noch einiges geklärt werden. Dir gefällt die Idee gut. Gehe ich Recht in der Annahme, dass Du in der DB verzeichnen willst, ob es Versionen Deines Werkes gibt, die für Blinde geeignet sind? Richtig. Du willst Deine Noten auch denjenigen zugänglich machen, die über geringe oder keine finanzielle Mittel verfügen. Jeder Interessent soll selbst entscheiden, was er bereit zu geben ist. Dennoch willst Du einen Orientierungswert angeben. In diesen Wert sollen Aspekte einfließen wie 'Dauer Deiner Tätigkeit als Komponist', 'Aktuelles Jahr', 'Inflationsrate', 'Dauer des Werkes', 'Anzahl der Stimmen, begrenzt auf eine Maximum', ... Soll der noch zu entwickelnde vollständige Algorithmus ebenfalls in die DB integriert werden? Das wäre prima. ... Andreas PS: Falls zufällig ein Leser etwas zum Thema Noten für Blinde zugänglich machen weiß, freue ich mich über eine private Mail: boru...@gmx.de Spezielle Randbedingung: Der Komponist setzt das Notensatzprogramm Sibelius ein. Es kommen nur Verfahren in Frage, wo ein automatisierter Export in ein passende Format möglich ist. Der Komponist ist BTW mit dem Satzprogramm Sibelius sehr unzufrieden. Falls jemand Komponisten oder Musiker kennt, die ein quelloffenes, mächtiges und reifes Notensatzprogramm empfehlen können: sehr gerne. Lilypond hat er bereits entdeckt, aber noch nicht ausprobiert. -- OOo 3.1 http://borumat.de/openoffice-writer-tipps - To unsubscribe, e-mail: users-unsubscr...@de.openoffice.org For
[de-users] Re: Datenbank: Werk eines Komponisten
Andreas Borutta schrieb: PS: Falls zufällig ein Leser etwas zum Thema Noten für Blinde zugänglich machen weiß, freue ich mich über eine private Mail: boru...@gmx.de Wie ich erstaunt feststelle, wurde meine Mailadresse von der Listensoftware umgewandelt. Daher hier stattdessen ein Kontaktlink, auf der meine Adresse steht: http://borumat.de/kontakt Schließlich ist das Thema hier offtopic Andreas -- OOo 3.1 http://borumat.de/openoffice-writer-tipps - To unsubscribe, e-mail: users-unsubscr...@de.openoffice.org For additional commands, e-mail: users-h...@de.openoffice.org
[de-users] Re: Datenbank: Werk eines Komponisten
Ernst Hügli schrieb: [OT-Thema Notensatz-Software] Kennt er MuseScore? Nein, kennt er nicht. Danke, ich leite es weiter. Andreas -- OOo 3.1 http://borumat.de/openoffice-writer-tipps - To unsubscribe, e-mail: users-unsubscr...@de.openoffice.org For additional commands, e-mail: users-h...@de.openoffice.org
[de-users] Re: Datenbank: Werk eines Komponisten
Andreas Borutta wrote: Im Moment nutze ich nicht Linux, sondern Windows. Daher kommen Werkzeuge, die allein für Linux bereitstehen, nicht in Frage. Das ist ja kein (großes) Verbrechen. Gottseidank stehen alle relevanten Datenbanken von mysql über postgres bis zu diversen db2, oracle, MaxDB oder sogar ms-eigenen Varianten auch für Windows zur Verfügung. Ich werde quelloffene freie Werkzeuge vorziehen, die plattformübergreifend oder -unabhängig bereit stehen. da wirst Du voraussichtlich keinen Mangel leiden. Viele Grüße Eberhard - To unsubscribe, e-mail: users-unsubscr...@de.openoffice.org For additional commands, e-mail: users-h...@de.openoffice.org
[de-users] Re: Datenbank: Werk eines Komponisten
Andreas Saeger schrieb: Ich spreche hier nicht von Formularen, sondern direkt von der Tabelle. Wegen dieser unterschiedlichen Tabellen taugt hier eben ein Allround-Werkzeug wie Base nicht richtig, sondern es muss zur Erstellung dieser Tabellen besser auf eine spezielle MySQL-Basis zurückgegangen werden. Auch hier gehen sicher die Meinungen auseinander. Ich erstelle alle meine Datenbanken mit phpMyAdmin - und bin damit immer gut gefahren. OK. Dann lag ich also richtig mit meinem Verständnis des vorherigen Postings. Du musst in der Tat zwischen dem Entwurf und der Benutzung unterscheiden. Mit MySQLAdmin, phpAdmin, per Kommandozeile oder Gedankenübertragung erstellst Du ein Grundgerüst, nenne es Skelett oder Gefäß von mir aus. Analog wie man als Programmierer möglichst geeignete Tools benötigt, um Quellcode (Text) in etwas maschinenlesbares zu verwandeln. Den Kompilierer braucht der Endbenutzer nicht mehr. Wenn das Skelett erstmal durch Relationen (Gelenke) verbunden ist, und ein Benutzer seine Daten (Fleisch) hinzugefügt hat und die Haut(Oberfläche) auch auf bestimmte Gegebenheiten zugeschnitten ist, dann kann das Skelett ohne größere Operationen nicht verändert werden, bestenfalls erweitert. Eine fertige Datenbank enthält keinerlei Daten, sondern ein Gerüst aus Abhängigkeiten und Gültigkeitsregeln, in welche dann gewünschte Daten eingegeben werden können wärend ungültige, unzusammenhängende oder unvollständige Daten zurückgewiesen werden. Auf diese Weise wird ein Benutzer die Datenbank auch niemals speichern müssen. Jeder gültige Datensatz (vereinfacht: Tabellenzeile) wird direkt auf die Platte geschrieben. Eine Datenbank hat wesentlich mehr Gemeinsamkeiten mit einem Dateisystem als mit einer Datei. Ein Aspekt einer Datenbank ist, dass sie es verunmöglichen soll, dass Du z.B. ein neues Musikstück ohne Komponisten eingibst. Die Zeile für das Musikstück wird einfach nicht auf die Platte geschrieben, Fehlermeldung, Basta. Dafür musst Du nichts programmieren. Das ist durch die Tabelleneigenschaften so. Nicht eine einzige dieser Eigenschaften würdest Du in einer Tabellenkalkulation wiederfinden, eine geänderte Zeile wird dort auch nicht direkt auf die Platte geschrieben. Dort würdest Du z.B. mit Formeln und Makros permanent überprüfen, ob alles da ist =WENN(UND(A10;B10);A1/B1;) und dergleichen Schwachsinn mehr. [...] Danke und Kompliment für diese sehr gut geschriebene Verdeutlichung des Wesens von DBs und ihrer Wesensunterschiede zur Tabellenkalkulation. Der Einstieg in das Thema DB macht mir übrigends zunehmend Freude. Heute werde ich mir Literatur beschaffen :) Falls ihr also noch Literatur empfehlen möchtet: gerne. Ernst war ja schon so freundlich. Andreas -- OOo 3.1 http://borumat.de/openoffice-writer-tipps - To unsubscribe, e-mail: users-unsubscr...@de.openoffice.org For additional commands, e-mail: users-h...@de.openoffice.org
Re: [de-users] Re: Datenbank: Werk eines Komponisten
Hallo Ernst und alle anderen ... Ernst Hügli schrieb: ... Wenn er aber mal 09 oder gar nur 9, ein ander Mal aber 1992 eingibt, dann kommt die DB damit nicht klar. das kann man aber über constraints (Bedingungen) lösen, nicht unbedingt 4-stellig, bzw. integrierten Korrekturen (habe dazu gerade kein Beispiel, kann aber meist über die interne Programmiersprache der DB erledigt werden, Stichwort: stored procedures) CREATE TABLE Tabelle ( ... Beginn DATE; Ende DATE; CHECK (Ende Beginn) ); Wie in diesem Thread schon mehrfach betont: der Design - und da empfehle ich meinen Schülern auch: Bleistift und Papier, allenfalls die Textverarbeitung oder ein Zeichnungsprogramm à la Draw oder Visio - ist das Alpha und Omega einer guten Datenbank-Applikation. Dazu gehört auch eine sorgfältige Überlegung, welchen Datentyp ein Feld denn aufnehmen soll. es gibt aber auch grafische Tools hierfür, Stichworte UML, entity relationship (o.ä.) PS. Bezüglich der erbetenen Literaturangaben zum Thema DB werde ich mich später noch melden. Nun, mit Literatur ist das immer so eine Sache. Was dem einen zusagt, muss dem anderen überhaupt nicht zusagen. ... Zum Glück kann man heute oftmals im Internet Teile eines Buches Probe lesen, bevor man es kauft. auch eine gut sortierte Buchhandlung kann ich empfehlen. Sofern das betreffende Buch dort vorhanden ist, kannst Du es in Ruhe lesen ... Ich habe noch nie erlebt, daß ich bei Hugendubel, Lehmans, ... angesprochen wurde ... auch wenn ich ein Buch über eine Stunde gelesen habe! MfG Günter - To unsubscribe, e-mail: users-unsubscr...@de.openoffice.org For additional commands, e-mail: users-h...@de.openoffice.org
Re: [de-users] Re: Datenbank: Werk eines Komponisten
Hallo Guenter Guenter Wallnig schrieb: Wie in diesem Thread schon mehrfach betont: der Design - und da empfehle ich meinen Schülern auch: Bleistift und Papier, allenfalls die Textverarbeitung oder ein Zeichnungsprogramm à la Draw oder Visio - ist das Alpha und Omega einer guten Datenbank-Applikation. Dazu gehört auch eine sorgfältige Überlegung, welchen Datentyp ein Feld denn aufnehmen soll. es gibt aber auch grafische Tools hierfür, Stichworte UML, entity relationship (o.ä.) Selbstverständlich gibt es diese Tools - die Frage ist bloss: soll ich - wenn ich nur gelegentlich mal eine DB selber entwerfen - mich dafür in ein weiteres Tool einarbeiten, das trotz GUI i.d.R. nicht trivial zu bedienen ist? Ich halte es da eher mit der altmodischen Variante: Einsteiger und Gelegenheits-Entwickler sollen zunächst einmal die Theorie verstehen lernen und ihre Entwürfe mit Papier (Flipchart-Bögen sind empfehlenswert) und Farbstift erarbeiten, dann können sie bei Bedarf immer noch weitere Tools anschaffen. Als Neuling im Bergsteigen wage ich mich wohl auch kaum als erstes an die Eigernordwand - u.a. auch darum, weil dafür der gleichzeitige Einsatz mehrerer Tools notwendig ist. Das ist erfahrenen Bergsteigern vorbehalten. Aber vielleicht ist das auch die spezifische Sicht eines Lehrers, der den Ehrgeiz hat, seinen Schülern beizubringen, dass sie wissen, was sie tun, und nicht wie hirnlose Roboter einfach ein paar Tasten drücken können O:-) . Denn eins bleibt gerade in diesem Zusammenhang der DB-Entwicklung immer wieder zu beachten: A fool with a tool is still a fool! :-X Freundlich grüsst Ernst - To unsubscribe, e-mail: users-unsubscr...@de.openoffice.org For additional commands, e-mail: users-h...@de.openoffice.org
[de-users] Re: Datenbank: Werk eines Komponisten
Jörg Schmidt schrieb: [...] Du mußt an der Stelle auch die Zusammenhänge von Werten, Formatierungen und 'Eingabeautomatisierungen' verstehen lernen. Beispielsweise gibt es aus Sicht der Tabellenkalkulation keine 'allgemeinen' Zeiten, woraus leicht Mißverständnisse und Fehler erwachsen können. Wenn Du in eine Zelle 12:00 schreibst und das dann normal (ohne STRG) 'runterziehst' steht optisch in allen Zellen 12:00:00, der Zellwert der Zellen, mit dem gerechnet wird, ist jedoch keineswegs für alle diese Zellen gleich ... Danke für Deine Hinweise, Jörg. Ja, so langsam lerne ich Schein und Sein immer besser auseinander zuhalten. Andreas -- OOo 3.1 http://borumat.de/openoffice-writer-tipps - To unsubscribe, e-mail: users-unsubscr...@de.openoffice.org For additional commands, e-mail: users-h...@de.openoffice.org
[de-users] Re: Datenbank: Werk eines Komponisten
Andreas Saeger schrieb: Na, dann haben wir ja schon mal MySQL as Backend. Damit habe ich ein kleines bisschen Erfahrung. Das Ding ist wohl sowas wie der VW Golf unter den Datenbanken. Das einzige wesentlich bessere Frontend, über das ich wirklich Auskunft geben könnte wäre MS Access. Lassen wir das einmal beiseite (ja, mit MS Access kann ebenfalls hervorragend Nicht-Access Datenbanken bedienen). Was Du mit Base niemals machen darfst: Benutze Base nie, um den Aufbau einer MySQL-Datenbank zu verändern! Mist. Wenn ich Dich richtig verstehe, wäre für meine mittelfristigen Ziele das passende Backend MySQL. Aber wenn man dessen Aufbau mit Base nicht verändern kann, scheidet Base als Frontend aus. Sehr schade. Also bleibt mir als Tool zum Verwalten allein PHPmyAdmin? Was ich aber eigentlich die ganze Zeit sagen wollte: Ein Bogen Papier mit Buntstiften ist meiner Meinung nach das wichtigste Tool weil Datenbanktabellen nur schwer zu verändern sind sobald sie einmal Daten enthalten und/oder Beziehungen zu anderen Tabellen. Ich gestehe, dass ich darüber erstaunt bin. Ich dachte, die Relationen seien durch die eindeutigen Namen Tabellenname.Datenfeldname und durch die IDs robust. Sozusagen wie in Calc relative Referenzierung. Dort geht ja auch eine Tabelle nicht kaputt, wenn Zeilen oder Spalten eingefügt werden. Aber gut, es wird seine Gründe haben, die ich noch einsehen werde. Doch, es ist möglich, Felder einzufügen. Nur bietet Base das nicht in seiner GUI an. menu:ExtrasSQL... ALTER TABLE Tabelle ADD COLUMN Feld X VARCHAR(32) BEFORE Feld Y Prima. Klappte einwandfrei. Neustart von Base war nötig. menu:ExtrasSQL... ist die Kommandozeile zum Datenbank-Backend. Über diese Kommandozeile klappts dann auch mit MySQL wie mit jeder anderen Kommandozeile auch. OK. Mit der Sprache muss ich mich eh beschäftigen. Da Du als Verfahren die Kommandozeile erwähnst, nehme ich an, dass der Quellcode eines Tabellenentwurfes nicht in Form einer Textdatei editierbar ist, oder? Andreas -- OOo 3.1 http://borumat.de/openoffice-writer-tipps - To unsubscribe, e-mail: users-unsubscr...@de.openoffice.org For additional commands, e-mail: users-h...@de.openoffice.org
Re: [de-users] Re: Datenbank: Werk eines Komponisten
Hallo Andreas Andreas Borutta schrieb: ... Na, dann haben wir ja schon mal MySQL as Backend. da ebenfalls OpenSource und eine große aktive Community, ist das eine gute Wahl! Also bleibt mir als Tool zum Verwalten allein PHPmyAdmin? nein, wie Du ja auch dem vorherigen posting entnehmen kannst und hier ... Doch, es ist möglich, Felder einzufügen. Nur bietet Base das nicht in seiner GUI an. ... menu:ExtrasSQL... ist die Kommandozeile zum Datenbank-Backend. Über diese Kommandozeile klappts dann auch mit MySQL wie mit jeder anderen Kommandozeile auch. diese Kommandozeile ist nichts anderes als ein Fenster in die Edit-Ebene von beispielsweise /usr/bin/mysql (unter Linux) Das Kommando in einer Shell (auch mit Putty unter Windows zum Linux-Rechner mit der MySQL-DB) mysql -h $HOST -D $DATABASE -u $USER -p öffnet Dir einen prompt zur Bearbeitung der DB (natürlich mit den entsprechend eingerichteten Berechtigungen) mysql help For the complete MySQL Manual online visit: http://www.mysql.com/documentation For info on technical support from MySQL developers visit: http://www.mysql.com/support For info on MySQL books, utilities, consultants, etc. visit: http://www.mysql.com/portal List of all MySQL commands: (Commands must appear first on line and end with ';') ... OK. Mit der Sprache muss ich mich eh beschäftigen. ich wiederhole nochmal aus meinen früheren Beitrag: In der c't 09/2003, ab S. 234 steht ein guter Artikel über Datenbanken Datenschule. Mit SQL zur eigenen Datenbank von Hajo Schulz Da Du als Verfahren die Kommandozeile erwähnst, nehme ich an, dass der Quellcode eines Tabellenentwurfes nicht in Form einer Textdatei editierbar ist, oder? Weil die MySQL-DB ja eigenständig ist (Base ist ja nur die GUI), kannst Du *sehr viel* mit den Tools für MySQL machen ... So erstellst Du mit einem Dump der DB eine editierbare ASCII-Datei, die *alle* Befehle zum Erstellen der DB enthält ... auf Wunsch sogar mit Benutzern und Passwörtern. Außerdem wählbar: nur Struktur oder Struktur mit Daten ... Dieser Dump ist eine gute Backup-Möglichkeit. Er kann auch zum Erstellen der DB auf einem anderen Rechner dienen. MfG Günter - To unsubscribe, e-mail: users-unsubscr...@de.openoffice.org For additional commands, e-mail: users-h...@de.openoffice.org
[de-users] Re: Datenbank: Werk eines Komponisten
Ernst Hügli schrieb: Die Ursache könnte tatsächlich in Calc liegen. Die Jahreszahlen habe ich in unformatierte Zellen eingegeben. Calc konnte sie also nur als vier Ziffern werten und nicht als Datumsangabe. Aber auch wenn man in Calc eine Zelle zuerst als Datum formatiert und danach einen Wert wie 1905 eingibt, interpretiert Calc das als 1905. In Jörg Schmidts Buch habe ich zu Typ auf Seite 315 nur 6 Typen gefunden: Zahl, Text, Wahrheitswert, Formel, Fehlerwert, Matrix Datum oder Zeit scheint es als Typ nicht zu geben. Calc bildet sie offenbar als Zahl ab. Ich verstehe Dein Problem nicht: als Datentyp gibt es weder in einer Tabellenkalkulation noch in der Kalenderrechnung noch in der Mathematik: das ist eine reine Zahl, und genau so interpretiert Calc auch Deine Eingabe. [Erklärung] Danke. Daraus folgt, dass eine Formatangabe , wie Robert sie zuerst in Base vorgenommen hatte, scheitern muss, weil es eben keinen Datentyp Jahreszahl gibt. Die aktuelle Feldeigenschaft Vierstellige Ganzzahl ist also genau richtig. PS. Bezüglich der erbetenen Literaturangaben zum Thema DB werde ich mich später noch melden. Prima :) Andreas -- OOo 3.1 http://borumat.de/openoffice-writer-tipps - To unsubscribe, e-mail: users-unsubscr...@de.openoffice.org For additional commands, e-mail: users-h...@de.openoffice.org
Re: [de-users] Re: Datenbank: Werk eines Komponisten
Hallo Andreas Andreas Borutta schrieb: Danke. Daraus folgt, dass eine Formatangabe , wie Robert sie zuerst in Base vorgenommen hatte, scheitern muss, weil es eben keinen Datentyp Jahreszahl gibt. Die aktuelle Feldeigenschaft Vierstellige Ganzzahl ist also genau richtig. Richtig. Wichtiger scheint mir aber - denn die Definition des Typs bleibt dem User in einer gut designten [! furchtbares Wort] DB verborgen - dass Du ihn zwingst, 4 Ziffern einzugeben. In Deiner Anwendung sind Jahrzahlen aus dem Mittelalter oder gar Altertum doch wohl unwahrscheinlich. Wenn er aber mal 09 oder gar nur 9, ein ander Mal aber 1992 eingibt, dann kommt die DB damit nicht klar. Das will heissen: sortieren, selektieren u.ä. wird mit solchen Daten extrem schwierig. Wie in diesem Thread schon mehrfach betont: der Design - und da empfehle ich meinen Schülern auch: Bleistift und Papier, allenfalls die Textverarbeitung oder ein Zeichnungsprogramm à la Draw oder Visio - ist das Alpha und Omega einer guten Datenbank-Applikation. Dazu gehört auch eine sorgfältige Überlegung, welchen Datentyp ein Feld denn aufnehmen soll. Und auch das kann ich nur betonen und wiederholen: sind in einer DB mal Daten drin, dann ist eine Änderung der *Struktur* oft - wenn überhaupt! - nur mit weitreichenden Konsequenzen machbar. Das Ganze wird schnell zu einem Murcks. Darum: Gehirn einschalten - denken - zeichnen - hin und her überlegen - korrigieren - realisieren - testen - Testdaten löschen - ggf. Struktur nochmals anpassen, und erst nach dieser langen Zeit produktive Daten eingeben. PS. Bezüglich der erbetenen Literaturangaben zum Thema DB werde ich mich später noch melden. Nun, mit Literatur ist das immer so eine Sache. Was dem einen zusagt, muss dem anderen überhaupt nicht zusagen. Was für den Einsatz im Klassenverband geeignet ist, taugt nicht für den Selbstunterricht, usw. usf. Nimm also diese Empfehlungen mit der nötigen Sorgfalt auf. Zum Glück kann man heute oftmals im Internet Teile eines Buches Probe lesen, bevor man es kauft. Suche also auch aktiv nach Literatur, die für Dich passt. Ich gebe Dir zwei Bücher an, die sich aus meiner Sicht [!] für Dein Anliegen - in DB im allgemeinen und in Base im besonderen einzusteigen - bewährt haben: Hölscher Lorenz; Richtig einsteigen: Datenbanken entwickeln mit Access 2007; Microsoft Press Deutschland; ISBN 978-3-86645-203-9; €24.90 Krumbein Thomas; Datenbanken mit OpenOffice.org 3; Galileo Computing Bonn; ISBN 978-3-8362-1301-1; €39.90 Zu den beiden Büchern: das erste Buch ist zwar von der Konkurrenz, was bedeutet, dass Du die Beispiele nicht immer 1:1 übertragen kannst. Doch bei aller Kritik an MS: die können auch gute Bücher schreiben. Da wir in der Schule mit den MS-Produkten arbeiten, gehe ich nach diesem Buch vor. Was mir besonders gut gefällt ist gerade der Teil, der hier im Thread so ausgiebig breitgewalzt wird: der Design, die zugrunde liegenden DB-Strukturen, die Normalisierung sind m.E. mit der nötigen Sorgfalt, aber nicht theoretisch, behandelt (und darum empfehle ich Dir dieses Buch). Nicht zu vergessen ein Punkt, der auch schon verschiedentlich angesprochen wurde: wie sollen Tabellen, Abfragen, Formulare und Berichte, aber auch DB-Felder, sinnvoll benannt werden? Der Autor hat hier m.E. einen sehr guten, stilsicheren Ansatz vorzuweisen. Das Buch von Thomas Krumbein hat Volker schon kurz erwähnt - m.E. unverzichtbar, wenn man seriös in Base einsteigen will. Also, wie gesagt: jeder hat seine Vorlieben. Ich halte es auch so, dass ich aus einem Buch das herauspicke, was mir zusagt - den Rest überlese ich geflissentlich. Ich empfehle Dir diese Bücher in diesem Sinne. Freundlich grüsst aus der regnerischen Schweiz Ernst - To unsubscribe, e-mail: users-unsubscr...@de.openoffice.org For additional commands, e-mail: users-h...@de.openoffice.org
Re: [de-users] Re: Datenbank: Werk eines Komponisten
Hallo Andreas Andreas Borutta schrieb: Bitte gehe auf die von mir genannten Argumente ein, wo ich schreibe, dass ich keinen guten Grund sehe, bewußt eine für menschliche Verwalter (ich schrieb explizit nicht von Anwendern) schlechter lesbare (Benennungen, Reihenfolge) und somit schlechter wartbare Struktur anzulegen. Auf diese Deine Aussage bin ich bis jetzt noch nicht eingegangen und will das gerne nachholen: Es kann keine Rede davon sein, eine (...) schlechter wartbare Struktur anzulegen. Die Aussage lautete ganz anders: die Benennung von Feldern und ihre Reihenfolge in der Tabelle ist für das Funktionieren der DB absolut belanglos - das war sinngemäss der Inhalt der Aussage. Dazu folgende Bemerkungen: * Eine klar gegliederte Struktur kann nie schaden - doch darf diese Gliederung (im Sinne von: Reihenfolge der DB-Felder) nicht überbewertet werden. Aus zwei Gründen: erstens sieht der User nie die Tabellen, denn er wäre - wie ich schon verschiedentlich betont habe - bei einer gut gemachten DB-Applikation überfordert: da müsste er sich mit mehreren Tabellen herum schlagen, müsste Primärschlüsselwerte auslesen und sie als Sekundärschlüsselwerte in anderen Tabellen einfügen, und derlei Spässe mehr. Dafür bietet ein DB-System die Formulare (im wesentlichen für die Eingabe) und die Reports (im wesentlichen für die Ausgabe). In diesen Objekten zerschiesst man bewusst die schön aufgebaute Struktur, damit der User versteht, was er eingeben soll oder was bekommen kann. Die Gliederung der Felder kann völlig anders sein als in den Tabellen. Es liegt am Entwickler, das Ganze im Hintergrund wieder auseinander zu bröseln. Zweitens: was ist denn eine gut lesbare Struktur? Das ist kein objektives Kriterium. Nimm als ganz einfaches Beispiel einen Adressdatensatz: Amerikaner und Engländer setzen die PLZ (dort Zip genannt) ganz anders als wir in Zentraleuropa. Oder die Russen: ihre Adressstruktur ist völlig auf den Kopf gestellt und damit für uns sehr gewöhnungsbedürftig: zuoberst wird das Land angegeben, dann die PLZ und die Stadt, auf der nächsten Zeile die Adresse, und zuunterst der Name des Empfängers - auch eine Logik, aber aus unserer Sicht wie gesagt sehr gewöhnungsbedürftig. Das ergäbe in einer Adress-DB eine völlig andere Struktur als bei uns. Was ist nun eine gut lesbare und damit wartbare Struktur? Doch eine sehr subjektive Angelegenheit. Dazu ein Beispiel: nimm eine Adress-DB. Die Normalisierung verlangt mindestens zwei Tabellen: eine mit den personenbezogenen Angaben (Name, Vorname, Adresse, Telefonnummern, ..., sowie den Sekundärschlüssel auf die Ortstabelle) und eine für den Ort (PLZ, Ortsname, evtl. Stadtteil). Was ist jetzt die richtige Struktur? Hängt doch sehr vom Anwendungsfall ab: für Adressetiketten ist eine andere Reihenfolge sinnvoll als für ein Mitgliederverzeichnis. Trotz dieses Einwandes spricht nichts dagegen, sich auch die Reihenfolge gut zu überlegen und für eine logisch erscheinende (das ist subjektiv, nicht objektiv) Reihenfolge zu entscheiden. Gerade weil ein nachträgliches Einschieben nicht ohne weiteres möglich ist, muss ich aber im Sinne der Aufwandminimierung auch akzeptieren, dass in der Testphase noch Änderungen auftreten, die diese Struktur zerschiessen. Beispiel: ich habe mich ursprünglich dafür entschieden, PLZ und Ort im gleichen Feld zu erfassen (warum auch immer - es geht ums Prinzip). Nun zeigt aber die Testphase, dass ich sie doch auseinander nehmen muss. Dann habe ich in der Tabelle nicht die übliche Struktur PLZ - Ort(sname). Für die Leistungsfähigkeit der DB-Applikation ist das belanglos. Wichtiger scheint mir da, in der Entwurfsansicht nicht nur die Spalten Feldname und Feldtyp zu beachten, sondern ganz speziell die dritte Spalte Beschreibung: hier soll man Hinweise auf Bedeutung und Zusammenhänge der Felder notieren. * Was sind gut lesbare Feldnamen? Der Entwickler wird darunter etwas Anderes verstehen als der User. Name ist Schall und Rauch ist man mit Johnny Goethe versucht zu sagen - solange der Entwickler mit seiner eigenen Namensgebung klar kommt. Dem Entwickler ist es i.a. wichtiger, über die Namen einen Hinweis auf die Struktur zu erhalten: zu welcher Tabelle gehört ein Feld? Hat es eine spezielle Aufgabe (z.B. Sekundärschlüssel), und auf welche Tabelle referenziert es in diesem Fall? Das von mir empfohlene Buch von Hölscher schlägt diesbezüglich eine aus User-Sicht ungewohnte, aus Entwicklersicht aber sehr sinnvolle Konvention vor. In den User-Interfaces - sprich Formularen und Berichten - sollte das Ganze aber im Klartext, möglichst in epischer Breite, daher kommen, damit der User klar weiss, worum es geht. Fazit: ich bin der letzte, der der Schludrigkeit das Wort redet - aber die Ansicht, was eine gut lesbare und wartbare Struktur sei,
[de-users] Re: Datenbank: Werk eines Komponisten
Ernst Hügli schrieb: Ich verstehe Dein Problem nicht: als Datentyp gibt es weder in einer Tabellenkalkulation noch in der Kalenderrechnung noch in der Mathematik: Das Werkzeug PHPmyAdmin bietet beim Anlegen einer Tabelle YEAR als Datentyp an - neben DATE, DATETIME, TIMESTAMP, TIME Selbstverständlich schreibe ich das nicht im Sinne von aber Ich berichte nur über diese Entdeckung. Das Interface von PHPmyAdmin zum Anlegen von Tabellen ist drastisch umfangreicher als jenes von Base. Andreas -- OOo 3.1 http://borumat.de/openoffice-writer-tipps - To unsubscribe, e-mail: users-unsubscr...@de.openoffice.org For additional commands, e-mail: users-h...@de.openoffice.org
[de-users] Re: Datenbank: Werk eines Komponisten
Andreas Borutta wrote: Nehmen wir an, solche Tabellentypen wären ausserhalb von Base erstellt worden. Weil Du oben den schreibenden Zugriff erwähnst: man kann z.B. innerhalb der Base-GUI eine solche Tabelle öffnen und einen Datensatz unten einpflegen? Ich spreche hier nicht von Formularen, sondern direkt von der Tabelle. Wegen dieser unterschiedlichen Tabellen taugt hier eben ein Allround-Werkzeug wie Base nicht richtig, sondern es muss zur Erstellung dieser Tabellen besser auf eine spezielle MySQL-Basis zurückgegangen werden. Auch hier gehen sicher die Meinungen auseinander. Ich erstelle alle meine Datenbanken mit phpMyAdmin - und bin damit immer gut gefahren. OK. Dann lag ich also richtig mit meinem Verständnis des vorherigen Postings. Andreas Du musst in der Tat zwischen dem Entwurf und der Benutzung unterscheiden. Mit MySQLAdmin, phpAdmin, per Kommandozeile oder Gedankenübertragung erstellst Du ein Grundgerüst, nenne es Skelett oder Gefäß von mir aus. Analog wie man als Programmierer möglichst geeignete Tools benötigt, um Quellcode (Text) in etwas maschinenlesbares zu verwandeln. Den Kompilierer braucht der Endbenutzer nicht mehr. Wenn das Skelett erstmal durch Relationen (Gelenke) verbunden ist, und ein Benutzer seine Daten (Fleisch) hinzugefügt hat und die Haut(Oberfläche) auch auf bestimmte Gegebenheiten zugeschnitten ist, dann kann das Skelett ohne größere Operationen nicht verändert werden, bestenfalls erweitert. Eine fertige Datenbank enthält keinerlei Daten, sondern ein Gerüst aus Abhängigkeiten und Gültigkeitsregeln, in welche dann gewünschte Daten eingegeben werden können wärend ungültige, unzusammenhängende oder unvollständige Daten zurückgewiesen werden. Auf diese Weise wird ein Benutzer die Datenbank auch niemals speichern müssen. Jeder gültige Datensatz (vereinfacht: Tabellenzeile) wird direkt auf die Platte geschrieben. Eine Datenbank hat wesentlich mehr Gemeinsamkeiten mit einem Dateisystem als mit einer Datei. Ein Aspekt einer Datenbank ist, dass sie es verunmöglichen soll, dass Du z.B. ein neues Musikstück ohne Komponisten eingibst. Die Zeile für das Musikstück wird einfach nicht auf die Platte geschrieben, Fehlermeldung, Basta. Dafür musst Du nichts programmieren. Das ist durch die Tabelleneigenschaften so. Nicht eine einzige dieser Eigenschaften würdest Du in einer Tabellenkalkulation wiederfinden, eine geänderte Zeile wird dort auch nicht direkt auf die Platte geschrieben. Dort würdest Du z.B. mit Formeln und Makros permanent überprüfen, ob alles da ist =WENN(UND(A10;B10);A1/B1;) und dergleichen Schwachsinn mehr. Kann der Benutzer den Komponisten nicht im Formular auswählen, dann muss er wohl erstmal die entsprechende Zeile für die Person in einer andere Tabelle anlegen und dann das Stück hinzufügen. Wenn die Person kein Geburtsdatum hat, Du aber das Datum als erforderlich festgelegt hast, um nach Epochen klassifizieren und sortieren zu können, dann muss der Benutzer wohl erstmal googeln bevor die Datenbank die neue Komponistenzeile akzeptiert und dann ein neues Stück dieses Menschen eingegeben werden kann. Die Tabellen selbst und was in welcher Tabelle steht und wie das alles zusammenhängt ist völlig unsichtbar für den Endbenutzer. Du würdest wohl auch nicht die 2 Dutzend Relationen verstehen, die die Bestellung eines Buches bei Amazon ausmachen, aber das Bestellen mittels des Formulars klappt trotzdem. Wir wissen nicht, welche Datenbank und welche Entwichlungswerkzeuge bei Amazon verwendet werden. Das Frontend wird als HTML an Deinen Browser ausgeliefert. Es ist völlich wumpe, womit Du Deine Relationen und Datentypen festgelegt hast. Danach können Menschen mit derselben Datenbank mittels HTML-Formular, Base-Formularen, und völlig anderen Programmen interagieren. Du könntest sogar festlegen, wer von welcher Maschine aus was lesen, was editieren, was löschen und was hinzufügen darf und dass ohne Autentifizierung immer noch der Lesezugriff auf öffentliche Datensätze über ein Web-Formular möglich ist. - To unsubscribe, e-mail: users-unsubscr...@de.openoffice.org For additional commands, e-mail: users-h...@de.openoffice.org
[de-users] Re: Datenbank: Werk eines Komponisten
Na, dann haben wir ja schon mal MySQL as Backend. Damit habe ich ein kleines bisschen Erfahrung. Das Ding ist wohl sowas wie der VW Golf unter den Datenbanken. Das einzige wesentlich bessere Frontend, über das ich wirklich Auskunft geben könnte wäre MS Access. Lassen wir das einmal beiseite (ja, mit MS Access kann ebenfalls hervorragend Nicht-Access Datenbanken bedienen). Was Du mit Base niemals machen darfst: Benutze Base nie, um den Aufbau einer MySQL-Datenbank zu verändern! Das hat schon Datenbanken ruiniert. Relationenfenster und Tabellenentwurf sind als read-only zu betrachten, selbst wenn Base anbietet, damit zu arbeiten. Ausnahmen sind die beiden Datenbanktypen, die Du in Base auch neu erstellen kannst: HSQLDB und dBase. MySQL-Backends werden mit MySQL-Tools erstellt. Das Nachprogrammieren in Base-Frontends betrifft überwiegend Formulare. Formulare dienen der komfortablen Eingabe von Daten und viele Benutzer erwarten zurecht komfortable, vordefinierte Filter in Datenbankformularen. Für das Filtern von Formulardaten gibt es zwar mannigfaltige Möglichkeiten, die aber so merkwürding zu implementieren sind, dass viele Leute zusäztlichen Basic-Code in Kauf nehmen, der bis einschl. v3.1 auch noch separat installiert werden musste. Ja, so ist das. Reports dienen der formatierten Ausgabe. Sun's Report Builder (Erweiterung) lässt auch ohne Makros kaum wünsche offen. Persönlich reichen mir formatierte Calc-Tabellen und Datenpiloten. Dann gibt es immer noch so leidige Probleme wie das Öffnen von Formularen und Reports ohne jedesmal ins Datenbankfenster zu wechseln, also z.B. eine Schltfläche auf einem Formular, welches ein anderes Objekt öffnet. Dafür gibt es nun ebenfalls ein separates Add-On, welches ich persönlich nie benutze, weil mir das Datenbankfenster einfach gut genug ist (und weil das Ding suboptimal programmiert ist). Was ich aber eigentlich die ganze Zeit sagen wollte: Ein Bogen Papier mit Buntstiften ist meiner Meinung nach das wichtigste Tool weil Datenbanktabellen nur schwer zu verändern sind sobald sie einmal Daten enthalten und/oder Beziehungen zu anderen Tabellen. Formulare und Reports sind auch sehr schwer zu debuggen, wenn die zugrundeliegende Datenbank sich geändert hat. Doch, es ist möglich, Felder einzufügen. Nur bietet Base das nicht in seiner GUI an. menu:ExtrasSQL... ALTER TABLE Tabelle ADD COLUMN Feld X VARCHAR(32) BEFORE Feld Y menu:ExtrasSQL... ist die Kommandozeile zum Datenbank-Backend. Über diese Kommandozeile klappts dann auch mit MySQL wie mit jeder anderen Kommandozeile auch. - To unsubscribe, e-mail: users-unsubscr...@de.openoffice.org For additional commands, e-mail: users-h...@de.openoffice.org
Re: [de-users] Re: Datenbank: Werk eines Komponisten
Hallo Am Sonntag, 14. Juni 2009 schrieb Andreas Borutta: snip Darauf möchte ich mich im Moment auch konzentrieren. Formulare kommen dann in der zweiten Phase. Der Datenbankentwurf ist das A und O des ganzen. Wenn das nicht stimmt, kannst du mit Formularen nichts mehr retten. Erstmal muss mir klar werden, mit welcher Struktur das Werk eines Komponisten am besten abgebildet wird. Mir geht es dabei um Langlebigkeit, um Nachhaltigkeit. Auch hier wieder: Datenbankentwurf. Wenn das Ganze gut wird, möchte ich die Datenbank auch anderen Komponisten zur freien Nutzung bereitstellen. Die in der Rohdatentabelle aufgeführten Merkmale gelten für beliebige Kompositionen von Komponisten für neue Musik, sagte mir mein Freund. Da musst du dir aber absolut sicher sein, dass das so ist. Das ganze lieber dreimal hinterfragen. snip Dennoch finde ich, dass es der Nachhaltigkeit dient, wenn die Datenfelder der Tabelle in einer sinnvollen Reihenfolge stehen und sprechende Namen tragen. Das kann, muss aber nicht so sein. Jede zusätzlich Schicht erhöht die Komplexität und erschwert die Wartung. Ohne Not, denke ich, sollte man eine solche Schicht hinzufügen. Spätestens hier wird es notwendig auf ein paar Konzept hin zu weisen: ACID, Trennung der Daten von den Sichten, Normalformen, Transaktion usw. Ich denke du kommst um ein bischen Theorie zu Datenbanken nicht herum. Aber offenbar kann man in Base Datenfelder nachträglich nicht in der Reihenfolge ändern oder mittendrin ein neues Datenfeld einfügen. Das sollte in allen Datenbanken tunlichst unterbleiben. Ich bin kein Datenbankentwerfer, arbeite aber täglich in der Programmierung von und mit Datenbanken in der Verwaltung von Technischen Dokumenten. Das ganze ist nicht trivial. -- Mit freundlichen Grüßen Matthias Müller (Benutzer #439779 im Linux-Counter http://counter.li.org) PS: Bitte senden Sie als Antwort auf meine E-Mails reine Text-Nachrichten! signature.asc Description: This is a digitally signed message part.
[de-users] Re: Datenbank: Werk eines Komponisten
Ernst Hügli schrieb: Hallo Ernst, zunächst mal vorab: ich schätze es ausdrücklich, wenn jemand, wie Du es hier getan hast, mir gegenüber Tacheles redet. Erlaube mir bitte im Gegenzug einige Bemerkungen. Du wirst hier im Thread keine Aussagen vor mir finden, wo ich glauben machen möchte, ich habe keinen Respekt vor dem Aufsetzen einer Datenbank. Das Gegenteil ist der Fall. Mein Respekt war die ganzen letzten Jahre so groß, dass ich nicht mal erwogen habe, sowas anzugehen. Die unbefriedigenden Merkmale der Tabelle, mit der ich versucht habe, meinem Freund das Erfassen leichter/bzw. überhaupt möglich zu machen, in Verbindung mit dem Hinweis einiger hier denk' mal über eine Datenbanklösung nach, ließen mich neugierig werden. Schlechter als mit der aktuellen Calc-Tabelle, dachte ich mir, könne es schon nicht werden. Meine erste Vorstellung war eine rudimentäre Datenbank, die nur aus einer einzigen Tabelle besteht und weder Formular noch Bericht aufweist. Einfach nur ein Container mit viel strikteren Regeln (Datentypen, Feldeigenschaften) als es eine Calc-Tabelle erlaubt. Als Formular sollte die Base-Tabelle selbst dienen. Als Bericht ein Import der Daten von Calc aus. Erstmal. Evolution wird schon möglich sein, so meine Überlegung. Dabei wollte ich keineswegs einen Schnellschuss. Ich war sogar hier derjenige, der bremsend Einfluss nahm, als mir schon Formulare vorgeschlagen wurden (was ich in keiner Weise kritisieren möchte, denn das war absolut nett und wohlwollend gemeint), wo ich noch einige Zeit über der Struktur brüten wollte. Zu Deinem Vorschlag, nach einer professionellen Software Ausschau zu halten oder in einer Community anzufragen: das werde ich auf jeden Fall erwägen, sobald ich aus eigener Erfahrung Deine Einschätzung bestätigen kann. Pfusch hat mich noch nie befriedigt. Angemessene Imperfektion sehr wohl. Ich bin nicht so vermessen zu denken, die selbstgebaute Anwendung eines blutigen Anfängers könne sich mit der Universalität, Bedienfreundlichkeit oder gar der Wohlgestalt einer Profi-Software messen. Ich schreibe das nicht nur als Floskel: Aufgeben ist definitiv eine Option. Meine Eitelkeit hält das aus. Wenn eine Lösung herauskäme, die ich vor meinem Freund nicht guten Gewissens vertreten kann, werde ich ihm raten, sich was Besseres zu suchen und dabei auch unterstützen. Du schreibst, ich würde ihm etwas vorgaukeln. Das war und ist nicht der Fall. Zu Deine Bemerkungen haben mir gezeigt, dass Du das Wesen einer DB (noch) nicht begriffen: Ohne Frage habe ich das Wesen einer Datenbank noch nicht begriffen. Du machst dies jedoch IMHO an einem unpassenden Aufhänger fest. Bitte gehe auf die von mir genannten Argumente ein, wo ich schreibe, dass ich keinen guten Grund sehe, bewußt eine für menschliche Verwalter (ich schrieb explizit nicht von Anwendern) schlechter lesbare (Benennungen, Reihenfolge) und somit schlechter wartbare Struktur anzulegen. Ich hoffe ich konnte einiges aufklären. Da Du das Erstellen von DB unterrichtest: darf ich noch um einen Rat bitten? Welche didaktisch exzellente (deutschsprachige) Literatur zur Struktur (relationaler) DB kannst Du mir empfehlen? Schöne Grüße, Andreas Hallo Andreas Erlaube mir ein paar allgemeine Bemerkungen zu Deinem Anliegen. Du hast zwei Probleme: zum einen will Dein Freund, der Komponist, ein Werkzeug, das ihm erlaubt, seine Werke zu katalogisieren. Zum anderen willst Du DB lernen. Tut mir leid, aber als einer, der selber Berufsmittelschüler u.a. auch in DB unterrichtet, muss ich Dir sagen: vergiss es, diese beiden Probleme in einem Aufwaschen lösen zu wollen! Du wirst scheitern. Wenn es so einfach wäre wie Du zu glauben scheinst, dann würden professionelle DB-Entwickler woll kaum ein FH- oder Uni-Studium benötigen. Um das Problem Deines Freundes zu lösen, gibt es drei Wege: ein professionelles Programm, das kostet: scheidet aus, weil Dein Freund nicht über die Mittel verfügt, wie Du schreibst. Dann bleiben immer noch zwei andere Wege: suche gezielt im Open Source-, Freeware-Bereich, was es schon an Lösungen gibt - ich bin immer wieder erstaunt, was es in diesem Bereich alles gibt, und was erfahrene (!!) professionelle Entwickler der Community bereit sind, der Allgemeinheit gratis oder allenfalls gegen eine mehr als nur bescheidene Lizenzgebühr zur Verfügung zu stellen. 30€ für eine solche Lizenzierung müsste auch Deinem Freund die Professionalität wert sein. Sollte wider Erwarten auch dieser Weg nicht zum Ziel führen so wäre die gezielte Anfrage in der Community zu lancieren, ob jemand bereit ist, für ihn diese DB professionell zu entwickeln - entweder als OS/FS-Produkt, oder aber gratis für Deinen Freund, weil er sein Know-how auf User-Seite zur Verfügung stellt. Aber lass als Anfänger die Finger davon, eine komplexe DB für den professionellen Einsatz entwickeln zu wollen - Du wirst Dir und Deinem Freund damit nur Frust und Scherereien einfahren, und ein Produkt wird - wenn
Re: [de-users] Re: Datenbank: Werk eines Komponisten
* Andreas Borutta [14-06-2009 19:08]: Welche didaktisch exzellente (deutschsprachige) Literatur zur Struktur (relationaler) DB kannst Du mir empfehlen? Hallo Andreas, einen direkten Literaturtipp habe ich nicht für dich, aber 2 Seiten für einen groben Überblick: http://de.wikipedia.org/wiki/Relationale_Datenbank http://de.wikipedia.org/wiki/Entity-Relationship-Modell Wenn du das ERM verstanden hast, bist du ein großes Stück weiter. Gruß Uwe - To unsubscribe, e-mail: users-unsubscr...@de.openoffice.org For additional commands, e-mail: users-h...@de.openoffice.org
[de-users] Re: Datenbank: Werk eines Komponisten
Robert Großkopf schrieb: Jetzt geht es erstmal darum, die Datenbank zu konzipieren. Mir erscheint es sinnvoll, dass Daten jeweils nur an einzigen Stelle eingeben werden und nicht mehrmals. Das sollte grundsätzlich in jeder Datenbank so sein. Weiterhin sollen nur voneinander unabhängige Daten eingegeben werden: Daten, die also aus anderen berechnet werden können, sollen nicht im Datenbestand vorkommen. Wenn Du die händisch berechnen würdest wäre an dieser Stelle ja auch eine entsprechende Fehlerquelle. Richtig. Aber wenn ich mir Dein Beispiel zur Verwaltung OpenOffice Medien ansehe, wären wohl auch für Werk eines Komponisten ausgewachsene Makros nötig um die Abhängigkeiten abzubilden. Den Entwurf kann ich mir im Moment nicht ansehen (muss gleich weg ...) Ich habe die hier im Thread aufgezählten Abhängigkeiten nochmal sauber auf dem ersten Tabellenblatt von http://borumat.de/+temp/openoffice/rohdaten-simon-barber-work.ods aufgeführt. Toll fände ich ein paar Links auf empfehlenswerte, didaktisch wertvolle und vorbildliche ODBs, die als Beispiele fungieren können. Nicht weiter verfolgt, da mein eigentlicher Bereich für Datenbank bereits durch MySQL-PHP ausgefüllt ist, Mein Ziel ist es ebenfalls, meinem Freund ein Webformular an die Hand geben zu können, mit welchem er neue Werke direkt in die Datenbank auf dem Server einspeisen kann. Wenn ich es richtig sehe, gibt es in Base keinen Assistenten, der die Erstellung eines Webformulars unterstützt. Ein interessanter Punkt ist mir in Deiner Datenbank Inventur aufgefallen. Du hast eine eigene Tabelle zum Aufführen des Einheitenzeichens verwendet. Ist das in Datenbanken generell ein empfehlenswerter/etablierter Weg um einer Maßzahl ein Einheitenzeichen zuzuordnen? aber vom Entwurf her wohl ganz brauchbar: http://www.scoolonline.de/download/openoffice.html PS: Ich habe bereits Daten einer Calc-Tabelle in eine ODB-Tabelle eingefügt. Das klappte. Datenfelder wurden automatisch erzeugt. Was mir nicht gelang, ist das Verschieben von Datenfeldern und das Einfügen eines neuen Datenfeldes mitten zwischen anderen Datenfeldern. In der Hilfe bin ich dazu nicht fündig geworden. Die Reihenfolge der Felder innerhalb der Tabelle ist doch eigentlich egal. Für die Maschine: ja. Für einen menschlichen Verwalter ist es dagegen praktisch, wenn inhaltlich zusammengehörende Datenfelder in einer sinnvollen Reihenfolge stehen. Andreas -- OOo 3.1 http://borumat.de/openoffice-writer-tipps - To unsubscribe, e-mail: users-unsubscr...@de.openoffice.org For additional commands, e-mail: users-h...@de.openoffice.org
Re: [de-users] Re: Datenbank: Werk eines Komponisten
Hallo Andreas, das Mittagessen wartet. Ich habe gerade einen Entwurf der Datenbanktabellen nach Deiner Tabelle gemacht. Er steht unter http://www.scoolonline.de/download/Musik_Klassik.odb Die Daten sind drin, aber noch nicht verknüpft. Ein Formular zur Eingabe fehlt natürlich auch noch. Gruß Robert - To unsubscribe, e-mail: users-unsubscr...@de.openoffice.org For additional commands, e-mail: users-h...@de.openoffice.org
[de-users] Re: Datenbank: Werk eines Komponisten
Andreas Borutta wrote: Richtig. Aber wenn ich mir Dein Beispiel zur Verwaltung OpenOffice Medien ansehe, wären wohl auch für Werk eines Komponisten ausgewachsene Makros nötig um die Abhängigkeiten abzubilden. Nein, die Abhängigkeiten können alle in der Datenbank hinter dem Formular abgebildet werden. Base ist leider so schlecht, dass für vergleichsweise triviale Dinge nachprogrammiert werden muss. Du kannst aber durchaus brauchbare, wenn auch nicht schöne oder sehr komfortable, Formulare ohne Makros erzeugen. Das einzige was wirklich zählt ist die Datenbankstruktur. Wenn die Fehlerhaft ist, dann programmierts Du Dir mit den Formularen einen Wolf. Mein Ziel ist es ebenfalls, meinem Freund ein Webformular an die Hand geben zu können, mit welchem er neue Werke direkt in die Datenbank auf dem Server einspeisen kann. Das ginge mit einer Tabellenkalkulation schon mal gar nicht und ansonsten nimmst Du halt die Datenbank, die dir möglichst preiswert und ohne Umstände auf dem Server zur Verfügung steht. Wenn ich es richtig sehe, gibt es in Base keinen Assistenten, der die Erstellung eines Webformulars unterstützt. Der alleinige Zweck von Base ist es, Datenbankinhalte (oder was als solche darstellbarist) in Officedokumente zu importieren. Selbst die verstümmelte HSQLDB, die Du in Base als alleinstehendes Datenbankdokument erzeugen kannst, nutzt nichts anderes als Writer für die Formulare und Reports. Für die Maschine: ja. Für einen menschlichen Verwalter ist es dagegen praktisch, wenn inhaltlich zusammengehörende Datenfelder in einer sinnvollen Reihenfolge stehen. Sagen wir mal, Du hast in Eile eine Tabelle mit den Feldnamen F1 bis F8 angelegt. Du kannst jedes Feld einer einzelnen Tabelle mit jedem Aliasnamen in jeder Reihenfolge von Spalten und Zeilen darstellen, ohne dass irgendjemand den Unterschied bemerken würde: SELECT F7 AS Nachname, F5 AS Vorname, F3 AS Geboren am, F1 AS Geburtsort FROM Tabelle1 AS Personen WHERE F2F4 ORDER BY F8, F6 ... und gleichzeiting nach irgenwelchen anderen Feldern sortieren filtern und sortieren. - To unsubscribe, e-mail: users-unsubscr...@de.openoffice.org For additional commands, e-mail: users-h...@de.openoffice.org
Re: [de-users] Re: Datenbank: Werk eines Komponisten
Hallo Andreas, das Mittagessen wartet. Ich habe gerade einen Entwurf der Datenbanktabellen nach Deiner Tabelle gemacht. Er steht unter http://www.scoolonline.de/download/Musik_Klassik.odb Habe mich gerade noch einmal für 45 Minuten dran gesetzt. Irgendwie hat die Formatierung des Datums als nicht richtig funktioniert. Habe das jetzt als 4-stellige Zahl realisiert. Die Daten sind drin, aber noch nicht verknüpft. Jetzt sind sie verknüpft, soweit es Titel und Untertitel angeht. Für di ersten Titel sind auch die anderen Verknüpfungen über das Formular erstellt. Ein Formular zur Eingabe fehlt natürlich auch noch. Steht jetzt. Die Instrumentation scheint mir aber noch nicht ideal gelöst zu sein. Zu Deinen Anmerkungen: Mit Base kannst Du keine Webformulare erstellen. Allerdings kannst Du mit Base sehr wohl auf eine Webdatenbank zugreifen. Dafür ist dann aber die eingebaute HSQLDB nicht geeignet. Umfassende Makroprogrammierung ist nur dann notwendig, wennn das Handling von Datenbanken mit dem Base-Frontend verbessert werden soll. Bevor ich die Medien-Datenbank erstellt habe hatte ich noch kein einiges Makro erstellt. Nur gab es da einige Ansprüche, die ich so nicht lösen konnte. Ähnliches könnte z.B. auch bei der Intrumentation in Deiner Datenbank der Fall sein. Zur Datenbank Inventur: Ich lege am liebsten alle Daten, die ich in der Datenbank brauche, auch dort ab. Maßeinheiten sind beispielsweise nicht Bestandteil der darunterliegenden Datenbank, sondern auch in Base nur durch die Benutzeroberfläche zusätzlich einstellbar. Für meine Web-Datenbanken entnehme ich die Werte für Listfelder grundsätzlich solchen kleinen Tabellen - es sei denn, die Menge der Bezeichnungen ist klar begrenzt, wird nicht erweitert und außerdem direkt in einer weiteren Tabelle abgelegt (m für männlich, w für weiblich). Bei den Maßeinheiten für das Inventur-Beispiel war das eigentlich erst einmal unklar. Das Beispiel ist auch nur entstanden, weil in dieser Liste jemand Probleme beim Datenbankerstellen hatte und sich unsicher war, wie denn eventuell Berechnungen in Base gingen. Gruß Robert - To unsubscribe, e-mail: users-unsubscr...@de.openoffice.org For additional commands, e-mail: users-h...@de.openoffice.org
[de-users] Re: Datenbank: Werk eines Komponisten
Andreas Saeger schrieb: Aber wenn ich mir Dein Beispiel zur Verwaltung OpenOffice Medien ansehe, wären wohl auch für Werk eines Komponisten ausgewachsene Makros nötig um die Abhängigkeiten abzubilden. Nein, die Abhängigkeiten können alle in der Datenbank hinter dem Formular abgebildet werden. Base ist leider so schlecht, dass für vergleichsweise triviale Dinge nachprogrammiert werden muss. In welchen Datenbankverwaltungsprogrammen ist das denn anders? Hintergrund der Frage ist auch, dass man ja via Base beliebige Datenbanken in Calc einbinden kann. Wenn also eine andere Software deutliche Vorteile gegenüber Base besitzt, könnte man ihr den Vorzug geben. Gerade jetzt, wo ich erst anfange. Vor allem: das Einbinden von Daten in Calc ist grundsätzlich nützlich. Zusätzlich möchte ich aber auf jeden Fall lernen, wie man Daten auf einem Webserver anbietet. Du kannst aber durchaus brauchbare, wenn auch nicht schöne oder sehr komfortable, Formulare ohne Makros erzeugen. Das einzige was wirklich zählt ist die Datenbankstruktur. Darauf möchte ich mich im Moment auch konzentrieren. Formulare kommen dann in der zweiten Phase. Erstmal muss mir klar werden, mit welcher Struktur das Werk eines Komponisten am besten abgebildet wird. Mir geht es dabei um Langlebigkeit, um Nachhaltigkeit. Wenn das Ganze gut wird, möchte ich die Datenbank auch anderen Komponisten zur freien Nutzung bereitstellen. Die in der Rohdatentabelle aufgeführten Merkmale gelten für beliebige Kompositionen von Komponisten für neue Musik, sagte mir mein Freund. Wenn die Fehlerhaft ist, dann programmierts Du Dir mit den Formularen einen Wolf. Mein Ziel ist es ebenfalls, meinem Freund ein Webformular an die Hand geben zu können, mit welchem er neue Werke direkt in die Datenbank auf dem Server einspeisen kann. Das ginge mit einer Tabellenkalkulation schon mal gar nicht und ansonsten nimmst Du halt die Datenbank, die dir möglichst preiswert und ohne Umstände auf dem Server zur Verfügung steht. Auf dem Server erlaubt der Anbieter all-inkl.com 5 MySQL Datenbanken. [Reihenfolge von Datenfeldern] Für die Maschine: ja. Für einen menschlichen Verwalter ist es dagegen praktisch, wenn inhaltlich zusammengehörende Datenfelder in einer sinnvollen Reihenfolge stehen. Sagen wir mal, Du hast in Eile eine Tabelle mit den Feldnamen F1 bis F8 angelegt. Du kannst jedes Feld einer einzelnen Tabelle mit jedem Aliasnamen in jeder Reihenfolge von Spalten und Zeilen darstellen, ohne dass irgendjemand den Unterschied bemerken würde: SELECT F7 AS Nachname, F5 AS Vorname, F3 AS Geboren am, F1 AS Geburtsort FROM Tabelle1 AS Personen WHERE F2F4 ORDER BY F8, F6 ... und gleichzeiting nach irgenwelchen anderen Feldern sortieren filtern und sortieren. OK. Ich habe mir schon gedacht, dass es Aliase gibt und auch eine andere Reihenfolge gibt. Dennoch finde ich, dass es der Nachhaltigkeit dient, wenn die Datenfelder der Tabelle in einer sinnvollen Reihenfolge stehen und sprechende Namen tragen. Jede zusätzlich Schicht erhöht die Komplexität und erschwert die Wartung. Ohne Not, denke ich, sollte man eine solche Schicht hinzufügen. Aber offenbar kann man in Base Datenfelder nachträglich nicht in der Reihenfolge ändern oder mittendrin ein neues Datenfeld einfügen. Andreas -- OOo 3.1 http://borumat.de/openoffice-writer-tipps - To unsubscribe, e-mail: users-unsubscr...@de.openoffice.org For additional commands, e-mail: users-h...@de.openoffice.org
[de-users] Re: Datenbank und Formulare
Hi Matthias, Matthias Müller elv_matth.muel...@... writes: ... Die deutsche Sprache kennt die Groß- und Kleinschreibung. Dies macht einen Text leichter lesbar. Nee, den Gefallen wird er uns nicht tun, und deinen Hinweis ernstnehmen. Die Leser für ihn ... phh und LOL. Im nächsten Beitrag setzt er noch einen drauf und schaltet hinter jede Zeile einen Leerabsatz, damit sich sein Geschriebenes schön wie Kaugummi zieht. Ich würde sagen, jetzt hilft: Nicht ärgern sondern für seine Postings den FileKill nutzen - schont die Augen. Martin - To unsubscribe, e-mail: users-unsubscr...@de.openoffice.org For additional commands, e-mail: users-h...@de.openoffice.org
[de-users] Re: Datenbank und Formulare
co...@... writes: Matthias Müller elv_matth.muel...@... writes: ... Die deutsche Sprache kennt die Groß- und Kleinschreibung. Dies macht einen Text leichter lesbar. Nee, den Gefallen wird er uns nicht tun, und deinen Hinweis ernstnehmen. Die Leser für ihn ... phh und LOL. Ich würde sagen, jetzt hilft: Nicht ärgern sondern für seine Postings den FileKill nutzen - schont die Augen. Ja. Ich finde mittlerweile, dass man Ignoranten auf dieser Liste ruhig ignorieren kann. Ich tue mir das nicht mehr an, Beiträge zu lesen, die - nur klein geschrieben sind - komplette vorherige Mails enthalten - die Antwort oben haben - u.ä. Zumindest dann nicht, wenn ich sehe, dass es keine Frischlinge hier sind, und ich davon ausgehen kann, dass sie jeden Montag den Pointer (Listenregeln) von Andrè ungelesen in die Tonne kloppen. Mario - To unsubscribe, e-mail: users-unsubscr...@de.openoffice.org For additional commands, e-mail: users-h...@de.openoffice.org
Re: [de-users] Re: Datenbank: Gültigkeitsprüfung
Hallo Josef, Hallo, und wie mache ich das nun genau? wie lautet der entsprechende SQL-Befehl bitte? Verstehe ich das richtig, dass Du die Eingabe nicht über ein Formular machst, das von Vornherein ungültige Eingaben ausschließen würde? Gerade bei der Vorgabe, die Du machst (1-9) ist das über SQL nur dann zu lösen, wenn Du die Länge des tinyinteger-Feldes auf 1 setzt (standardmäßig wegen der maximal möglichen 256 Zahlen auf 3 stehend, Einstellung bei Erstellen der Tabelle). Ich habe das gerade einmal versucht: Leider lässt sich der Wert bei OpenOffice-Base nicht beeinflussen. Dann musst Du wohl die Tabelle mit SQL direkt gründen: CREATE TABLE Tabellenname (Testfeld TINYINT(1), .weitere Felder, Primärschlüssel nicht vergessen ...) Einfacher geht's über die Formulareinstellungen. Gruß Robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [de-users] Re: Datenbank: Gültigkeitsprü fung
Hi, Josef Grabner schrieb: Hallo, und wie mache ich das nun genau? wie lautet der entsprechende SQL-Befehl bitte? ok - empfehlen würde ich es nicht, da der SQL-Befehl zwar die Dateneingabe einschränkt, das aber nur begrenzt an der Öberfläche sichtbar ist. (Die bessere - weil für den endanwender verstänlichere - Möglichkeit sind Formulare). Du kannst folgenden SQL-Befehl direkt ausführen: create table mytable3 ( i1 integer, i2 integer, primary key (i1), check (i2 between 0 and 9) ) Damit erhältst du eine Tabelle mit zwei integer-spalten. Für I2 sind dabei nur Werte von 0 bis 9 zulässig. Wird ein Wert ausserhalb dieses Bereichs einggeben, erhältst Du einen SQL-Fehler. Du musst die Datenbank schliessen und wieder öffnen, um die Tabelle zu sehen. Weitere hinweise zur SQL-Syntax der internen HSQL-DB unter http://hsqldb.org/doc/guide/ch09.html http://hsqldb.org/doc/guide/ch09.html#create_table-section André - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[de-users] Re: Datenbank: Gültigkeitsprüfung
Wie kann ich im Datenbankmodul die Güigkeitsprüfung für die Eingabe aktivieren? Josef, bei einer Datenbank kannst Du die zulässigen constraints nutzen, bei Verwendung der internen HSQLDB siehe http://www.hsqldb.org/web/hsqlDocsFrame.html Meintest Du das? Cheers Winfried -- re-Solutions.de Software Test Engineering Mainz Germany Europe meine OOo Seiten: http://www.re-solutions.de/ooo/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[de-users] Re: Datenbank: G�ltigkeitspr
Ich meine die Gültigkeitsregel bei der Dateneingabe. z.B.: sollen nur Zaheln 10 eingegeben werden können. kann ich das unter OpenOffice.org? Danke! Josef Grabner Winfried Rohr [EMAIL PROTECTED] schrieb im Newsbeitrag news:[EMAIL PROTECTED] Wie kann ich im Datenbankmodul die Güigkeitsprüfung für die Eingabe aktivieren? Josef, bei einer Datenbank kannst Du die zulässigen constraints nutzen, bei Verwendung der internen HSQLDB siehe http://www.hsqldb.org/web/hsqlDocsFrame.html Meintest Du das? Cheers Winfried -- re-Solutions.de Software Test Engineering Mainz Germany Europe meine OOo Seiten: http://www.re-solutions.de/ooo/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[de-users] Re: Datenbank: Gültigkeitsprüfung
Ich meine die Gültigkeitsregel bei der Dateneingabe. z.B.: sollen nur Zaheln 10 eingegeben werden können. Ja das geht. Wenn Du uns noch sagst welche Form der Dateneingabe Du im Konkreten meinst. Bei BASE-Dokumenten kann ein Formular zur Eingabe genutzt werden, darin ein nummerisches Kontrollfeld, dessen Wertebereich von Null bis 9 geht: meinst Du das? Cheers Winfried -- re-Solutions.de Software Test Engineering Mainz Germany Europe meine OOo Seiten: http://www.re-solutions.de/ooo/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[de-users] Re: Datenbank: G�ltigkeitspr
Hallo, und wie mache ich das nun genau? wie lautet der entsprechende SQL-Befehl bitte? Herzlichen Dank! Josef Winfried Rohr [EMAIL PROTECTED] schrieb im Newsbeitrag news:[EMAIL PROTECTED] Wie kann ich im Datenbankmodul die Güigkeitsprüfung für die Eingabe aktivieren? Josef, bei einer Datenbank kannst Du die zulässigen constraints nutzen, bei Verwendung der internen HSQLDB siehe http://www.hsqldb.org/web/hsqlDocsFrame.html Meintest Du das? Cheers Winfried -- re-Solutions.de Software Test Engineering Mainz Germany Europe meine OOo Seiten: http://www.re-solutions.de/ooo/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[de-users] Re: Datenbank
Hallo, aber damit bekomme ich doch noch keine Verknüpfung der Tabellen untereinander hin? Gruss Alfons Am 03.02.2007, 20:02 Uhr, schrieb Mechtilde [EMAIL PROTECTED]: Hallo Alfons Mair schrieb: Hallo, wie bekomme ich es hin eine bestehende Tabelle in der ich die jeweiligen Länder brauche in eine weitere Tabelle zu verknüpfen, welche dann nur die Länder beinhaltet? Leider habe ich nicht soviel Erfahrung mit einer DB, aber ich bin auf der Suche nach der selbigen. Nun mein Ziel ist es in Tabelle 1 eine Spalte Ländercode aufzunehmen und diesen dann aber in einer Tabelle 2 zu hinterlegen, kann ich dann in Tabelle 1 über ein Drop-Down oder was auch immer eine Verknüpfung zu Tabelle 2 bekommen? In der Tabellensicht selber geht es nicht. Es geht, wenn Du ein Formular erstellst und dort die entsprechenden Felder als Listenfelder definierst. Gruß Mechtilde - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [de-users] Re: Datenbank
Hallo Alfons, Alfons Mair schrieb: Hallo, aber damit bekomme ich doch noch keine Verknüpfung der Tabellen untereinander hin? Hast Du Dir mal www.ooowiki.de/DatenbankErzeugen angeschaut? Gruß Mechtilde -- Dipl. Ing. Mechtilde Stehmann ## Observer OpenOffice.org: lang/DE ## Freie Office-Suite für Linux, Mac, Windows, Solaris ## http://de.openoffice.org ## Meine Seite http://www.mechtilde.de ## PGP encryption welcome! Key-ID: 0x53B3892B - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [de-users] Re: Datenbank, Erfassungsformular
Claudia Drechsle schrieb: Vielen Dank an alle, die mir hier unter die Arme gegriffen haben. Begriffen habe ich das Ganze schlussendlich anhand zweier Beispiele, die mir Regina und Mechthild zugeschickt haben. Wer sie sich ansehen will (ich setze jetzt einfach mal voraus, dass das für die Ersteller ok ist), kann sie sich hier herunterladen: http://mypage.bluewin.ch/solkasim/ArtikelstammAbfrage.odb http://mypage.bluewin.ch/solkasim/ArtikelstammSQL.odb Kurze Zusammenfassung: Es gibt eine Tabelle WarenGruppen mit genau einem Eintrag pro Warengruppe, der jeweils aus einer Warengruppen-Nr. und einer Warengruppen-Bezeichnung besteht. In der Tabelle ArtikelDaten soll beim Erfassen eines Artikels auch eine Warengruppen-Nr. zugeordnet werden. Ein Auswahlfeld in einem Formular zur ArtikelDaten-Erfassung soll nun die Warengruppen-Bezeichnungen anbieten und nach erfolgter Auswahl nicht diese Bezeichnung sondern die zugehörige Warengruppen-Nr. in einem Feld der Tabelle ArtikelDaten ablegen. Dies ist mit einem Listenfeld möglich, in dem man entweder direkt einen SQL-Befehl hinterlegen kann oder eine Abfrage (die natürlich zunächst definiert werden muss) Bei den Beispielen einfach im Kontext-Menu des Listenfeldes 'Kontrollfeld' auswählen und das Register 'Daten' aufklappen: hier sind die Anweisungen hinterlegt. Vielen Dank für diese Informationen. Sie sind mehr sehr hilfreich. Werde nächste Woche gleich damit testen. Eine Frage drängt sich mir auf: Wäre es möglich, eine Auswahl (z.B. 010) vorzugeben? Grund: Es soll sichergestellt sein, dass mindestens eine Warengruppe eingegeben ist. Eine nächste Frage: Könnte ich eine Warengruppe suchen? Eventuell über ein zusätzliches Feld, wo ich z.B. Ob* eingeben könnte, und mir nur die möglichen Warengruppen angezeigt werden? Danke für Eure Hilfe Fredi - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[de-users] Re: Datenbank, Erfassungsformular
hallo Regina Ja, siehe http://www.ooowiki.de/EinsZuVieleBeziehung Abschnitt Vergelich mit Access Ich werd mir das mal reinziehen, vielen Dank _ Claudia - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[de-users] Re: Datenbank, Erfassungsformular
Hallo Mechtilde Diese Auswahl-Liste soll Dir aber die Konten-Bezeichnungen anzeigen, damit Du nicht die falsche Nummer erwischst. das geht möglicherweise nur mit einem Makro, da bin ich überfragt. Wenn das nur mit Makro geht, dann müssen wirs lassen. Danke trotzdem. Dazu brauchst Du _keine_ Makros. PS: In welcher Gegend von Deutschland kann man Dich denn finden? Gar nicht, lebe im Ausland Schade. Würde Dir gerne weiterhelfen Ich bin erst ganz am Anfang mit Datenbank+Formularen, muss mich halt noch ein wenig reinarbeiten. Vielleicht frage ich nochmal nach, wenn ich ein wenig klarer sehe. Wenn Du noch den Nerv dazu hast: ich habe eine ganz reduzierte Version ins Netz gestellt: http://mypage.bluewin.ch/solkasim/Artikelstamm.odb 2 Tabellen, ein Formular. Wenn Du da so ein Listenfeld reinsetzen und mir als PM schicken könntest, das wär lieb ([EMAIL PROTECTED]) -- _ Claudia - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [de-users] Re: Datenbank, Erfassungsformular
Hallo Claudia, Claudia Drechsle schrieb: Wenn Du noch den Nerv dazu hast: ich habe eine ganz reduzierte Version ins Netz gestellt: http://mypage.bluewin.ch/solkasim/Artikelstamm.odb 2 Tabellen, ein Formular. Wenn Du da so ein Listenfeld reinsetzen und mir als PM schicken könntest, das wär lieb ([EMAIL PROTECTED]) Habe ich dir geschickt. mfG Regina - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [de-users] Re: Datenbank, Erfassungsformular
Hallo Claudia, Claudia Drechsle schrieb: hallo Regina Ja, siehe http://www.ooowiki.de/EinsZuVieleBeziehung Abschnitt Vergelich mit Access Ich habe gemerkt, dass es bei deiner speziellen Anforderung einfacher ist, weil du ja nur 1 Spalte anzeigen willst. Guck dir mal den Artikel von Anfang an an, und sag dann, wo er dir noch nicht verständlich/ausführlich genug ist und in welcher Weise man ihn verbessern könnte. mfG Regina - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [de-users] Re: Datenbank, Erfassungsformular
Hallo, da wäre ich auch daran interessiert... Liebe Grüße Romana Regina Henschel schrieb: Hallo Claudia, Claudia Drechsle schrieb: Wenn Du noch den Nerv dazu hast: ich habe eine ganz reduzierte Version ins Netz gestellt: http://mypage.bluewin.ch/solkasim/Artikelstamm.odb 2 Tabellen, ein Formular. Wenn Du da so ein Listenfeld reinsetzen und mir als PM schicken könntest, das wär lieb ([EMAIL PROTECTED]) Habe ich dir geschickt. mfG Regina - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[de-users] Re: Datenbank, Erfassungsformular
Vielen Dank an alle, die mir hier unter die Arme gegriffen haben. Begriffen habe ich das Ganze schlussendlich anhand zweier Beispiele, die mir Regina und Mechthild zugeschickt haben. Wer sie sich ansehen will (ich setze jetzt einfach mal voraus, dass das für die Ersteller ok ist), kann sie sich hier herunterladen: http://mypage.bluewin.ch/solkasim/ArtikelstammAbfrage.odb http://mypage.bluewin.ch/solkasim/ArtikelstammSQL.odb Kurze Zusammenfassung: Es gibt eine Tabelle WarenGruppen mit genau einem Eintrag pro Warengruppe, der jeweils aus einer Warengruppen-Nr. und einer Warengruppen-Bezeichnung besteht. In der Tabelle ArtikelDaten soll beim Erfassen eines Artikels auch eine Warengruppen-Nr. zugeordnet werden. Ein Auswahlfeld in einem Formular zur ArtikelDaten-Erfassung soll nun die Warengruppen-Bezeichnungen anbieten und nach erfolgter Auswahl nicht diese Bezeichnung sondern die zugehörige Warengruppen-Nr. in einem Feld der Tabelle ArtikelDaten ablegen. Dies ist mit einem Listenfeld möglich, in dem man entweder direkt einen SQL-Befehl hinterlegen kann oder eine Abfrage (die natürlich zunächst definiert werden muss) Bei den Beispielen einfach im Kontext-Menu des Listenfeldes 'Kontrollfeld' auswählen und das Register 'Daten' aufklappen: hier sind die Anweisungen hinterlegt. -- _ Claudia - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[de-users] Re: Datenbank, Erfassungsformular
Hallo folgende Situation: Ich möchte mit einem Erfassungsformular Artikeldaten in eine DB-Tabelle Artikel erfassen. Jeder Artikel soll einer Warengruppe zugeordnet werden. Es gibt eine Tabelle Warengruppen, die besteht aus einer eindeutigen Warengruppennummer (Primärschlüssel) und einer Bezeichnung. In der Tabelle Artikel soll im Feld Warengruppe die Warengruppennummer abgelegt werden. Nun hätte ich gern folgenden Ablauf im Erfassungsformular: Die Warengruppe sollte mit einem Kombinationsfeld aus der Tabelle Wie das mit einem Kombinationsfeld geht, weiß ich nicht. Ich kenne nur eine Lösung mit einem Listenfeld. Warengruppe übernommen werden. Da ich aber die Gruppen-Nummern nicht auswendig kenne, möchte ich die Bezeichnung auswählen können und anhand der Bezeichnung soll dann die Gruppen-Nummer in die Tabelle Artikel übernommen werden. Ist sowas (ohne Makro) machbar? Ja. Die Lösung reiche ich nach, muss ich selber noch raussuchen. Den Tipp mit dem Listenfeld habe ich versucht, nachzustellen. Aber ich stelle es wohl nicht richtig an. Oder ich habe nicht richtig formuliert, was ich brauche: In der Tabelle Artikel soll nicht die Bezeichnung der Warengruppe abgelegt werden, sondern nur die Nummer. Was ich mit dem Listenfeld hin bekommen habe ist das: Wenn in Artikel das Feld 'WarenGruppe' übereinstimmt mit dem Feld 'WarenGruppe' in der Tabelle WarenGruppen, dann zeige an: Feld Bezeichnung aus der Rabelle WarenGruppe. Was ich aber brauche ist folgendes: ein DropDownfeld, das mir das Feld 'Bezeichnung' aus der Tabelle WarenGruppen aufklappt. Ich wähle eine Bezeichnung aus, daraufhin landet die Warengruppennummer, die zu dieser Bezeichnung gehört aus der Tabelle WarenGruppen im Feld 'WarenGruppe' der Tabelle Artikel. Schöne Grüsse -- _ Claudia - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [de-users] Re: Datenbank, Erfassungsformular
Hallo Claudia Claudia Drechsle wrote: Den Tipp mit dem Listenfeld habe ich versucht, nachzustellen. Aber ich stelle es wohl nicht richtig an. Oder ich habe nicht richtig formuliert, was ich brauche: In der Tabelle Artikel soll nicht die Bezeichnung der Warengruppe abgelegt werden, sondern nur die Nummer. Was ich mit dem Listenfeld hin bekommen habe ist das: Wenn in Artikel das Feld 'WarenGruppe' übereinstimmt mit dem Feld 'WarenGruppe' in der Tabelle WarenGruppen, dann zeige an: Feld Bezeichnung aus der Rabelle WarenGruppe. Was ich aber brauche ist folgendes: ein DropDownfeld, das mir das Feld 'Bezeichnung' aus der Tabelle WarenGruppen aufklappt. Ich wähle eine Bezeichnung aus, daraufhin landet die Warengruppennummer, die zu dieser Bezeichnung gehört aus der Tabelle WarenGruppen im Feld 'WarenGruppe' der Tabelle Artikel. Ich hoffe ich habe Deine Konstellation richtig interpretiert. Dann müsste diese Bedingung erfüllt sein. Ich benutze dies analog in meiner Buchhaltungstabelle. Da wird dann auch nur die ID gespeichert, ich aber sehe im Formular den dazugehörigen Text. Mechtilde -- Dipl. Ing. Mechtilde Stehmann ## Observer OpenOffice.org: lang/DE ## Freie Office-Suite für Linux, Mac, Windows, Solaris ## http://de.openoffice.org ## Meine Seite http://www.mechtilde.de ## PGP encryption welcome! Key-ID: 0x53B3892B - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [de-users] Re: Datenbank per Makro registrieren (OO 2.0)
Hallo zusammen, hallo Marko, Nachdem ich mich jetz ziemlich lange mit der SDK, diversen Foren und Internetseiten rumgeschlagen habe. Hab ich die Lösung gefunden. Man muss wirklich die XStorable-Schnittstelle nutzen, allerdings wird diese nicht von com.sun.star.sdb.DataSource unterstützt. Allerdings gibt es eine neue (?) Schnittstelle com.sun.star.sdb.DatabaseDocument und mit dieser lässt sich die xStorable nutzen. Folgenden Code hab ich getestet und er funktioniert: oDBContext = createUnoService(com.sun.star.sdb.DatabaseContext) oDatabase = createUnoService(com.sun.star.sdb.DataSource) DBUrl = ConvertToURL(C:\Temp) oDatabase.DatabaseDocument.storeAsURL(DBUrl /new.odb, Dummy()) 'Damit wird die Base-Datei erzeugt (Vorerst leeres Dokument) 'Hier Datenbank-Eigenschaften setzen oDatabase.DatabaseDocument.store(true) 'Speichern damit Einstellungen gesichert werden oDBContext.RegisterObject(sDBName, oDatabase) 'Jetzt ist eine Anmeldung der Datenquelle möglich Ich hoffe ich kann damit einigen weiterhelfen. Schöne Grüße Max Manzenberger Marko Moeller schrieb: Manzenberger Max schrieb: Fataler Fehler (Datenbank registrieren) Fehler 1 in der Zeile 276 Type: com.sun.star.lang.IllegalArgumentException Message: Die Datenquelle wurde nicht gespeichert. Bitte verwenden Sie die Schnittstelle XStorable, um die Datenquelle zu speichern. Irgendwie hab ich mir das ja schon gedacht, dass es mit OO 2.0 Probs gibt. Ich vermute mal das liegt daran, dass Datenquelle jetzt über das Base-Modul angelet werden und dieses speichert die Einstellungen in einer *.odb. Lieg ich das richtig mit meiner Vermutung?? Ja, das ist wirklich so. Die alte Schnittstelle sollte wohl ursprünglich auch unter 2.x funktionieren, ich habe sie aber mit keiner Version 1.9x zum Laufen bekommen. Sorry, ich bastel auch noch an diesem Problem. Sollte ich vorher etwas finden, melde ich mich! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[de-users] Re: Datenbank OO2 Beta
Harald Schilly [EMAIL PROTECTED] writes: On Mon, 28 Feb 2005 14:34:12 + (UTC), pgm7473 [EMAIL PROTECTED] wrote: wie es scheint, funktioniert die Datenbank nicht richtig. Ja, das haben Beta Versionen leider so an sich ;) Sonst hieen sie ja final. Dass der Crash Reporter nicht funktioniert ist das einzig echt strende, das Base Modul selbst braucht ohne Zweifel noch viel arbeit. Harald danke, nach Neuinstallation jedenfalls luft die neue Adressdatenbank jedenfalls, crashreport nicht mehr gestartet, hoffentlich bleibts so Pieter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
