Hi Charles,
Although there may be good reasons for this, have you carefully thought through
the purpose of having so many fields carry through to the child panel? If it
is because the unique index (Primary Key) on the parent panel carries many
fields to uniquely identify the record then you should perhaps consider using a
non-data loaded unique field as the unique identifier, such as an incrementing
number field (or Ralph's "Moment" identifier); then the child panel only needs
one field to bind it to the parent, and the data from the panel is always
accessible through the link for either reporting or other calculation purposes.
Of course there can be good reasons to bring multiple fields through a panel
link, but from what you are saying it does sound a little excessive, and will
mean that there isprobably lots of data reducancy in the database.
For instance you might have a contact register where you have an address book.
It might initially seem fine to have the First and Last Name as the Primary
Key, but then later you find duplicates and so you add, date of birth, or phone
number or address fields to make the index unique. But say you later add a
contact register panel your child panel needs to have each of those field
making up the Primary Key, plus whatever data is coming duplicated in the Child
record. By replacing the data loaded Primary Key fields with say one unique
autonumber field, only one field is needed in link field to the child panel.
Apart from the redundancy issue if any of the data in a parent's Primary Key
field change you have an issue of needing to cascade the data change into the
child panel. For these reasons I always try to have a non-data loaded field as
the unique identifier for a record.
Sometimes you want to pull "default" values from a parent into a child, and the
link fields can help you accomplish that, but in many cases (but not all) they
too can be condensed back into a single identifier and using field formulas on
Create to pull through defaults.
I think you have not so much hit a limit with the capabilities of DP, but more
that there is some work to be done on the application design. I do not think
other database products would make your problem go away.
Regards
Brian
----- Original Message -----
From: Charles G. Wolf
To: Dataperfect Users Discussion Group
Sent: Monday, April 28, 2008 5:55 AM
Subject: Re: [Dataperf] Re: Panel Link Question
Hi Ralph,
I thought so too, but I added up the field lengths and they only come to 192,
including the fields with won't carry through the link.
In the meantime, I think I've discovered I'm doing something wrong in
designing the link. (It's been years since I've done any more than superficial
design work). After creating the child record through the link (manually
filling in the values not carried through the link), upon returning to the
parent record and trying to view the related record, the link doesn't know it
exists. Very strange! I know I'm doing something wrong, but can't put my
finger on it.
Charlie
Ralph Alvy wrote:
There's a limit in terms of amount of data, not in terms of number of
fields. Sounds like you're passing that limit.
Charles G. Wolf wrote:
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
<font face="Times New Roman">Hi Everybody,<br>
<br>
Is there a limit on the number of fields that can be carried from a
parent panel to a child panel via a panel link? Fields 1-6 in the
Link Key Field List come through fine, but 7-10 do not. The index
selection matches the first 10 fields exactly, and in order. There
are 12 fields total in the index.<br>
<br>
I've been looking through all the documention I have, including Ralph's
book, but I can't locate the source of my problem.<br>
<br>
Thanks.<br>
Charlie Wolf<br>
</font>
</body>
</html>
_______________________________________________
Dataperf mailing list
[email protected]
http://lists.dataperfect.nl/mailman/listinfo/dataperf
------------------------------------------------------------------------------
_______________________________________________
Dataperf mailing list
[email protected]
http://lists.dataperfect.nl/mailman/listinfo/dataperf
_______________________________________________
Dataperf mailing list
[email protected]
http://lists.dataperfect.nl/mailman/listinfo/dataperf
