[de-users] Re: Re: Re: Datenbank: Werk eines Komponisten
Ernst Hügli schrieb: [...] Jahr der Fertigstellung einer Komposition [Ganzzahl, Jahreszahl nach Christus, vier Ziffern] [...] (ich habe dazu angemerkt, dass in Deinem Fall Jahrzahlen aus dem Mittelalter oder gar dem Altertum wenig realistisch sind, also vierstellige Zahlen 1500 oder drei- oder weniger stellige oder gar negative Zahlen)? Und hier musst Du im Entwurf ansetzen, wobei es mindestens zwei Möglichkeiten gibt: * mit einer Gültigkeitsprüfung, wie sie Guenter vorschlägt; Access sieht - im Gegensatz zu Base - eine solche Möglichkeit explizit im User-Interface für den Entwurf vor (als Angebot: take it or leave it) * durch Benutzung eines explizit als YEAR (o.ä.) deklarierten Feldtyps, wie Du mich für PHPMyAdmin in einer früheren Mail hingewiesen hast. Ich habe mit diesem Werkzeug bisher (noch?) nicht gearbeitet, vermute aber dennoch, dass dahinter eine vierziffrige Ganzzahl 1582 versteckt ist, also die von Guenter erwähnten Constraints teilweise in die Deklaration des Feldtyps integriert wurden. Alles Andere würde wenig Sinn machen Das wurde ja im Thread mittlerweile aufgeklärt: Du hattest richtig vermutet. Ohne sowas wird sie bei einer Selektion nach Jahren - z.B. Alle Werke, die nach der Jahrtausendwende komponiert wurden - je nach Formulierung gewisse Werke nicht finden: Setzest Du das Selektionskriterium auf 2000 (da das Jahr 2000 bekanntlich das letzte im 20. Jh. ist), dann findet er den Eintrag 09 nicht, denn 09 2000 (als Zahlenvergleich trivial). Oder aber: Du formulierst 00, und dann wird er mit Ausnahme der im Jahr 2000 (bzw. 1900, ..., wenn die Eintragungen so weit zurück reichen) eben alles finden. Fazit einmal mehr: der Entwurf (neudeutsch Design genannt) bestimmt, was Du nachher mit der DB anstellen kannst. Natürlich kannst Du im Nachhinein den Datentyp und allfällige Constraints noch ändern - doch je nach Anzahl Datensätzen steht Dir danach (oder davor, das ist teilweise Ansichtssache) noch ein hartes Stück Arbeit bevor, denn Du musst dann alle Werte anpassen - ob per Programm oder händisch ist dabei gleichgültig. Du investierst jedenfalls ein Mehrfaches der Zeit in die Korrektur, die Du für einen sauberen Entwurf benötigt hättest. Du musst dann nämlich auch noch sämtliche Beziehungen, ... prüfen, ob sich da nicht Folgefehler der Änderung einschleichen. Übrigens: die meisten DB und Tabellenkalkulationen haben mit Datumvariablen die erwähnte Restriktion: vierstellig, 1582. Die zweite Bedingung hat mit der Kalenderreform von Papst Gregor im Oktober 1582 zu tun, die erste ist wohl eine Frage des praktischen Nutzens bzw. der internen Darstellung von Datumwerten. So ist es denn wohl eher von theoretischer Bedeutung, dass Calc bereits ab dem Jahr 9958 Probleme mit der korrekten Darstellung eines Datums bekommt (ich habe mich noch nicht bemüht, die Ursache dieser Grenze zu eruieren - wahrscheinlich hängt es eben mit der internen Darstellung von Daten zusammen). Als Fazit könnte man für das Attribut Jahr der Fertigstellung einer Komposition ziehen: Datentyp SMALLINT In den SQL-Anweisungen für Abfragen * Eine Prüfung auf Zahl mit genau vier Ziffern * Bei Eingaben einer Zahl kleiner als 1400 (also vor der Renaissancemusik) könnte man eine Rückfrage ausgeben lassen Sind sie sicher ...? * Beim Versuch einer Eingabe größer als das aktuelle Jahr könnte man ausgeben Spekulationen über die Fertigstellung künftiger Werke sollen in dieser DB keinen Platz finden. Andreas -- Sammlung von Attributen für eine DB des Werkes eines Komponisten: http://borumat.de/+temp/openoffice/rohdaten-simon-barber-work.ods - To unsubscribe, e-mail: users-unsubscr...@de.openoffice.org For additional commands, e-mail: users-h...@de.openoffice.org
Re: [de-users] Re: Re: Re: Datenbank: Werk eines Komponisten
Hallo, Am Mittwoch, 17. Juni 2009 schrieb Andreas Borutta: snip Aber ich kann es mir bei Deinem Beispiel nicht verkneifen: Das Bessere ist der Feind des Guten. Das ist meistens so. :-) Hier könnte es sein: Orte ID (primary key) PLZ Name Oder würdet ihr den Schlüsselkandidat PLZ als Primärschlüssel empfehlen, weil er sozusagen einen sprechenden/natürlichenr Schlüssel darstellt? PLZ sind in D eindeutig, könnten somit als Schlüssel verwendet werden. Wenn nicht Teilorte/Stadtteile oÄ referenziert werden müssen. Dann ist es Essig damit. Hier hilft dann tatsächlich nur ein Primärschlüssel, der höchstwahrscheinlich künstlich sein muss. In der wirklichen Welt (in Deutschland), kommt fast überall die Postleitzahl vor dem Ort. Konventionen sollte man nicht ohne guten Grund brechen, oder? Du kannst es in der Reihenfolge definieren. Wenn dein DBMS aber die Feldnamen alfabetisch sortiert, wenn du die Tabelle inspizieren willst, hast du auch uU Pech gehabt. In diesem Beispiel jetzt nicht, aber ein geeignetes lässt sich bestimmt konstruieren. Und wenn die Tabelle schon Ort heißt, braucht man IMHO diesen Namensteil nicht mehr im Feldnamen wiederholen. Das ist imho Ansichtssache. In der Tabelle ORT könntest du auf eine führende Vorsilbe verzichten. Was aber, wenn du eine weitere Tabelle zB AUTO definieren musst mit den Feldern NAME (aka Automarke), TYP, MOTORLEISTUNG (Warum auch immer, sei mal dahingestellt, Beispiele hinken immer :-) ). Dann hast du zwei Tabellen mit dem Feldnamen NAME. Als Progrmmierer habe ich es mir angewöhnt solche Namen so eindeutig wie möglich zu machen, selbst dann, wenn das 3..17 (nur so zB) Buchstaben mehr sind. Spätestens bei der ersten Wartungsprogrmmierung bist du dafür dankbar. Ich bin der Meinung, das gilt auch bei Tabellen- und Feldnamen. Einen Plural im Tabellennamen finde ich nützlich. Er zeigt dem Verwalter (ich rede BTW nicht vom Endanwender, auch oben nicht) auf intuive Weise an, dass es sich um einen Tabellennamen handelt, wenn er z.B. in SQL damit hantieren muss. Hier kann ich jetzt nicht ganz folgen, auf was du dich beziehst. -- 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: Re: Re: Datenbank: Werk eines Komponisten
Robert Großkopf schrieb: http://www.scoolonline.de/download/Musik_Klassik.odb Zu Primärschlüsseln: Du verwendest auch in Tabellen mit nur einem Datenfeld (Beispiel Tabelle Form) zusätzlich einen Primärschlüssel. Jeder Datensatz enthält dort jedoch einen anderen Wert. Dubletten kommen nicht vor. http://borumat.de/+screenshots/sc-052.png Kann daher das Datenfeld Form nicht selbst als Primärschlüssel dienen? Dann wäre eigentlich die ganze Tabelle überflüssig. Denn wenn Du nur die Form wie Gesang oder Orchester in der Tabelle führst ergibt sich bei der Haupttabelle zwangsläufig, dass genau dieser Begriff dort eingetragen werden muss Eben. - und eben nicht eine (speicherplatzschonende) Ziffer. Dies ist ein Argument aus Sicht der Maschine. Das stelle ich nur fest, und kritisiere es selbstverständlich nicht. Wie ich schon in einem anderen Thread erwähnte, kann ich nicht beurteilen, ob sich sowas per Caching oder anderen technischen Verfahren, die sich mit Redundanz und Komprimierung beschäftigen, lösen liesse (ganz abgesehen davon, ob das jemand will). Sobald Du dann die Begriffe aus irgendeinem Grund ändern würdest, Das überzeugt mich. Denn hier meinst Du ja ändern im Sinne von Änderung unter Wahrung der Konsistenz des gesamten Datenbestandes. Es soll also nicht das eine Stück mit Kammermusik, ein anderes der gleichen Form jedoch mit chamber music bezeichnet werden dürfen. Und eine andere Integrität müsste auch sichergestellt werden: gleiche Sprache in einem Feld. Dieses Änderungspotential existiert beim Feld Jahr nicht. Es ist fix. würde Dir die Datenbank in etwa mitteilen, dass die Änderung aufgrund von Beziehungen zu anderen Tabellen (hier: Work) nicht möglich ist - es sei denn, Du lässt automatisch alle Begriffe in Work auch ersetzen. So arbeitet man eben in einer Tabellenkalkulation. In der Datenbank soll es eleganter und robuster gelöst werden. Danke für Deine Argumentation. Nochmal zu der bisher ungelösten Aufgabe der besten Abbildung der Abhängigkeit der Felder LengthIndetermination und ComponentLengthIndetermination (ich habe die Bezeichner präzisiert): http://borumat.de/+temp/openoffice/rohdaten-simon-barber-work.ods Könnte ein zusätzliches Feld HasComponents die Sache lösen? Die zweiten Normalform spricht ja nur von Daten innerhalb /einer/ Tabelle: Daten, die in der gleichen Tabelle stehen, dürfen nicht voneinander abhängig sein. Allerdings hängt der Wahrheitswert von Work.HasComponents von der Existenz eines Inhaltes in WorkComponent.Name ab. In der abzubildenden Wirklichkeit ist das Aufteilen von Super-Objekte und Sub-Objekte nichts Besonderes. Daher vermute ich, dass es für diese Standard-Aufgabe auch eine etablierte Standard-Lösung gibt. Mir ist bisher noch nicht klar, ob man solche Zusammenhänge allein via Constraints abbildet oder besser allein mit entsprechenden Relationen. 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: Re: Re: Datenbank: Werk eines Komponisten
Matthias Müller schrieb: 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. Kannst Du bitte ein konkretes Beispiel nennen, wo eine nicht sinnvolle Reihenfolge und schlechte Bezeichner von Datenfeldern die Wartbarkeit der Tabelle /nicht/ verschlechtern? Der Endanwender sieht den Entwurf, die Datenbank nicht. Er sieht Formulare und Ein- und Ausgabemasken. Der Entwickler der Datenbank entscheidet wie Datenfalder angeordnet werden. Die DB-Engine macht bestimmte Vorgaben, zB weil durch sie fest liegt, wie bestimmte Datentypen verarbeitet werden. Der Resourceverbrauch spielt eine Rolle mit. Und nicht zuletzt die interne Repräsentation des DB hat entscheidenden Anteil, was aus den Tabellen wird. Die anderen haben auch das eine oder andere Argument. Letztendlich ist es egal ob du die Tabelle ORT mit der Spaltenreihenfolge PLZ, ORTSNAME oder ORTSNAME,PLZ definierst. Insgesamt habe ich mich hier bereits überzeugen lassen, dass die Reihenfolge und Benennung nicht überbewertet werden soll. Aber ich kann es mir bei Deinem Beispiel nicht verkneifen: Das Bessere ist der Feind des Guten. Hier könnte es sein: Orte ID (primary key) PLZ Name Oder würdet ihr den Schlüsselkandidat PLZ als Primärschlüssel empfehlen, weil er sozusagen einen sprechenden/natürlichenr Schlüssel darstellt? In der wirklichen Welt (in Deutschland), kommt fast überall die Postleitzahl vor dem Ort. Konventionen sollte man nicht ohne guten Grund brechen, oder? Und wenn die Tabelle schon Ort heißt, braucht man IMHO diesen Namensteil nicht mehr im Feldnamen wiederholen. Einen Plural im Tabellennamen finde ich nützlich. Er zeigt dem Verwalter (ich rede BTW nicht vom Endanwender, auch oben nicht) auf intuive Weise an, dass es sich um einen Tabellennamen handelt, wenn er z.B. in SQL damit hantieren muss. btw: Das ist einer der spannendsten Threads in der letzten Zeit. :) 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: Re: Re: Datenbank: Werk eines Komponisten
Robert Großkopf schrieb: Kann daher das Datenfeld Form nicht selbst als Primärschlüssel dienen? Dann wäre eigentlich die ganze Tabelle überflüssig. Denn wenn Du nur die Form wie Gesang oder Orchester in der Tabelle führst ergibt sich bei der Haupttabelle zwangsläufig, dass genau dieser Begriff dort eingetragen werden muss - und eben nicht eine (speicherplatzschonende) Ziffer. Ich schlage von dieser Ziffer, die als Primärschlüssel dient, nochmal den Bogen zum Thema Schlüssel. Spricht in Deiner Tabelle Work etwas dagegen, auf den Surrogat(primär)schlüssel ID zu verzichten und den sprechenden Schlüsselkandidaten Werksnummer als Primärschlüssel zu verwenden? Die Werksnummer wird sich schließlich auch in Zukunft nicht ändern. Das hat mir der Komponist bestätigt. Und in Deiner Tabelle WorkPart: Spricht etwas dagegen, dort einen Verbundschlüssel als Primärschlüssel zu verwenden? Es böte sich der Verbund aus dem Merkmal Werksnummer und Werksteilnummer an? Auch für die Werksteilnummer gilt: sie ändert sich nicht mehr. Mit anderen Worten: Sollte man nicht, wo es ohne Nachteile möglich ist, auf künstliche Primärschlüssel (Surrogatschlüssel) verzichten? 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: Re: Re: Datenbank: Werk eines Komponisten
Hallo Andreas, Spricht in Deiner Tabelle Work etwas dagegen, auf den Surrogat(primär)schlüssel ID zu verzichten und den sprechenden Schlüsselkandidaten Werksnummer als Primärschlüssel zu verwenden? Die Werksnummer wird sich schließlich auch in Zukunft nicht ändern. Das hat mir der Komponist bestätigt. Und in Deiner Tabelle WorkPart: Spricht etwas dagegen, dort einen Verbundschlüssel als Primärschlüssel zu verwenden? Es böte sich der Verbund aus dem Merkmal Werksnummer und Werksteilnummer an? Auch für die Werksteilnummer gilt: sie ändert sich nicht mehr. Mit anderen Worten: Sollte man nicht, wo es ohne Nachteile möglich ist, auf künstliche Primärschlüssel (Surrogatschlüssel) verzichten? Natürlich geht genauso gut die Werknummer. Die wird ja zuerst dem Werk zugeordnet und dann automatisch in die Tabelle für die Werkteile übertragen. Auch ein Verbund aus Werknummer und einem Zusatz in der anderen Tabelle ist möglich. Es ist eben die Frage, ob diese Dinge wirklich gebraucht werden. Da ich nicht von der Wichtigkeit der Nummern ausgegangen bin habe ich mir mit der Automatik die entsprechenden Eingabefelder erspart. Außerdem führt dann die Eingabe von Dopplern oder das Fehlen der entsprechenden Eingabe zuerst einmal zu Fehlermeldungen, die für den Anwender häufig nicht verständlich sind. Gruß Robert - To unsubscribe, e-mail: users-unsubscr...@de.openoffice.org For additional commands, e-mail: users-h...@de.openoffice.org
[de-users] Re: Re: Re: Datenbank: Werk eines Komponisten
Mechtilde schrieb: Andreas Borutta schrieb: [Entwerfen einer Tabelle] [...] Aber welchen Nutzen hat dann Base, sobald man ein MySQL-Datenbankmanagementsystem verwendet? Base ist ein Frontend, das einem Hilfestellungen geben kann, eine Oberfläche zu erstellen, Du meinst hier mit Oberfläche Formulare und Berichte, richtig? Ich bezog mich - in erster Linie und zunächst - allein auf das Entwerfen von Tabellen. Wenn ich es richtig verstanden habe, sollte man mit der GUI von Base weder einen Tabellenentwurf für MySQL erstellen Entwerfen - nein OK, dann war mein Verständnis richtig. Erstellen - ja Hiermit meinst Du das Einpflegen von Daten in Felder ohne ein dafür manuell angefertigtes Formular, also in dem Interface Table Date View, richtig? Jetzt stellt sich die Frage, ob sich diese Aufgabe mit Base besser erledigen lässt als mit PHPmyAdmin? Hintergrund der Frage: ich suche momentan nach geeigneten Werkzeugen. Da mich zunächst allein MySQL-Datenbanken interessieren, für welche später einmal Webformulare erstellt werden sollen, ist für mich noch offen, ob Base ein geeignetes/ empfehlenswertes Werkzeug für mich ist. noch Relationen knüpfen (Datenbankentwurf normalisieren), richtig? Datenbankentwurf normalisieren macht man auf dem Papier Die Relationen zwischen den einzelnen Tabellen können in Base dann erstellt werden. OK. Also offenbar auch dann, wenn es sich um eine MySQL-DB handelt. 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: Re: Re: Datenbank: Werk eines Komponisten
Guenter Wallnig schrieb: Linux User 06/2006, S. 48: Datenbanken mit OpenOffice Habe ich mir angesehen. Aber wenn ich den Text richtig interpretiere, siehe auch meine Antwort auf Mechthilds Posting, dann lohnt Base bei der Verwendung einer MySQL-DB nur dann, wenn man a Formulare für Writer erstellen will oder b Daten in Calc einbinden möchte Ich lasse mich gerne korrigieren. Im Moment nutze ich nicht Linux, sondern Windows. Daher kommen Werkzeuge, die allein für Linux bereitstehen, nicht in Frage. Ich werde quelloffene freie Werkzeuge vorziehen, die plattformübergreifend oder -unabhängig bereit 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: Re: Re: Datenbank: Werk eines Komponisten
Hallo Andreas, Andreas Borutta schrieb: Mechtilde schrieb: Andreas Borutta schrieb: [Entwerfen einer Tabelle] [...] Aber welchen Nutzen hat dann Base, sobald man ein MySQL-Datenbankmanagementsystem verwendet? Base ist ein Frontend, das einem Hilfestellungen geben kann, eine Oberfläche zu erstellen, Du meinst hier mit Oberfläche Formulare und Berichte, richtig? in erster Linie Ja Ich bezog mich - in erster Linie und zunächst - allein auf das Entwerfen von Tabellen. Wenn ich es richtig verstanden habe, sollte man mit der GUI von Base weder einen Tabellenentwurf für MySQL erstellen Entwerfen - nein OK, dann war mein Verständnis richtig. Erstellen - ja Hiermit meinst Du das Einpflegen von Daten in Felder ohne ein dafür manuell angefertigtes Formular, also in dem Interface Table Date View, richtig? Nein. Vielleicht lässt sich das mit den zwei Begriffen nicht so genau abgrenzen. Mit Entwerfen meine ich, sich Gedanken über die grundsätzliche Struktur zu machen Ernst H. hat dies gerade in einer Mail so treffend beschrieben: Das 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. Mit Erstellen meine ich nicht die Eingabe der Daten. Dies ist - wie bereits schon mehrfach gesagt wurde - in einer Tabellenansicht sehr aufwendig. Dazu benutzt man besser Formulare oder Dialoge. Mit Erstellen meine ich schon das Erstellen der Tabellen in der Entwurfsansicht. Und dies *nachdem* die Struktur auf Papier o.ä ausgearbeitet wurde. Jetzt stellt sich die Frage, ob sich diese Aufgabe mit Base besser erledigen lässt als mit PHPmyAdmin? Hintergrund der Frage: ich suche momentan nach geeigneten Werkzeugen. Da mich zunächst allein MySQL-Datenbanken interessieren, für welche später einmal Webformulare erstellt werden sollen, ist für mich noch offen, ob Base ein geeignetes/ empfehlenswertes Werkzeug für mich ist. Die entscheidung dafür kann Dir niemand abnehmen. Dazu muss Du Dir überlegen, was Du anschließend brauchst. Und davon hängt auch die Wahl des Werkzeuges ab. noch Relationen knüpfen (Datenbankentwurf normalisieren), richtig? Datenbankentwurf normalisieren macht man auf dem Papier Die Relationen zwischen den einzelnen Tabellen können in Base dann erstellt werden. OK. Also offenbar auch dann, wenn es sich um eine MySQL-DB handelt. Ja und wie das erfolgt, hängt von der verwendetn Engine in MySQl ab. Am Schluss vielleicht noch ein kurzes scenario, warum ich mich für Base entschieden habe. Wenn ich Daten aus der Datenbank in einem Writer oder Calc Dokument weiterverarbeiten will, ist es praktikabler, auch die Dateneingabe in Base zu gestalten. Besonders wenn beides kontinuierlich notwendig ist. Soll es eine Webanwendung zur Verarbeitung der Daten werden, dann sollte analog die Dateneingabe auch in dieser Webanwendung möglich sein. Auf die Sicherheitsprobleme einer Webanwendung möchte ich an dieser Stelle nicht eingehen. Gruß Mechtilde -- Dipl. Ing. Mechtilde Stehmann ## http://de.openoffice.org ## Ansprechpartnerin für die deutschsprachige QA ## Freie Office-Suite für Linux, Mac, Windows, Solaris ## Meine Seite http://www.mechtilde.de ## PGP encryption welcome! Key-ID: 0x53B3892B - To unsubscribe, e-mail: users-unsubscr...@de.openoffice.org For additional commands, e-mail: users-h...@de.openoffice.org
[de-users] Re: Re: Re: Datenbank: Werk eines Komponisten
Robert Großkopf schrieb: mit den Jahreszahlen gibt es natürlich keine Probleme, wenn die Datenbank explizit diesen Datentyp besitzt (ist bei MySQL der Fall MySQL strebe ich an. (Eben habe ich erfolgreich XAMPP und MySQL GUI Tools installiert. Hätte nie gedacht, dass sowas reibunglos abläuft :) nicht aber bei HSQLDB). Bei MySQL könnte dann die zweistellige Angabe ausreichen. Das würde übersetzt in 1970-2069. Ich halte die Einschränkung Genau vier Ziffern oder leer (falls das Jahr unbekannt ist) für sinnvoll - für die Zielgruppe. Langwierige Erklärungen, wie zweistellige Angaben genau übersetzt werden, verwirren nur. Zudem entstehen Kompositionen nicht in derart großer Zahl. Da sind die paar Ziffern zu verschmerzen, denke ich. 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: Re: Re: Datenbank: Werk eines Komponisten
Robert Großkopf schrieb: Geklärtes gesnipt. 1 Rechtfertigung für weitere Tabellen Du verwendest in Tabelle Work für $Year ein Datenfeld, speist jedoch die Gattung (Form) via ID ein. Auch gleiche Werte für Jahr kommen vor. [...] Handelt es sich dabei um eine Frage des Geschmacks oder gibt es objektive Kriterien für eine Entscheidung. Ist wohl wirklich eine Frage des Geschmacks. Ich habe in dieser Liste auch schon Meinungen gehört, z.B. für Adressdaten einfach alles in eine Tabelle zu packen. Grundlage einer Datenbank mit Beziehungsstrukturen ist aber eigentlich, Doubletten vor allem längerer Feldinhalte zu vermeiden. Danke. Das lasse ich mal sacken. Man kann ahnen, dass hinter den Entscheidungstyp Neue Tabelle einige Erfahrung steckt und keine objektive allgemeingültige Antwort möglich ist. 2 WorkLengthTruth und WorkPartLengthTruth Hier gibt es eine Abhängigkeit. Zur Zeit wird diese noch nicht durch die Struktur abgebildet. Beispiel: Work.LengthTruth kann den Wert WAHR enthalten, während gleichzeitig WorkPart.LengthTruth, bei einem Werksteil des gleichen Werkes, den Wert FALSCH einnehmen kann. Logisch ist das verboten. Einfachste Möglichkeit wäre wohl, die LengthTruth-Eigenschaft aus WorkPart auszulesen und dann über eine Abfrage im Hauptformular anzuzeigen Dabei ist das Problem, dass Werke, die keine Werksteile enthalten, demnach auch keinen Wert in WorkPartLengthTruth. WorkLengthTruth könnte also nicht ermittelt werden. In anderen Worten: Auf das Datenfeld WorkLengthTruth kann beim aktuellen Stand nicht verzichtet werden. Aber vielleicht gibt es ja noch eine elegante Lösung rund um den Genaue Angabe, ungefähre Angabe. (ähnlich der momentanen Anzeige der fehlenden/überschüssigen Sekunden) Die Ursache der überschüssigen Sekunden haben sich aufgeklärt. Der Komponist hatte Längenangaben inkonsistent gerundet. Werksteile hat er nicht gerundet. Werke schon. Die Rohdaten sind entsprechend überarbeitet. http://borumat.de/+temp/openoffice/rohdaten-simon-barber-work.ods Kleinigkeit am Rande: Wie schreibt man eigentlich in der richtigen Syntax über Datenfeld 'LenghtTruth' der Tabelle 'WorkPart' der Datenbank 'SimonBarberWork', damit man sich eindeutig verständigen kann? Irgendwas in der Form SimonBarberWork.WorkPart.LengthTruth? Also [Datenbankdatei].[Tabellenname].[Datenfeldname]? Sieh Dir dazu die Abfrage LegthDiff an: Length_Work.ID OK. Die Anführungszeichen dürfen also trotz Abwesenheit von Leerzeichen in den Namen nicht weggelassen werden? 3 Nummerierung der Werksteile/ Primärschlüssel Du hattest ja schon geschrieben, dass von Primärschlüsseln abzuraten ist, die aus einem Datentyp als INTEGER bestehen. In den Rohdaten tragen Werksteile IDs, die sehr klar und gut lesbar sind: 7a, 7b, etc. In Deiner Datenbank tragen die Werksteile IDs, die keine Schluss auf die Zugehörigkeit zu einem Werk erlauben. Ist es in einem solchen Fall empfehlenswert die sprechende ID manuell als zusätzliches Datenfeld einzuführen. Die Verbindung erfolgt doch sichtbar im Formular. Wenn Du die Untergliederungen der Tabelle der Unterformulars mit a,b,c usw. sortieren willst, so muss natürlich diese Sortierung noch zusätzlich in die Tabelle WorkPart eingegeben werden. Wir haben uns aufgrund der Sortierproblematik entschieden, auf die alphabetischen Werkstteilnummern zu verzichten. Sie werden jetzt nummeriert. Die Werksnummer entspricht schon jetzt der ID. Fast. Die ID muss nur noch statt bei 0, bei 1 beginnen. Das kann offenbar für den Autozähler nicht per GUI in Base eingestellt werden. Man muss wohl einfach die erste ID manuell setzen, oder? Bei Werksteilen sieht es anders aus. Hier käme als ID ein zusammgesetzter Wert in Frage: 40.3 Spricht etwas dagegen? Den Bogen nochmal zur grundlegenden Struktur: Denkbar wäre eine Tabelle, die keine statische Zahl von Datenfeldern enthält, sondern wo die Anzahl dynamisch ist. Dann könnte auf die Tabelle workpart verzichtet werden. Nein, ich behaupte natürlich nicht, dass das besser ist. Ich überlege nur laut. Tabelle work: ID Name Length PartName_1 PartName_2 ... PartName_n PartLength Form 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. OK. Vermutest Du da einen Bug in Base? Das scheint mir ein Bug zu sein. Ich habe mich nur gewundert, dass alle Felder auf 1904 standen und eine Angabe von 1998 nicht angenommen wurde. Dann habe ich das ganze Datum sichtbar gemacht. Dort standen dann irgendwelche Komplettdaten, die anscheinend aus der Jahreszahl konstruiert wurden. Hier ließ sich dann auch die Jahreszahl ändern und anschließend wieder anzeigen. Vielleicht ist das aber auch ein Übertragungsproblem von Calc nach Base. Hier wird wohl nicht die Formatierung des Base-Feldes berücksichtigt, sondern aus 1998 ein komplettes Datum gebildet. Ob die Neueingabe mit
[de-users] Re: Re: Re: Datenbank: Werk eines Komponisten
Robert Großkopf schrieb: Klar. Aber welchen Nutzen hat dann Base, sobald man ein MySQL-Datenbankmanagementsystem verwendet? Die Tabellen erstellst Du dann in dem anderen System, mit Base greifst Du auf die Tabellen lesend, suchend und schreiben zu, führst auch Abfragen durch. Wenn ich es richtig verstanden habe, sollte man mit der GUI von Base weder einen Tabellenentwurf für MySQL erstellen noch Relationen knüpfen (Datenbankentwurf normalisieren), richtig? Relationen werden in MySQL nicht von allen Tabellentypen unterstützt. Gerade der Standardtabellentyp MyISAM hat mit irgendeiner Realtionendefinition nichts am Hut. Diese Definition machst Du anschließend mit Deinem Formular und Deinen Abfragen. Für richtige Relationen musst Du z.B. InnoDB-Tabellen wählen. 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 -- 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: Re: Re: Datenbank: Werk eines Komponisten
Hallo Andreas, 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. Das geht auf jeden Fall. Nur solltest Du möglichst nicht die Tabellen von der Struktur her bearbeiten wollen. Aber: Schreibender Zugriff auf einzelne Tabellen macht eigentlich nur dann Sinn, wenn in der Tabellen nicht irgendwelche Fremdschlüssel enthalten sind (Tabellen in dem Entwur Work und WorkPart). Wie gut es mit dem Schutz der Autowert-Felder (nennt sich in MySQL autoinkrement) bestellt ist weiß ich nicht, Würde ich bei der Tabelle einfach ausblenden, damit nicht aus versehen ein Wert geändert wird. Gruß Robert - To unsubscribe, e-mail: users-unsubscr...@de.openoffice.org For additional commands, e-mail: users-h...@de.openoffice.org
[de-users] Re: Re: Re: Datenbank: Werk eines Komponisten
Volker Heggemann schrieb: Zu Primärschlüsseln: Du verwendest auch in Tabellen mit nur einem Datenfeld (Beispiel Tabelle Form) zusätzlich einen Primärschlüssel. Jeder Datensatz enthält dort jedoch einen anderen Wert. Dubletten kommen nicht vor. http://borumat.de/+screenshots/sc-052.png Kann daher das Datenfeld Form nicht selbst als Primärschlüssel dienen? [Geschwindigkeit] Hhmm. Ich schätze es, wenn Bedürfnisse von Maschinen (hier ist es: Ressourcenverbrauch) im Untergrund befriedigt werden, wenn es vermeidbar ist, die menschlichen Verwalter damit zu belästigen. Anders: könnte eine Datenbank sowas nicht unbemerkt intern abwickeln? Lange Primärschlüssel auf kürzere mappen? Ich sollte als Anfänger zu sowas schweigen, damit mich hier niemand als vorlaut einschätzt ;) Andreas, CNR Falls sich jemand für das interessiert, wofür das dienende Werkzeug DB einmal eingesetzt werden soll, für Neue Musik: http://neu.simon-barber.com/mp3/ (Es handelt sich um eine Subdomain, auf der Entwürfe für die neue Site gelagert werden. Alle anderen eventuell erreichbaren Seiten dieser Subdomain sind also nichts als Skizzen.) -- 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: Re: Re: Datenbank: Werk eines Komponisten
Andreas Borutta schrieb: Volker Heggemann schrieb: Zu Primärschlüsseln: Du verwendest auch in Tabellen mit nur einem Datenfeld (Beispiel Tabelle Form) zusätzlich einen Primärschlüssel. Jeder Datensatz enthält dort jedoch einen anderen Wert. Dubletten kommen nicht vor. http://borumat.de/+screenshots/sc-052.png Kann daher das Datenfeld Form nicht selbst als Primärschlüssel dienen? [Geschwindigkeit] Hhmm. Ich schätze es, wenn Bedürfnisse von Maschinen (hier ist es: Ressourcenverbrauch) im Untergrund befriedigt werden, das schön (das du es schätzt) es wird aber nicht im Untergrund passieren! Denn wenn deine Maschine xxl Lange Primärschlüssel und Relationen auflösen muß, dann rödelt sie wie verrückt auf der Festplatte herum! Und - wird langsam. Und diese verhalten steigt mit einer größeren Anzahl an Daten und längeren Schlüsseln exponential an! wenn es vermeidbar ist, die menschlichen Verwalter damit zu belästigen. Insofern wir auch der Menschliche Verwalter damit belästigt, da er in dieser Zeit dann des öfteren Kaffee kochen muß. Anders: könnte eine Datenbank sowas nicht unbemerkt intern abwickeln? Lange Primärschlüssel auf kürzere mappen? Wie? mfg Volker - To unsubscribe, e-mail: users-unsubscr...@de.openoffice.org For additional commands, e-mail: users-h...@de.openoffice.org
[de-users] Re: Re: Re: Datenbank
Hallo, ich komme aus dem Grenzgebiet zu Dänemark, Niebüll-Flensburg. Was mich nun aber wirklich wurmt, das wenn ich Importe aus Calc heraus ausführe alles ordentlich abläuft, wenn ich aber dann versuche einen Primärschlüssel einzubauen, dass sich dann an dieser Stelle base quer stellt. Wenn ich die Spaltenüberschrift Short als Primärschlüssel vergeben will, kommt der Hinweis das dies nicht möglich ist. Vielmehr wird gelöscht und neu angehängt? Wieso denn diese Reaktion des Programmes? Gruß Alfons Am 04.02.2007, 13:46 Uhr, schrieb Mechtilde [EMAIL PROTECTED]: Allo Alfons, Alfons Mair wrote: Hallo, nun habe ich mir die Anleitung durchgelesen, aber ich habe trotzdem folgendes Problem: Hast Du dir die Beispieldatenbank europa.odb angeschaut? Ganz besonders sowohl die Tabellen als auch die Formulare in der Entwurfsansicht? Bei den Formularen kannst dir von jeder Spalte die Eigenschaften (Spalte...) anzeigen lassen. Ich habe nun 1 Tabelle aufgebaut welche folgende Spalten beinhaltet: ID = Primärschlüssel welcher Feldtyp? Text-ID = Text Text-ID Type = Text Text scheint mir hier problematisch Validity from = Date Validity until = Date Language = Text Export Country = Text Import Country = Text Certified Invoice Text = Text Tabelle 2 versuche ich aus Calc zu übernehmen, was mir allerdings nur ansatzweise gelingt: ID = Primärschlüssel ISO 3166 ALPHA-2 Diese Spaltenbezeichnung wird schon nicht funktionieren. Welcher Feldtyp? Country name ISO 3166 ALPHA-3 ISO 3166 numerisch TLD IOC ISO 3166-2 UN/LOCODE Auch hier fehlen die Feldtypen? Ich gehe davon aus, dass alle Tabellen mit der internen HSQL DB erstellt wurden. Alle übrigen Spalten sind Text-Spalten. Ich wundere mich nun nur ein wenig wie es denn sein kann, dass die Primärschlüssel jeweils mit 1,2 und 3 anfangen, eigentlich kann das doch so garnicht sein? Ich versuche nämlich den ISO 3166 ALPHA-2 Code zum Primärschlüssel umzuwandeln, aber das will nicht funktionieren. Hast Du event. Autowert aktiviert? Ist denn womöglich der komplette Ansatz verkehrt, ich habe so meine Bedenken bei den Feldern Language, Export Country und Import Country diese sollen letztendlich mit dem ISO 3166 ALPHA-2 gefüttert werden. Dies kann nur über das Formular erfolgen Aus welcher Gegend kommst Du, vielleicht wäre ein Real-Treffen möglich. Gruß Mechtilde - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [de-users] Re: Re: Re: Datenbank
Hallo Alfons, Alfons Mair wrote: Hallo, ich komme aus dem Grenzgebiet zu Dänemark, Niebüll-Flensburg. Was mich nun aber wirklich wurmt, das wenn ich Importe aus Calc heraus ausführe alles ordentlich abläuft, wenn ich aber dann versuche einen Primärschlüssel einzubauen, dass sich dann an dieser Stelle base quer stellt. Wenn ich die Spaltenüberschrift Short als Primärschlüssel vergeben will, kommt der Hinweis das dies nicht möglich ist. Vielmehr wird gelöscht und neu angehängt? Wieso denn diese Reaktion des Programmes? Ich möchte Dir ja gerne helfen. Dazu ist es unabdingbar, dass Du meine Frage auch beantwortest. Ansonsten kann ich nur raten, was Du vorhast. Base bietet sehr viele verschiedene Möglichkeiten ein Problem anzugehen bzw zu lösen. Um Dir dies zu erleichtern habe ich den wichtigsten Teil dazu nochmal unten angehängt. und jeweils als Frage gekennzeichnet. nun habe ich mir die Anleitung durchgelesen, aber ich habe trotzdem folgendes Problem: Fragen Hast Du dir die Beispieldatenbank europa.odb angeschaut? Ganz besonders sowohl die Tabellen als auch die Formulare in der Entwurfsansicht? /Fragen Bei den Formularen kannst dir von jeder Spalte die Eigenschaften (Spalte...) anzeigen lassen. Ich habe nun 1 Tabelle aufgebaut welche folgende Spalten beinhaltet: ID = Primärschlüssel Frage / welcher Feldtyp? Text-ID = Text Text-ID Type = Text Kommentar / Text scheint mir hier problematisch Validity from = Date Validity until = Date Language = Text Export Country = Text Import Country = Text Certified Invoice Text = Text Tabelle 2 versuche ich aus Calc zu übernehmen, was mir allerdings nur ansatzweise gelingt: ID = Primärschlüssel ISO 3166 ALPHA-2 Diese Spaltenbezeichnung wird schon nicht funktionieren. Welcher Feldtyp? Country name ISO 3166 ALPHA-3 ISO 3166 numerisch TLD IOC ISO 3166-2 UN/LOCODE Auch hier fehlen die Feldtypen? Ich gehe davon aus, dass alle Tabellen mit der internen HSQL DB erstellt wurden. Alle übrigen Spalten sind Text-Spalten. Ich wundere mich nun nur ein wenig wie es denn sein kann, dass die Primärschlüssel jeweils mit 1,2 und 3 anfangen, eigentlich kann das doch so garnicht sein? Ich versuche nämlich den ISO 3166 ALPHA-2 Code zum Primärschlüssel umzuwandeln, aber das will nicht funktionieren. Frage / Hast Du event. Autowert aktiviert? Ist denn womöglich der komplette Ansatz verkehrt, ich habe so meine Bedenken bei den Feldern Language, Export Country und Import Country diese sollen letztendlich mit dem ISO 3166 ALPHA-2 gefüttert werden. Dies kann nur über das Formular erfolgen Bitte die Fragen und Kommentare unbedingt beantworten. 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]
[de-users] Re: Re: Re: Datenbank, Erfassungsformular
Hi Mechtilde Meine SQL-Statements liefern Fehlermeldungen, die ich nicht verstehe. Ich kenne nur ganz rudimentäre SQL-Befehle. Was bedeutet ID AS? Aber bevor wir uns hier allzusehr verbiegen: Mit dem Wizzard habe ich folgende Listenfelddefinition hinbekommen: Wenn die Warengruppen-Nr. im Datensatz von Artikel mit der Warengruppen-Nr. im Datensatz WarenGruppen übereinstimmt, dann zeige mir den Text aus der Tabelle WarenGruppen an, der zu der Warengruppen-Nr. gehört. Ist das das, was Du mir erklären wolltest? Was ich suche ist nämlich etwas anderes: Zum einen geht es darum, eine Warengruppen-Nr. in der Tabelle WarenGruppen zu suchen und ins Feld Warengruppen-Nr. des Artikel-Datensatzes zu übernehmen. Es geht also nicht um die Anzeige im Formular, sondern um die Übernahme des Feldinhaltes der WarenGruppen-Tabelle in das entsprechende Feld im Artikel-Datensatz. So, wie ich die Kontrollfelder bisher begreife, geht das nur mit Kombinationsfeldern. Dort gibt es eine Option Wert in einem Datenbankfeld speichern. So etwas habe ich bei den Listenfeldern nicht gefunden. Kann man das überhaupt mit Listenfeldern bewerkstelligen? Was ich nun könnte, wäre: per Kombinationsfeld eine Warengruppen-Nr. in meinen Artikel-Datensatz übernehmen und per Listenfeld über den Vergleich der Warengruppen-Nr. des Artikels mit derjenigen aus der WarenGruppen-Tabelle den zugehörigen Text anzeigen. Mein eigentliches Problem ist aber das: Wenn ich einen Artikel einer Warengruppen-Nr. zuordnen soll (also noch bevor der Artikel-Datensatz eine Warengruppen-Nr. hat, die mit der WarenGruppen-Tabelle abgeglichen werden könnte), möchte ich nicht nur eine Liste der Warengruppen-Nummern angezeigt bekommen, wie das mit dem Kombinationsfeld möglich ist, sondern ich möchte die Texte sehen, die hinter diesen Warengruppen-Nummern stehen, um dann die richtige Gruppen-Nr. auswählen zu können. Ich (der Mensch) kann die Warengruppen-Zugehörigkeit eines Artikels anhand des Warengruppen-Textes identifizieren, kenne aber die Gruppen-Nr. nicht, die im Artikel-Stammsatz hinterlegt werden muss, um den Artikel richtig zuzuordnen. Es müsste also so gehen: zeige mir die Texte aus der WarenGruppen-Tabelle an und wenn ich dann so einen Text ausgewählt habe: schreibe mir die zugehörige Warengruppen-Nr. ins zuständige Feld des Artikel-Datensatzes. Gruss, Claudia - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [de-users] Re: Re: Re: Datenbank, Erfassungsformular
Hallo Claudia, Claudia Drechsle wrote: Hi Mechtilde Meine SQL-Statements liefern Fehlermeldungen, die ich nicht verstehe. Ich kenne nur ganz rudimentäre SQL-Befehle. Was bedeutet ID AS? Sorry ID = Warengruppennummer Aber bevor wir uns hier allzusehr verbiegen: Mit dem Wizzard habe ich folgende Listenfelddefinition hinbekommen: Wenn die Warengruppen-Nr. im Datensatz von Artikel mit der Warengruppen-Nr. im Datensatz WarenGruppen übereinstimmt, dann zeige mir den Text aus der Tabelle WarenGruppen an, der zu der Warengruppen-Nr. gehört. Ist das das, was Du mir erklären wolltest? Was ich suche ist nämlich etwas anderes: Zum einen geht es darum, eine Warengruppen-Nr. in der Tabelle WarenGruppen zu suchen und ins Feld Warengruppen-Nr. des Artikel-Datensatzes zu übernehmen. Es geht also nicht um die Anzeige im Formular, sondern um die Übernahme des Feldinhaltes der WarenGruppen-Tabelle in das entsprechende Feld im Artikel-Datensatz. So, wie ich die Kontrollfelder bisher begreife, geht das nur mit Kombinationsfeldern. Dort gibt es eine Option Wert in einem Datenbankfeld speichern. So etwas habe ich bei den Listenfeldern nicht gefunden. Kann man das überhaupt mit Listenfeldern bewerkstelligen? Was ich nun könnte, wäre: per Kombinationsfeld eine Warengruppen-Nr. in meinen Artikel-Datensatz übernehmen und per Listenfeld über den Vergleich der Warengruppen-Nr. des Artikels mit derjenigen aus der WarenGruppen-Tabelle den zugehörigen Text anzeigen. Mein eigentliches Problem ist aber das: Wenn ich einen Artikel einer Warengruppen-Nr. zuordnen soll (also noch bevor der Artikel-Datensatz eine Warengruppen-Nr. hat, die mit der WarenGruppen-Tabelle abgeglichen werden könnte), möchte ich nicht nur eine Liste der Warengruppen-Nummern angezeigt bekommen, wie das mit dem Kombinationsfeld möglich ist, sondern ich möchte die Texte sehen, die hinter diesen Warengruppen-Nummern stehen, um dann die richtige Gruppen-Nr. auswählen zu können. Willst Du an dieser Stelle auch editieren oder willst Du Dir den Status nur anzeigen lassen? Im zweiten Fall kannst Du eine entsprechende Abfrage erstellen und daraufhin ein Formular. Ich (der Mensch) kann die Warengruppen-Zugehörigkeit eines Artikels anhand des Warengruppen-Textes identifizieren, kenne aber die Gruppen-Nr. nicht, die im Artikel-Stammsatz hinterlegt werden muss, um den Artikel richtig zuzuordnen. Es müsste also so gehen: zeige mir die Texte aus der WarenGruppen-Tabelle an und wenn ich dann so einen Text ausgewählt habe: schreibe mir die zugehörige Warengruppen-Nr. ins zuständige Feld des Artikel-Datensatzes. das geht möglicherweise nur mit einem Makro, da bin ich überfragt. Mechtilde PS: In welcher Gegend von Deutschland kann man Dich denn finden? Vielleicht lassen sich so ein paar Probleme besser lösen. -- 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: Re: Re: Datenbank, Erfassungsformular
Es müsste also so gehen: zeige mir die Texte aus der WarenGruppen-Tabelle an und wenn ich dann so einen Text ausgewählt habe: schreibe mir die zugehörige Warengruppen-Nr. ins zuständige Feld des Artikel-Datensatzes. Gruss, Claudia Hallo Claudia, eine Lösung für Dein Problem habe ich für eine meiner Datenbanken bereits entwickelt. Allerdings kostet es sehr viel Zeit, Dir das so aufzuschreiben, daß Du es nachvollziehen kannst. Daher mein Vorschlag: schicke mir eine Datenbank mit einigen Musterdatensätzen per PM und ich versuche, meine Lösung auf Deine Datenbank zu übertragen. Mit freundlichen Grüßen Jörn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
