> perhaps we can tweak your tables a bit. suggest
>
[quoted text clipped - 81 lines]
> >
> > Any help much appreciated.
in the equipment details tables (tblLaptops, tblMobilePhones, etc), is the
EquipID field's Indexed property set to No, or to Yes (Duplicates OK) ?
if so, open the Relationships window and delete the one-to-many relationship
between tblEquipment and tblLaptops. then open tblLaptops in design view.
change the EquipID field's Indexed property to Yes (No Duplicates). close
and save. go back to the Relationships window and create the link again; it
should default to "one-to-one". if this works, do the same thing to all the
other equipment details tables.
your relationships should match reality, so it's worth fixing. i can't think
of any reason you would actually need "many" equipment details records for a
single piece of equipment - unless you're intending to keep a "history" of
changes to equipment parts (and i'd rather not open that can of worms!)
btw, in the example tables i posted earlier, i named the foreign key fields
the same as the primary key fields they're linked to. my mistake; i usually
don't do that because having the same field names in different tables
becomes confusing when working with queries, code, etc. instead, i add an
"fk" suffix to the foreign key field names, and a prefix to identify the
table, as
tblLaptops
LaptopID (primary key)
LEquipIDfk (foreign key from tblEquipment)
tblMobilePhones
MPhoneID (primary key)
MPEquipIDfk (foreign key from tblEquipment)
that way all the field names in your database are unique, and you can tell
at a glance which table a foreign key field belongs to. sorry i didn't
include this originally, hope it's not too confusing.
hth
> tina,
> It wouldn't accept a one to one join but would accept a one to
[quoted text clipped - 86 lines]
> > >
> > > Any help much appreciated.