Having trouble with Portal not showing

[Hack]

Hi all

I just reworked my relationship table and smoothing out some of problems I getting with portals not showing within layout even through there is relationship?, if you have chance to have look at the attached FHPRO7 file and look at the layout Job instruction there are two portal one "items" and other "amendments" can any one see why I not seeing them? (As use them to enter data about the job instruction

I very stuck here, looking forward to seeing peoples suggestions

regards

Damian

print_specs_Clone-v6.fp7.zip

Edited July 18, 2006 by Guest

[Ender]

If you're looking to add items via the portals, you'll need to hit the checkbox in the Edit Relationship window to 'Allow creation of records in this table via this relationship'.

I would also suggest that you don't need to include the grandparent keys in the relationships. Just use the primary key of the parent table on both sides of the relationship. For example, with the Client <=> Job Instruction relationship, you only need to use ClientID as the key on both sides. With the Job Instruction <=> Items relationship, you only need to use the Job Instruction ID.

[Hack]

Hay thats great it works, I completely forgot I had to do that. Also I am new to the database world is there a glossery I can uses to work out the discription to what key words are like "grandparent keys" and "primary key"

also do each table need a unique id for every table??

Kind regards

Damian

Edited July 19, 2006 by Guest

[Ender]

I don't have a glossary for you, but these terms are common to all database applications so you should be able to find something out there. A primary key is the field(s) whose value uniquely identifies each record in a table. This is usually an auto-entered serial number. This is also called the parent key, since any other tables related via this key would necessarily be on the "many" (child) side of the relationship. Although you may not find "grandparent key" in a book, I'm referring to the child table's parent's parent.

It is not always necessary to have a unique ID for every table (child tables that have no children of thier own and don't have a self-join probably don't need it), but is is generally a good idea to have it in there anyway. It makes it a little easier to add child tables and self-joins later, and can aid in mapping imports and rebuilding the data for a table.

[Hack]

Hi Ender

that really helpfull

kind regards Damian