Re: [de-users] n:m Relation in Base
Hallo könnte es an den ' liegen? Mechtilde schrieb: > Hallo > Mechtilde schrieb: > CREATE TABLE `AktenAdressen'`(`AktenNr` INTEGER NOT NULL,`AdressenNr` ^ > INTEGER NOT NULL,`PersonengruppenNr` INTEGER NOT NULL,`Reihenfolge` > INTEGER,PRIMARY KEY(`AktenNr`,`AdressenNr`),CONSTRAINT SYS_FK_64 FOREIGN > KEY(`AdressenNr`) REFERENCES `Adressen`(`ID) ON DELETE CASCADE ON UPDATE > CASCADE,CONSTRAINT SYS_FK_79 FOREIGN KEY(`AktenNr`) REFERENCES > `Akten`'(`ID`') ON DELETE CASCADE ON UPDATE CASCADE) ^ ^ > > Mechtilde > > -- Gruß Karl-Heinz ++ WinXP-Pro SP2 OOo 2.0.0-de - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [de-users] n:m Relation in Base
Mechtilde schrieb: > Dabei habe ich festgestellt, dass die Erstellung eines zusammengesetzten > Primärschlüssels geht, wenn die Tabelle mit dem Assistenten erstellt > wird, nicht jedoch in der Entwurfsansicht. > (Das bezieht sich auf MySQL 4.1 via ODBc 3.51.09 und OOo >=2.0.2 Für eine HSQL-Datenbank unter Win kann ich in der Entwurfsansicht beide Felder mit der Strg-Taste markieren und dann über die rechte Maustaste den Primärschlüssel zuweisen Gruß Karl-Heinz ++ WinXP-Pro SP2 OOo 2.0.0-de - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [de-users] n:m Relation in Base
Hallo,
Mechtilde schrieb:
ich teste gerade weiter ;-)
Dabei habe ich festgestellt, dass die Erstellung eines zusammengesetzten
Primärschlüssels geht, wenn die Tabelle mit dem Assistenten erstellt
wird, nicht jedoch in der Entwurfsansicht.
(Das bezieht sich auf MySQL 4.1 via ODBc 3.51.09 und OOo >=2.0.2
Ich verstehe dein Problem nicht so richtig. In HSQL sieht es so aus
CREATE CACHED TABLE "course"("who" INTEGER NOT NULL,"what" INTEGER
NOT NULL,"paid" BOOLEAN,"repeat" BOOLEAN,PRIMARY
KEY("who","what"),CONSTRAINT SYS_FK_64 FOREIGN KEY("what") REFERENCES
"subject"("ID") ON DELETE CASCADE ON UPDATE CASCADE,CONSTRAINT
SYS_FK_79 FOREIGN KEY("who") REFERENCES "pupil"("ID") ON DELETE
CASCADE ON UPDATE CASCADE)
Wo kann ich mir eventuell den SQL-Befehl zum Tabellen-Wizzard anschauen?
Das müsste in MySQL doch ähnlich aussehen, entscheidend ist PRIMARY
KEY("who","what"), dass also die beiden Felder zusammen als Liste als
Parameter zu PRIMARY KEY angegeben werden. Nach MySQL 5.0 Syntax geht
das.
Hast Du zufällig die Fundstelle dazu in der 5.0.er-Referenz.
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
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [de-users] n:m Relation in Base
Hallo
Mechtilde schrieb:
Regina Henschel schrieb:
Hallo Mechtilde,
ich teste gerade weiter ;-)
Ich verstehe dein Problem nicht so richtig. In HSQL sieht es so aus
CREATE CACHED TABLE "course"("who" INTEGER NOT NULL,"what" INTEGER NOT
NULL,"paid" BOOLEAN,"repeat" BOOLEAN,PRIMARY
KEY("who","what"),CONSTRAINT SYS_FK_64 FOREIGN KEY("what") REFERENCES
"subject"("ID") ON DELETE CASCADE ON UPDATE CASCADE,CONSTRAINT
SYS_FK_79 FOREIGN KEY("who") REFERENCES "pupil"("ID") ON DELETE
CASCADE ON UPDATE CASCADE)
Als erste habe ich "Cached" weggelassen und alle doppelten
Anführungszeichen durch Acent grave ersetzt.
Bei mir sieht die SQL-Anweisung dann so aus:
CREATE TABLE `AktenAdressen'`(`AktenNr` INTEGER NOT NULL,`AdressenNr`
INTEGER NOT NULL,`PersonengruppenNr` INTEGER NOT NULL,`Reihenfolge`
INTEGER,PRIMARY KEY(`AktenNr`,`AdressenNr`),CONSTRAINT SYS_FK_64 FOREIGN
KEY(`AdressenNr`) REFERENCES `Adressen`(`ID) ON DELETE CASCADE ON UPDATE
CASCADE,CONSTRAINT SYS_FK_79 FOREIGN KEY(`AktenNr`) REFERENCES
`Akten`'(`ID`') ON DELETE CASCADE ON UPDATE CASCADE)
Dann erscheint folgende Fehlermeldung:
[MySQL][ODBC 3.51 Driver][mysqld-4.1.11-Debian_4sarge2-log]Fehler in
der SQL-Syntax. Bitte die korrekte Syntax im Handbuch nachschlagen
(diese kann für verschiedene Server-Versionen unterschiedlich sein) bei
'AktenNr`) REFERENCES `Akten`'(`ID`') ON DELETE CA
Hier weiß ich leider nicht mehr weiter :-((
Das müsste in MySQL doch ähnlich aussehen, entscheidend ist PRIMARY
KEY("who","what"), dass also die beiden Felder zusammen als Liste als
Parameter zu PRIMARY KEY angegeben werden. Nach MySQL 5.0 Syntax geht
das.
Hast Du zufällig die Fundstelle dazu in der 5.0.er-Referenz.
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
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [de-users] n:m Relation in Base
Regina Henschel schrieb:
Hallo Mechtilde,
Das sieht gut aus, gilt wohl leider nur für HSQL und nicht für MySQL.
Sowohl mit OOo als auch mit PhpMyAdmin lassen sich in MySQL _zwei_
Primärschlüssel angeben.
Das sollte mich wundern. Es ist 1 Primärschlüssel, der aus zwei Feldern
besteht. Kannst du sehen, welches SQL-Kommando benutzt wurde?
In der MySQl-Referenz habe ich bisher auch noch nichts dazu gefunden.
Ich verstehe dein Problem nicht so richtig. In HSQL sieht es so aus
CREATE CACHED TABLE "course"("who" INTEGER NOT NULL,"what" INTEGER NOT
NULL,"paid" BOOLEAN,"repeat" BOOLEAN,PRIMARY
KEY("who","what"),CONSTRAINT SYS_FK_64 FOREIGN KEY("what") REFERENCES
"subject"("ID") ON DELETE CASCADE ON UPDATE CASCADE,CONSTRAINT SYS_FK_79
FOREIGN KEY("who") REFERENCES "pupil"("ID") ON DELETE CASCADE ON UPDATE
CASCADE)
Ich habe versucht,
1. diese SQL-Anweisung unter "Extras -> SQL..." einzugeben in die
Datenbank "school_with"und auszuführen.
-> das funktioniert.
2. diese SQL-Anweisung so abzuwandeln, dass sie in meiner
MySQL-Datenbank funktionieren könnte und das sowohl mit doppelten als
auch mit einfachen Anführungszeichen, wie hier zu sehen:
CREATE CACHED TABLE 'AktenAdressen'('AktenNr' INTEGER NOT
NULL,'AdressenNr' INTEGER NOT NULL,'PersonengruppenNr' INTEGER NOT
NULL,'Reihenfolge' INTEGER,PRIMARY
KEY('AktenNr','AdressenNr'),CONSTRAINT SYS_FK_64 FOREIGN
KEY('AdressenNr') REFERENCES 'Adressen'('ID') ON DELETE CASCADE ON
UPDATE CASCADE,CONSTRAINT SYS_FK_79 FOREIGN KEY('AktenNr') REFERENCES
'Akten'('ID') ON DELETE CASCADE ON UPDATE CASCADE)
-> das funktioniert nicht es kommt folgende Fehlermeldung:
MySQL][ODBC 3.51 Driver][mysqld-4.1.11-Debian_4sarge2-log]Fehler in der
SQL-Syntax. Bitte die korrekte Syntax im Handbuch nachschlagen (diese
kann für verschiedene Server-Versionen unterschiedlich sein) bei 'CACHED
TABLE 'AktenAdressen'('AktenNr' INTEGER NO
Das müsste in MySQL doch ähnlich aussehen, entscheidend ist PRIMARY
KEY("who","what"), dass also die beiden Felder zusammen als Liste als
Parameter zu PRIMARY KEY angegeben werden. Nach MySQL 5.0 Syntax geht das.
Hast Du zufällig die Fundstelle dazu in der 5.0.er-Referenz.
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
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [de-users] n:m Relation in Base
Hallo Mechtilde,
Tabelle course (erste Spalte PupilID,zweite sucjectID)
1 a
1 b
2 c
2 a
Wenn du eine zusätzliche Spalte als Schlüssel benutzt, hast du zum
Beispiel (erste Spalte ID)
1 1 a
2 1 b
3 2 c
4 2 a
Um unteren Fall könntest du den Datensatz
5 1 a
anlegen und hättest damit eine doppelte Kursbelegung, die Information
(Gerd,Mathe) wäre zweimal drin. Wenn du den Verbundschlüssel benutzt,
wird das verhindert.
Das sieht gut aus, gilt wohl leider nur für HSQL und nicht für MySQL.
Sowohl mit OOo als auch mit PhpMyAdmin lassen sich in MySQL _zwei_
Primärschlüssel angeben.
Das sollte mich wundern. Es ist 1 Primärschlüssel, der aus zwei Feldern
besteht. Kannst du sehen, welches SQL-Kommando benutzt wurde?
In der MySQl-Referenz habe ich bisher auch noch nichts dazu gefunden.
Ich verstehe dein Problem nicht so richtig. In HSQL sieht es so aus
CREATE CACHED TABLE "course"("who" INTEGER NOT NULL,"what" INTEGER NOT
NULL,"paid" BOOLEAN,"repeat" BOOLEAN,PRIMARY
KEY("who","what"),CONSTRAINT SYS_FK_64 FOREIGN KEY("what") REFERENCES
"subject"("ID") ON DELETE CASCADE ON UPDATE CASCADE,CONSTRAINT SYS_FK_79
FOREIGN KEY("who") REFERENCES "pupil"("ID") ON DELETE CASCADE ON UPDATE
CASCADE)
Das müsste in MySQL doch ähnlich aussehen, entscheidend ist PRIMARY
KEY("who","what"), dass also die beiden Felder zusammen als Liste als
Parameter zu PRIMARY KEY angegeben werden. Nach MySQL 5.0 Syntax geht das.
mfG
Regina
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [de-users] n:m Relation in Base
Mechtilde schrieb: Hallo, Regina Regina Henschel schrieb: Hallo Mechtilde, Mechtilde schrieb: Meine Frage dazu müssen die beiden Werte in der Tabelle "course" Primärschlüssel haben oder kann ich der Tabelle auch eine eigene ID als Primärschlüssel geben? Du kannst schon, aber das ist hier nicht so gut. Tabelle pupil 1 Gerd 2 Jutta 3 Inge Tabelle subject a Mathe b Bio c Sport Tabelle course (erste Spalte PupilID,zweite sucjectID) 1 a 1 b 2 c 2 a Wenn du eine zusätzliche Spalte als Schlüssel benutzt, hast du zum Beispiel (erste Spalte ID) 1 1 a 2 1 b 3 2 c 4 2 a Um unteren Fall könntest du den Datensatz 5 1 a anlegen und hättest damit eine doppelte Kursbelegung, die Information (Gerd,Mathe) wäre zweimal drin. Wenn du den Verbundschlüssel benutzt, wird das verhindert. Das sieht gut aus, gilt wohl leider nur für HSQL und nicht für MySQL. Sowohl mit OOo als auch mit PhpMyAdmin lassen sich in MySQL _zwei_ Primärschlüssel angeben. In der MySQl-Referenz habe ich bisher auch noch nichts dazu gefunden. Danke für die detailierte Erläuterung. Ich habe das Problem ber der Beziehung zwischen Akten und Adressen. Das ist auch eine m:n Beziehung. Das eigentliche Problem ist hier jetzt die Erstellung des Formulars. Gibt es Informationen und Kniffe, wie man ein solches Problem angehen sollte. 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [de-users] n:m Relation in Base
Hallo, Regina Regina Henschel schrieb: Hallo Mechtilde, Mechtilde schrieb: Ich habe mir deine Anhänge zum Issue 50660 angeschaut. Ja, ich habe mal meine liegen gebliebenen Datenbankprobleme aufgearbeitet. Meine Frage dazu müssen die beiden Werte in der Tabelle "course" Primärschlüssel haben oder kann ich der Tabelle auch eine eigene ID als Primärschlüssel geben? Du kannst schon, aber das ist hier nicht so gut. Tabelle pupil 1 Gerd 2 Jutta 3 Inge Tabelle subject a Mathe b Bio c Sport Tabelle course (erste Spalte PupilID,zweite sucjectID) 1 a 1 b 2 c 2 a Wenn du eine zusätzliche Spalte als Schlüssel benutzt, hast du zum Beispiel (erste Spalte ID) 1 1 a 2 1 b 3 2 c 4 2 a Um unteren Fall könntest du den Datensatz 5 1 a anlegen und hättest damit eine doppelte Kursbelegung, die Information (Gerd,Mathe) wäre zweimal drin. Wenn du den Verbundschlüssel benutzt, wird das verhindert. Danke für die detailierte Erläuterung. Ich habe das Problem ber der Beziehung zwischen Akten und Adressen. Das ist auch eine m:n Beziehung. Das eigentliche Problem ist hier jetzt die Erstellung des Formulars. Gibt es Informationen und Kniffe, wie man ein solches Problem angehen sollte. 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [de-users] n:m Relation in Base
Hallo Mechtilde, Mechtilde schrieb: Ich habe mir deine Anhänge zum Issue 50660 angeschaut. Ja, ich habe mal meine liegen gebliebenen Datenbankprobleme aufgearbeitet. Meine Frage dazu müssen die beiden Werte in der Tabelle "course" Primärschlüssel haben oder kann ich der Tabelle auch eine eigene ID als Primärschlüssel geben? Du kannst schon, aber das ist hier nicht so gut. Tabelle pupil 1 Gerd 2 Jutta 3 Inge Tabelle subject a Mathe b Bio c Sport Tabelle course (erste Spalte PupilID,zweite sucjectID) 1 a 1 b 2 c 2 a Wenn du eine zusätzliche Spalte als Schlüssel benutzt, hast du zum Beispiel (erste Spalte ID) 1 1 a 2 1 b 3 2 c 4 2 a Um unteren Fall könntest du den Datensatz 5 1 a anlegen und hättest damit eine doppelte Kursbelegung, die Information (Gerd,Mathe) wäre zweimal drin. Wenn du den Verbundschlüssel benutzt, wird das verhindert. mfG Regina - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [de-users] n:m Relation in Base
Hallo Jens und die anderen,
Jens Nürnberger schrieb:
Hallo Karl-Heinz,
Meines Wissens nicht. Ich habe die Tabellen mal testweise angelegt und
es hat geklappt, aber ich hatte wohl einen Denkfehler. Ich habe nur eine
spezielle Form der n:m-Beziehung aufgebaut. jeder Satz aus Tabelle1 kann
maximal einmal mit einem Satz aus Tabelle2 verknüpft werden. Aber das
ist noch lange keine 1:1-Beziehung.
Eine Beziehung mit "genau einmal" ist auch nicht sinnvoll, weil man die
Einträge in den Tabellen nicht gleichzeitig vornehmen kann. Es muss
daher eine vorrangige und eine abhängige Tabelle geben. Eine
1:1-Beziehung hat m.E. eine Richtung. In OOo Base ergibt sie sich durch
die Zugrichtung bzw. die Reihenfolge in dem Dialog "Relationen" (links
abhängig Relation). Insofern ist die Menge {aufgeteilte Tabellen inkl.
Beziehungen} nicht das gleiche wie eine einzelne Tabelle.
[..]
Ich stell die Theorie heute noch Online - inkl. Beispiele - da kann
jeder mal sehen was gemeint ist.
Kannst Du den Link dann hier in der Liste posten?
Ja! http://jensnuernberger.homepage.t-online.de/dbp/datenbankplanung.html
Achtung das Dokument ist eine frühe! Version!
Ich habe dort mal mit 1_1.odb angefangen. Meines Erachtens geht das so
noch nicht:
(1) Die Beziehung sollte andersherum sein. Es kann Personal geben, zu
dem noch kein Gehalt eingetragen ist. Umgekehrt muss zu jedem
Gehaltseintrag eine Person existieren. Die Personalnummer in tbl_Gehalt
muss die Referenz auf die Personalnummer in tbl_personal enthalten.
(2) Der Primärschlüssel der "abhängigen" Tabelle sollte kein Autowert
sein. Denn er könnte u.U. nicht zu der gewünschten Person passen, wenn
durch Einfügen und Löschen die Zählungen nicht synchron laufen.
(3) Die Konstruktion geht davon aus, dass die Personalnummer niemals
geändert wird. Wenn man sie aber änderbar haben möchte, müsste man wohl
die Update-Option auf "Kaskadieren" stellen. Ansonsten kann man die
Nummer bei tbl_personal nicht ändern, weil noch eine Referenz existiert
und bei tbl_Gehalt nicht, weil es den neuen Schlüssel noch nicht gibt.
mfG
Regina
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [de-users] n:m Relation in Base
Am 23 Apr 2006 um 21:48 hat Mechtilde geschrieben: > Kann sie leider nicht öffnen, da dies wohl nur unter Windows ohne > weitere eingriffe möglich ist. > Ein Ändern des Pfades auf die *.mdb datei hat keinen Zugriff ermöglicht. > > Mechtilde Hallo Mechtilde, Schade, dass die Dateien Dir nun nicht weiter helfen, aber ich muss noch unter Win arbeiten, wegen meiner CAD- und CNC- Sachen. Fuer mich bekomme ich die Aenderung schon noch irgendwie hin. Viele Gruesse & einen schoenen Rest-Abend Bernd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [de-users] n:m Relation in Base
Bernd Schukat schrieb: Am 23 Apr 2006 um 20:48 hat Mechtilde geschrieben: Hallo Bernd, Vielleicht hast Du ja doch eine Möglichkeite Deine Datei online zu stellen. Ich würde sie dann auch gerne herunterladen. Hallo Mechtilde, ich kann sie leider nicht online stellen, Dir aber gern als PM zuschicken. Jens Nürnberger hat schon die Kinken entdeckt: Darf ich fragen warum dein Primärindex oft im Format Text ist? Der lateinische Name muss natürlich eingegeben werden, nur access speichert intern die Daten des Primärindex als Zahlen, damit machst du Access langsam (auch wenn man es nicht immer merkt). War ein typischer Anfaengerfehler. das war halt meine 1. Datenbank. Habe den Primaerschluessel dann in der lat. Bezeichnung gelassen, wg. angeborener Faulheit. Die Uebergabe zu Base war auch mein erster Versuch und dann war ich so froh, das endlich alles geklappt hatte, das ich noch keine Lust hatte, es schon wieder zu aendern. Aber Du hast natuerlich grundsaetzlich Recht und es steht auch auf meiner tudu-Liste, aber da steht halt so viel ... :-). Du kannst sie selbstverstaendlich auch online stellen, trotz des Kinkens funktionieren sie ja. Ich habe nur noch keine einfache Reparaturmethode gefunden. Ich kann auch keine Garantie auf Richtigkeit uebernehmen, da ich von Gartenbau keine Ahnung und alles muehsam aus sich widersprechenden Quellen abgeschrieben habe. Kann sie leider nicht öffnen, da dies wohl nur unter Windows ohne weitere eingriffe möglich ist. Ein Ändern des Pfades auf die *.mdb datei hat keinen Zugriff ermöglicht. 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [de-users] n:m Relation in Base
Am 23 Apr 2006 um 20:48 hat Mechtilde geschrieben: > Hallo Bernd, > > Vielleicht hast Du ja doch eine Möglichkeite Deine Datei online zu stellen. > Ich würde sie dann auch gerne herunterladen. > > Wenn du nichts dagegen hast, kann ich sie auch online stellen. > > Mechtilde > Hallo Mechtilde, ich kann sie leider nicht online stellen, Dir aber gern als PM zuschicken. Jens Nürnberger hat schon die Kinken entdeckt: > > Darf ich fragen warum dein Primärindex oft im Format Text ist? > Der lateinische Name muss natürlich eingegeben werden, nur access > speichert intern die Daten des Primärindex als Zahlen, damit machst du > Access langsam (auch wenn man es nicht immer merkt). > > Grüße Jens War ein typischer Anfaengerfehler. das war halt meine 1. Datenbank. Habe den Primaerschluessel dann in der lat. Bezeichnung gelassen, wg. angeborener Faulheit. Die Uebergabe zu Base war auch mein erster Versuch und dann war ich so froh, das endlich alles geklappt hatte, das ich noch keine Lust hatte, es schon wieder zu aendern. Aber Du hast natuerlich grundsaetzlich Recht und es steht auch auf meiner tudu-Liste, aber da steht halt so viel ... :-). Du kannst sie selbstverstaendlich auch online stellen, trotz des Kinkens funktionieren sie ja. Ich habe nur noch keine einfache Reparaturmethode gefunden. Ich kann auch keine Garantie auf Richtigkeit uebernehmen, da ich von Gartenbau keine Ahnung und alles muehsam aus sich widersprechenden Quellen abgeschrieben habe. So die Dinger kommen als 2 PM´s. Viele Gruesse Bernd
Re: [de-users] n:m Relation in Base
Hallo Regina Regina Henschel schrieb: Nachtrag: Regina Henschel schrieb: Ich habe jedoch festgestellt, dass es einfacher ist, erst einen künstlichen Schlüssel zu setzen, dann die Beziehungen herzustellen, dann den Schlüssel auf kombinierten Schlüssel zu ändern und schließlich das Feld des alten künstlichen Schlüssels zu löschen. Vielleicht kennt ja jemand einen direkteren Weg? Gefunden, wenn man nicht versucht die Beziehungen durch Ziehen herzustellen, sondern man das Symbol "Neue Relation" aus der Leiste benutzt, geht es direkt, auch wenn in der Tabelle schon der zusammengesetzte Schlüssel gesetzt ist. Ich habe mir deine Anhänge zum Issue 50660 angeschaut. Meine Frage dazu müssen die beiden Werte in der Tabelle "course" Primärschlüssel haben oder kann ich der Tabelle auch eine eigene ID als Primärschlüssel geben? 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [de-users] n:m Relation in Base
Hallo Bernd, Bernd Schukat schrieb: Am 23 Apr 2006 um 19:54 hat Jens Nürnberger geschrieben: Hallo Bernd, Ja, das würde ich mir gerne ansehen. mfG Regina Ist unterwegs zu Dir in 2 Mails dürfte ich die auch mal erhalten? > kein Problem, die 2. mit der org-Acessversion ist allerdings ein "Moerderteil". Vorschlag: Wenn es Dir nur ums grundsaetzliche geht, wuerde ich zum Verkleinern vorher einiges loeschen. Die volle Droehnung dann auf extra Anfrage. Die Spar-und die Base-Version sind im Anmarsch als PM Vielleicht hast Du ja doch eine Möglichkeite Deine Datei online zu stellen. Ich würde sie dann auch gerne herunterladen. Wenn du nichts dagegen hast, kann ich sie auch online stellen. 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [de-users] n:m Relation in Base
Am 23 Apr 2006 um 19:54 hat Jens Nürnberger geschrieben: > Hallo Bernd, > > >> Ja, das würde ich mir gerne ansehen. > >> > >> mfG > >> Regina > > > > Ist unterwegs zu Dir in 2 Mails > > dürfte ich die auch mal erhalten? > > Danke Jens Claro, kein Problem, die 2. mit der org-Acessversion ist allerdings ein "Moerderteil". Vorschlag: Wenn es Dir nur ums grundsaetzliche geht, wuerde ich zum Verkleinern vorher einiges loeschen. Die volle Droehnung dann auf extra Anfrage. Die Spar-und die Base-Version sind im Anmarsch als PM Viele Gruesse Bernd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [de-users] n:m Relation in Base
Hallo Bernd, Ja, das würde ich mir gerne ansehen. mfG Regina Ist unterwegs zu Dir in 2 Mails dürfte ich die auch mal erhalten? Danke Jens - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [de-users] n:m Relation in Base
Hallo Karl-Heinz, Meines Wissens nicht. Ich habe die Tabellen mal testweise angelegt und es hat geklappt, aber ich hatte wohl einen Denkfehler. Ich habe nur eine spezielle Form der n:m-Beziehung aufgebaut. jeder Satz aus Tabelle1 kann maximal einmal mit einem Satz aus Tabelle2 verknüpft werden. Aber das ist noch lange keine 1:1-Beziehung. Bei 1:1-Beziehungen besteht die Schwierigkeit, dass auch wirklich alle Daten die eindeutig zu einem Schlüssel gehören auch in diesem Datensatzkonglomerat abzuspeichern sind. Hier gebe ich dir recht, nehmen wir das Bsp einer Personalnummer, die "Nebentabelle" muss ja den selben Schlüssel nutzen den der Name in der Personaldatenbank erhalten hat. Das ist, wenn dort gewünscht, eine zwingende Voraussetzung beim prof. Einsatz von OpenOffice Base. Hier sehe ich nur die Möglichkeit, sämtliche zur eindeutigen Identifizierung notwendigen Felder in einem Datensatz abzuspeichern und die "abhängigen" Daten dann in anderen Tabellen abzuspeichern. Dabei muß dann der Schlüssel der "übergeordneten" Tabelle ebenfalls als Schlüssel der "untergeordneten" Tabelle genommen werden. Für Auswertungen wäre das mit JOIN dann kein Problem. Im Prinzip hättest Du dann eine hierarchische Datenbank als mehrere Tabellen abgespeichert. Ich frag mal: "JOIN" ist ein SQL Befehl? Da muß ich Dir Recht geben, die Formulare und deren Verknüpfungen zu den Datenbanktabellen sind ein bischen gewöhnungsbedürftig und vor allem verbesserungsfähig. Aber auch die Beziehung lässt sich so glaube ich nicht in Base abbilden. In Base gibt es nur die Möglichkeit 1:n-Relationen einzurichten. Das stimmt nicht ganz, Base nutzt eine SQL Datenbank als Basis und kann alle drei Beziehungen erzeugen 1:1, 1:n, und n:m. Die Schwierigkeit besteht in der Eingabe und Auswertung dieser Daten. Als einfaches Beispiel würde ich hier mal 1:n anführen, eine Adressdatenbank in der das Land per Pulldown Menü ausgewählt werden kann und zwar so das ich weitere Länder einfügen kann (Hilfstabellen). Der Weg den ich kenne, das zu lösen, ist recht umständlich, hier hoffe ich auf die Zukunft, OOo.org Base Version 3.* :-) das dem Nutzer dann die Arbeit erleichtert wird. Einzig und allein sähe ich da die Möglichkeit, die Formularsteuerung über Makros zu realisieren, aber dafür kenne ich mich bei den Makros zu wenig aus. Hier bin ich bei einem Problem, wo ich dir Recht geben muss, nur immer an einen Anfänger denke ... SQL und oder Makros sind nicht der ideale Weg für grundlegende Lösungen. Ich stell die Theorie heute noch Online - inkl. Beispiele - da kann jeder mal sehen was gemeint ist. Kannst Du den Link dann hier in der Liste posten? Ja! http://jensnuernberger.homepage.t-online.de/dbp/datenbankplanung.html Achtung das Dokument ist eine frühe! Version! Grüße Jens - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [de-users] n:m Relation in Base
Hallo Regina, Ja, abgesehen von der Tatsache, dass ich bei Formularen noch Nachholbedarf habe, scheinen diese das eigentliche Problem zu sein. Vielleicht kann man typische Situationen isolieren und dann Lösungen ermitteln? Für mich sind diese Fälle: - Erstellen von Auswahlfeldern die ihre Daten aus einer Hilfstabelle beziehen, - Arbeit mit mehr als einem Unterformular (wenn möglich versch. Typen) Diese beiden Probleme würden in meinen Augen fürs erste einmal reichen, da sie so ziemlich alle wichtigen Formular erfassen. Ich würde dann gerne solche Anwendungsfälle im Wiki dokumentieren. Ich kann zwar Mini-Beispieldatenbanken dazu herstellen, aber besser wären natürlich solche Beispieldatenbanken, die realitätsnah sind. Hast du so etwas? Jein, als Dozent habe ich mich auch die Erstellung und Planung von "Access" Datenbanken konzentriert, da gibt es genug. IMHO müssten aber auch einfache Datenabnken reichen, eine Access Bsp. - Datenbank hat auch nur 10 bis 20 Datensätze, da die Ertellung und er Umgang wichtiger ist. Ich bin der Meinung, das es ausreichen würde einfache und überschaubare Datenbanken zu haben, als komplexe, wer macht sich schon die Mühe die komplette Datenbank "Nordwind" von Access auseinander zu nehmen um an die Erstellung von Abfragen zu lernen. Es ist zwar mühsam, für jedes kleine Problem eine Beispieldatenbank zu machen als mit einer großen zu arbeiten, Anfänger würden wir damit vermutlich erschlagen. Meine bisherigen Arbeiten habe ich hier zum nachlesen mal Online gestellt, das Material ist nicht frei und unterliegt noch nicht der PDL, da ich (oder jeder der möchte) die Literatur noch überarbeiten muss (ich nutze teilweise bei komplexen Passagen noch Originaltexte aus der Literatur). Link: http://jensnuernberger.homepage.t-online.de/dbp/datenbankplanung.html Grüße Jens - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [de-users] n:m Relation in Base
Hallo Jens, Jens Nürnberger schrieb: > Hallo Karl-Heinz, > >> Hast Du schon mal versucht das ganze als n:m Beziehung zu speichern und >> dabei die beiden Schlüssel gemeinsam als Primärschlüssel für die >> Verbindungstabelle zu definieren? > > Geht das? Verstößt das nicht gegen ein Datenbank Grundsatz? Meines Wissens nicht. Ich habe die Tabellen mal testweise angelegt und es hat geklappt, aber ich hatte wohl einen Denkfehler. Ich habe nur eine spezielle Form der n:m-Beziehung aufgebaut. jeder Satz aus Tabelle1 kann maximal einmal mit einem Satz aus Tabelle2 verknüpft werden. Aber das ist noch lange keine 1:1-Beziehung. Bei 1:1-Beziehungen besteht die Schwierigkeit, dass auch wirklich alle Daten die eindeutig zu einem Schlüssel gehören auch in diesem Datensatzkonglomerat abzuspeichern sind. Hier sehe ich nur die Möglichkeit, sämtliche zur eindeutigen Identifizierung notwendigen Felder in einem Datensatz abzuspeichern und die "abhängigen" Daten dann in anderen Tabellen abzuspeichern. Dabei muß dann der Schlüssel der "übergeordneten" Tabelle ebenfalls als Schlüssel der "untergeordneten" Tabelle genommen werden. Für Auswertungen wäre das mit JOIN dann kein Problem. Im Prinzip hättest Du dann eine hierarchische Datenbank als mehrere Tabellen abgespeichert. > > Die Beziehungen sind kein Problem mit Base, das Formular und die > Dateneingabe sehe ich als größeres Problem an ... Da muß ich Dir Recht geben, die Formulare und deren Verknüpfungen zu den Datenbanktabellen sind ein bischen gewöhnungsbedürftig und vor allem verbesserungsfähig. Aber auch die Beziehung lässt sich so glaube ich nicht in Base abbilden. In Base gibt es nur die Möglichkeit 1:n-Relationen einzurichten. Einzig und allein sähe ich da die Möglichkeit, die Formularsteuerung über Makros zu realisieren, aber dafür kenne ich mich bei den Makros zu wenig aus. > Ich stell die Theorie heute noch Online - inkl. Beispiele - da kann > jeder mal sehen was gemeint ist. > Kannst Du den Link dann hier in der Liste posten? > Grüße Jens -- Gruß Karl-Heinz ++ WinXP-Pro SP2 OOo 2.0.0-de - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [de-users] n:m Relation in Base
Am 23 Apr 2006 um 18:39 hat Regina Henschel geschrieben: > Ja, das würde ich mir gerne ansehen. > > mfG > Regina Ist unterwegs zu Dir in 2 Mails mfg Bernd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [de-users] n:m Relation in Base
Hallo Bernd, Bernd Schukat schrieb: ich haette da evtl was. Ich habe eine Datenbank von Access zu Base "exportiert" .Wg der großen Infomenge (Anzahl der Spalten) hatte ich die Bank unter Acess in 4 Tabellen aufgeteilt. Das ging unter Base leider nicht, weil ich aus 4 Tabellen kein Formular machen konnte. Dann habe ich eine Mastertabelle und 4 "Untertabellen" gemacht, da wurden die Daten dann aus dem Formular nicht vollstaendig in die Untertabellen uebertragen. Bei Interesse kann ich dir das gern als PM zusenden. Ja, das würde ich mir gerne ansehen. mfG Regina - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [de-users] n:m Relation in Base
Am 23 Apr 2006 um 17:39 hat Regina Henschel geschrieben: > aber besser wären natürlich solche Beispieldatenbanken, die realitätsnah > sind. Hast du so etwas? Hallo Regina, ich haette da evtl was. Ich habe eine Datenbank von Access zu Base "exportiert" .Wg der großen Infomenge (Anzahl der Spalten) hatte ich die Bank unter Acess in 4 Tabellen aufgeteilt. Das ging unter Base leider nicht, weil ich aus 4 Tabellen kein Formular machen konnte. Dann habe ich eine Mastertabelle und 4 "Untertabellen" gemacht, da wurden die Daten dann aus dem Formular nicht vollstaendig in die Untertabellen uebertragen. Bei Interesse kann ich dir das gern als PM zusenden. Viele Gruesse Bernd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [de-users] n:m Relation in Base
Nachtrag: Regina Henschel schrieb: Ich habe jedoch festgestellt, dass es einfacher ist, erst einen künstlichen Schlüssel zu setzen, dann die Beziehungen herzustellen, dann den Schlüssel auf kombinierten Schlüssel zu ändern und schließlich das Feld des alten künstlichen Schlüssels zu löschen. Vielleicht kennt ja jemand einen direkteren Weg? Gefunden, wenn man nicht versucht die Beziehungen durch Ziehen herzustellen, sondern man das Symbol "Neue Relation" aus der Leiste benutzt, geht es direkt, auch wenn in der Tabelle schon der zusammengesetzte Schlüssel gesetzt ist. mfG Regina - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [de-users] n:m Relation in Base
Hallo Jens, Jens Nürnberger schrieb: Eins? Die Beispiele gibt es schon (bei mir), das Problem ist auch nicht die Erstellung der Datenbanken im Modus 1:1; 1:n und n:m jemanden näher zu bringen (auf Wunsch kann ich das schon Online stellen), sondern die Umsetzung der dazugehörenden Formulare, vor allem bei n:m Beziehungen. Ja, abgesehen von der Tatsache, dass ich bei Formularen noch Nachholbedarf habe, scheinen diese das eigentliche Problem zu sein. Vielleicht kann man typische Situationen isolieren und dann Lösungen ermitteln? Ich würde dann gerne solche Anwendungsfälle im Wiki dokumentieren. Ich kann zwar Mini-Beispieldatenbanken dazu herstellen, aber besser wären natürlich solche Beispieldatenbanken, die realitätsnah sind. Hast du so etwas? Sollten wir mit der Diskussion nicht besser nach business@de.openoffice.org umziehen? Poste Frage und Link zu dem Beispiel doch dort. :-( bin schon in der User-Liste aktiv, in der dev Liste und nun noch Bussiness ist diese Splittung wirklich sinnvoll? ... melde mich gerade an ... So hatte ich das Ergebnis der Diskussion in dev verstanden. mfG Regina - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [de-users] n:m Relation in Base
Hallo Karl-Heinz, Hast du das schon einmal gemacht? Ich scheitere in OpenOffice.org Base an der praktischen Umsetzung der Theorie und wär Glücklich ein Praxisbeispiel mal nachspielen zu dürfen. Auch eine 1:1 Beziehung wär intressant. Hast Du schon mal versucht das ganze als n:m Beziehung zu speichern und dabei die beiden Schlüssel gemeinsam als Primärschlüssel für die Verbindungstabelle zu definieren? Geht das? Verstößt das nicht gegen ein Datenbank Grundsatz? Die Beziehungen sind kein Problem mit Base, das Formular und die Dateneingabe sehe ich als größeres Problem an ... Ich stell die Theorie heute noch Online - inkl. Beispiele - da kann jeder mal sehen was gemeint ist. Grüße Jens - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [de-users] n:m Relation in Base
Regina Henschel schrieb: bin wieder da, und kann darauf antworten und auf einige Fragen dazu eingehen. Hast du das schon einmal gemacht? Ich scheitere in OpenOffice.org Base an der praktischen Umsetzung der Theorie und wär Glücklich ein Praxisbeispiel mal nachspielen zu dürfen. Auch eine 1:1 Beziehung wär intressant. Reicht dafür nicht eine 1:n Beziehung, wenn du auf der n-Seite für die Spalte einen eindeutigen Index definierst? Völlig symmetrisch geht es wohl nicht. Könnte es dann vielleicht einen Loop bei Änderungsverfolgungen geben? 1:1 Beziehungen sind im Bürobereich dann üblich wenn sicherheitsrelavante Informationen gespeichert werden müssen, wie zum Beispiel die Adresse (Primärsch. ist die Personalnummer) für die PErsonalabteilung und die Lohngruppe für die Zahlungsabteilung, beide Abteilungen sollten nicht wissen was wer verdient. Das Problem bei Base ist, das der Aufbau einer Abfrage / eines Formulars für eine 1:1; n:m Beziehung, recht schwer und komplex ist, bei Experimenten von mir wurden Datenbestände nicht in beiden Datenbanken aktualisiert. Theorie und allgemeine Beispiele für eine Diskussion wie es gehen müsste, kann ich auf Wunsch zusteuern und Online stellen. Solch ein Beispiel wäre gut, Theorie ist eigentlich klar. Dann kann man mal gemeinsam an die Umsetzung von Theorie zur Praxis gehen. Bei meinen Mini-Beispielen hatte ich jedenfalls keine Schwierigkeiten damit. Eins? Die Beispiele gibt es schon (bei mir), das Problem ist auch nicht die Erstellung der Datenbanken im Modus 1:1; 1:n und n:m jemanden näher zu bringen (auf Wunsch kann ich das schon Online stellen), sondern die Umsetzung der dazugehörenden Formulare, vor allem bei n:m Beziehungen. Sollten wir mit der Diskussion nicht besser nach business@de.openoffice.org umziehen? Poste Frage und Link zu dem Beispiel doch dort. :-( bin schon in der User-Liste aktiv, in der dev Liste und nun noch Bussiness ist diese Splittung wirklich sinnvoll? ... melde mich gerade an ... Grüße Jens - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [de-users] n:m Relation in Base
Hallo Karl-Heinz, Karl-Heinz Gödderz schrieb: Hallo Jens, Jens Nürnberger schrieb: Hast du das schon einmal gemacht? Ich scheitere in OpenOffice.org Base an der praktischen Umsetzung der Theorie und wär Glücklich ein Praxisbeispiel mal nachspielen zu dürfen. Auch eine 1:1 Beziehung wär intressant. Hast Du schon mal versucht das ganze als n:m Beziehung zu speichern ?? Wie willst du eine n:m Beziehung setzen um sie dann zu speichern? und dabei die beiden Schlüssel gemeinsam als Primärschlüssel für die Verbindungstabelle zu definieren? Das muss man inhaltlich entscheiden. Wenn es wirklich eine reine Verbindungstabelle ist, dann funktioniert das gut. Es verhindert gleichzeitig doppelte Einträge, die bei einem künstlichen Schlüssel mit Autoincrement entstehen können, wenn man nicht aufpasst. Ich habe jedoch festgestellt, dass es einfacher ist, erst einen künstlichen Schlüssel zu setzen, dann die Beziehungen herzustellen, dann den Schlüssel auf kombinierten Schlüssel zu ändern und schließlich das Feld des alten künstlichen Schlüssels zu löschen. Vielleicht kennt ja jemand einen direkteren Weg? mfG Regina - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [de-users] n:m Relation in Base
Hallo Jens, Jens Nürnberger schrieb: > > Hast du das schon einmal gemacht? Ich scheitere in OpenOffice.org Base > an der praktischen Umsetzung der Theorie und wär Glücklich ein > Praxisbeispiel mal nachspielen zu dürfen. Auch eine 1:1 Beziehung wär > intressant. > Hast Du schon mal versucht das ganze als n:m Beziehung zu speichern und dabei die beiden Schlüssel gemeinsam als Primärschlüssel für die Verbindungstabelle zu definieren? -- Gruß Karl-Heinz ++ WinXP-Pro SP2 OOo 2.0.0-de - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [de-users] n:m Relation in Base
Hallo Jens, Jens Nürnberger schrieb: Hast du das schon einmal gemacht? Ich scheitere in OpenOffice.org Base an der praktischen Umsetzung der Theorie und wär Glücklich ein Praxisbeispiel mal nachspielen zu dürfen. Auch eine 1:1 Beziehung wär intressant. Reicht dafür nicht eine 1:n Beziehung, wenn du auf der n-Seite für die Spalte einen eindeutigen Index definierst? Völlig symmetrisch geht es wohl nicht. Könnte es dann vielleicht einen Loop bei Änderungsverfolgungen geben? Theorie und allgemeine Beispiele für eine Diskussion wie es gehen müsste, kann ich auf Wunsch zusteuern und Online stellen. Solch ein Beispiel wäre gut, Theorie ist eigentlich klar. Dann kann man mal gemeinsam an die Umsetzung von Theorie zur Praxis gehen. Bei meinen Mini-Beispielen hatte ich jedenfalls keine Schwierigkeiten damit. Sollten wir mit der Diskussion nicht besser nach business@de.openoffice.org umziehen? Poste Frage und Link zu dem Beispiel doch dort. mfG Regina - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [de-users] n:m Relation in Base
Hallo Regina, Das liegt daran, dass bei einem vernünftigen Datenbankentwurf n:m Relationen zu 1:n Relationen aufgelöst werden. Du musst also eine dritte Tabelle einführen. Beispiel VHS: Eine Person kann mehrere Kurse buchen und ein Kurs besteht aus mehreren Personen. Du brauchst eine dritte Tabelle für die Kursbelegung. Hast du das schon einmal gemacht? Ich scheitere in OpenOffice.org Base an der praktischen Umsetzung der Theorie und wär Glücklich ein Praxisbeispiel mal nachspielen zu dürfen. Auch eine 1:1 Beziehung wär intressant. Theorie und allgemeine Beispiele für eine Diskussion wie es gehen müsste, kann ich auf Wunsch zusteuern und Online stellen. Grüße Jens - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [de-users] n:m Relation in Base
Hallo Ines, Ines Peters schrieb: Hallo zusammen, ist es möglich Datensätze zweier Tabellen mit einer n:m Relation zu verknüpfen? Ich bekomme immer nur 1:n Relationen angezeigt. Kann mir jemand helfen? Das liegt daran, dass bei einem vernünftigen Datenbankentwurf n:m Relationen zu 1:n Relationen aufgelöst werden. Du musst also eine dritte Tabelle einführen. Beispiel VHS: Eine Person kann mehrere Kurse buchen und ein Kurs besteht aus mehreren Personen. Du brauchst eine dritte Tabelle für die Kursbelegung. mfG Regina - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
