I think you're right. It's not just the
number of bytes, but the number of fields factors in. Perhaps it's
because there's some overhead in the bytes needed to carry over each
field.
Brian Hancock wrote:
Hi Charles,
If you traverse a link to create the
record, then you only need to bring through a single unique primary key
field (eg ID field) into the Child Panel, and on each of the target
fields in the child panel include a formula referencing back through to
the source field in the parent panel (via a reverse of the link that
got you to the child panel). Set the formula to only trigger on Create.
You can bring any number of fields
into your other panel.
Regards
Brian
PS. There is something funny though
about long indexes, I just tried a very quick experiment to see what
would happen. I started with 4 x A50 fields in the parent panel, 4 x
A50 fields plus a G999::IN field in the child panel, and created a
panel link from the parent. Each panel had one index with all fields. I
filled the first parent record with "aaaa...", "bbbb.." etc The data
came through the link ok, but after the first child record when trying
to save the 2nd I got a dujplicate record message, (despite my 5th
field making the child record unique), which made me suspect that the
either the long index or the numeric component was at fault. So I
converted the 5th field in the child panel into an A3 field, but I got
the same problem. So I lengthen the last A50 field to A53, so I could
add another 3 characters to make the record unique and that worked. so
I could get a unique record with 203 bytes in 4 fields, but not 203
bytes in 5 fields.
-----
Original Message -----
Sent:
Tuesday, April 29, 2008 12:47 AM
Subject:
Re: [Dataperf] Re: Panel Link Question
Hi Brian,
Actually, I'm adding on the address management panel that I asked you
about a month ago. I need to carry through the old address to the
managment panel prior to changing it, etc. After triming some
superflusous fields, I tried carrying through the following to the
child record.
Last Name: A25
First Name: A25
Addr 1: A35
Addr 2: A35
City: A35
State: U2
Zip: N99999-9999
The State and Zip fields would not come through. I didn't think the
byte length of the combined fields reached DP's limit, but I guess it
did.
Charlie
Brian Hancock wrote:
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 -----
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
_______________________________________________
Dataperf mailing list
[email protected]
http://lists.dataperfect.nl/mailman/listinfo/dataperf
_______________________________________________
Dataperf mailing list
[email protected]
http://lists.dataperfect.nl/mailman/listinfo/dataperf
|
