I have made a database with 3 tables, A, B and C. I want to setup an 1:1 relation between A and B and an 1:1 relation between A and C?. Is it possible to do that?
I have made a database with 3 tables, A, B and C. I want to setup an 1:1 relation between A and B and an 1:1 relation between A and C?. Is it possible to do that?
I don't think it is. 1:1 relationships are not the most used. I can't imagine would you could be doing to need this. Can you tell us more.
If this helped, please click the star at the bottom left of this posting and add to my reputation. Many thanks.
Bob Fitzpatrick
I sort of do that. Example:
tblSample
SampleID (primary key)
tblTestA
SampleID (primary key)
tblTestB
SampleID (primary key)
tblTestC
SampleID (primary key)
A sample can have any number of different test procedures associated with it but not all of the test procedures and only one of each test procedure. So sample 1010 could have test A and C and sample 1011 could have test B.
The way this database works, users login a sample and select the desired tests from a list. Code creates the test records with SQL INSERT actions. Then on some later date forms with RecordSource that join the related records are opened for entry of test data. Form/Subforms when needed have Master/Child links on the SampleIDs. Data integrity is managed by code. Code also allows data entry into fields for only the tests that have been selected.
Relationships can be established in the builder, however, I have so many different test procedures that I cannot setup relationships in the Relationships window (I think limit is like 30 tables). This parent/child linking on two PK fields (neither is autonumber) does seem to work to allow creation of dependent record, I just don't have forms setup that way. Also, the master table (tblSample) will show only one dependent table when clicking the + in the left table margin. But users don't work directly with tables anyway so this is irrelevant.
How to attach file: http://www.accessforums.net/showthread.php?t=70301 To provide db: copy, remove confidential data, run compact & repair, zip w/Windows Compression.
Further to what June and Bob have provided/advised, I think we need to know more about your intended data base. Perhaps you could give us some meaningful table names and sample data in order that we can understand your situation. Table A, B and C is nice in theory, but it's a little too abstract to respond with specific ideas.
sure, but you may have alternatives if there was more info.Is it possible