Hallo Andreas,

> Angehängt habe ich jetzt einfach nochmal die Screenshots aus der Mail
> gestern plus Screenshots bzgl. der Feldtypen.

Wie Robert schon sagte, kommen hier in der Liste keine Anhänge an.

Okay, in Deiner Mail, die auch per CC an mich privat ging, war in den
Screenshots zu lesen:

Column types do not match in statement [ALTER TABLE "Talk List" ADD
FOREIGN KEY ("Talk Number" REFERENCES "Speaker Talks" ("Talk Number")]

Das würde bedeuten, dass die beiden "Talk Number"-Spalten in den beiden
Tabellen inkompatible Typen haben.  Schau doch mal im Tabellenentwurf
nach, von welchem Typ die jeweils sind.


Die zweite Fehlermeldung im Screenshot war

Primary or unique constraint required on main table: "Speaker Talks" in
statement [ALTER TABLE "Speakers List" ADD FOREIGN KEY ("Speaker Number"
REFERENCES "Speaker Talks" ("Speaker ...

(Der Rest war vom OK-Knopf verdeckt. Hmm, ich dachte, *der* Bug wäre
gefixt.)

Das bedeutet, dass Du versucht hast, eine Relation von "Speakers
List"."Speaker Number" auf "Speaker Talks"."Speaker Number" (vermute
ich) anzulegen.

Das zweite Speaker Number ist allerdings weder der Primärschlüssel der
"Speaker Talks" Tabelle, noch hat es einen eindeutigen Index - deswegen
kann es nicht Ziel eines Fremdschlüssels sein.


Insgesamt scheint es mir, als wenn der Aufbau Deiner Tabellen nicht
richtig passt. Was ich aus einem Deiner Screenshots entnehmen konnte, war:

Tabelle: Speakers List
Felder:  ID (der Primärschlüssel) *
         ...
         Fax
         Additional Information
         Speakers Number

* (das vermute ich nur, das war nicht auf dem Bild)

Tabelle: Speaker-Talks
Felder:  ID (der Primärschlüssel)
         Speaker Number
         Talk Number

Tabelle: Talk List
Felder:  ID (der Primärschlüssel)
         Talk Number
         Talk Theme


Konzeptionell scheint es sich hier um einen m-n-Beziehung zwischen den
Sprechern und den Gesprächen zu handeln, klassich realisiert über eine
Zwischen-Tabelle. So weit, so richtig.

Aber:
Du scheinst in jeder Tabelle einen Primärschlüssel ID angelegt zu
haben, aber *zusätzlich* ein Feld, welches die (sicher eindeutige?!)
Nummer des Datensatzes aufnehmen soll. Das ist ein eindeutiger Wert
zuviel, und zum Teil für Deine Probleme verantwortlich.

Du solltest in Speakers List entweder die ID entfernen, und "Speakers
Number" zum Primärschlüssel erklären, oder einfach "Speakers Number"
entfernen, und die ID als eindeutige Nummer nutzen (letztendlich ist
genau das der Sinn eines PK.).
Analog für Talk List.

Außerdem solltest Du die ID aus Speakers-Talks entfernen, und das *Paar*
"Speaker Number"/"Talk Number" zum Primärschlüssel der Tabelle erklären.
Denn genau das ist es, was einen Datensatz in dieser Tabelle eindeutig
identifiziert: das Paar aus der Nummer des Sprechers und des Gesprächs
(da ein Sprecher wohl kaum zweimal bei dem selben Gespräch anwesend sein
wird).


Dann klappt's auch mit den Beziehungen, sollte man meinen (darauf
achten, dass Du die von Speakers-Talks zu "Speakers List" resp. "Talk
List" ziehst, nicht umgekehrt).

Ciao
Frank


-- 
- Frank Schönheit, Software Engineer         [EMAIL PROTECTED] -
- Sun Microsystems                      http://www.sun.com/staroffice -
- OpenOffice.org Base                       http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Antwort per Email an