Hi all, I will try and explain m

[woodyinoz]

Hi all,

I will try and explain my problem and I hope you all understand what I want to do.

I have two tables linked on a form through a common field (Plate id. One table holds material information while the other holds part information. One thing that these tables have in common are the thickness fields in each of them.

What I want to do is tell Paradox that these two tables can't share the same plateid if the thicknesses are different. i.e. a 25thk part can't be cut from a 30th plate.

Can anyone help?

Thanks in advance,

Woody.

 

[ros]

If I understand your problem correctly, you could try linking the tables with both (ID and thickness) fields. You may have to restructure one or both tables to make thickness part of the primary key. This way items in the parts table must have the same thickness as the plate. Try it on a copy to se if you get the desired results.

Richie

 

[ros]

On second thoughts scratch that last reply. You don't need the thickness field in the parts table at all. Why repeat the data if the plateID will give you the part thickness anyway?
If you need to find out the thickness of the part you should be able to get it from the plate table linking by plateID.
In general you shouldn't repeat master table fields except those necessary for linking.

HTH,
Richie

 

[woodyinoz]

Not all parts are already linked to a plate and that is where my problem lies. I want the users to enter a plate number so that a part can be tied to a plate but I don't want them to link it to the wrong thickness plate.

 

[Langley]

I think Ros was on the right track to begin with. Key should be

-Material.db-

PlateID*
Thickness*
yada yada

-Part.db-

PlateID*
Thickness*
UniqueOtherNum*
yada yada

When linked, viewing a record in Material.db would only show records in Part.db that has the same PlateID and Thickness. Inserted records in Part.db would automagically be assigned that PlateID and Thickness but you would have to deal with the UniqueOtherNumber at that point.

Mac
Mac

"Strange women lying in ponds and distributing swords is no basis for a system of government" - Dennis, age 37

mailto:langley_mckelvy@cd4.co.harris.tx.us

 

[JoeNg]

Based on this info, here is what I would try.
To keep it simple, the Plate and Part tables will have 1 to 1 relationships.
It can be easily changed to 1 to Many. But let’s see if this concept works.

Plate table Link Table Part Table
Plate ID Plate ID, Part ID Part ID

The Plate table is keyed by Plate ID field; the Link table is keyed by Plate Id and Part ID fields (composite keys); and the Part table is keyed by Part ID.

On the form, I would allow the user to “link” the Part record to the Plate record by entering the Plate ID and the Part ID. Before the Link table would accept the Part ID, compare the thickness field fields. If the Part’s thickness is less than Plate thickness, display error, reject link.