Hi bcooney -
Thank you for your reply. I have considered trying to create the two entities as one file, but that only creates difficulties in other parts of the application futher down the track.
The actual application has to with a winery (I just love fly fishing , hence the analogy with rivers and ponds - and further down the track there are files containing puddles...) - I know a lot more about fly fishing and wine than database design...
There is one point ( a key point in the user interface) where I want to consider rivers and ponds as equivilent for one purpose, and ponds and puddles equivilent for another...
I can do all this with scripts and manual evaluation of the user inputs; but it's pretty ugly -- it seemed that fmp would do a very elegant job if I could convince it to do this:
For a record (in a portal) allow inputs into 'field A' that MUST BE validated by an already existing occurence of that fieldID (ie a related value) in EITHER the river or ponds file, and in 'Field B' [which happend to be in the same portal row] MUST BE validated by an already existing occurence of that fieldID in EITHER the ponds or puddles file.
The thing is that the way our business works, sometimes the 'river' can be a 'pond', and sometimes the 'pond' can be 'puddle' (but a 'river' can NEVER be 'puddle') - and I am trying to eliminate that from the data entry.
I hope I have not made this clear as mud - our rivers in New Zealand are really very clear!
Cheers,
bernt