LookupC, LookupN cannot fill automatically

[peterth]

Re: LookupC, LookupN cannot fill automatically

The lookups can only work after "PID1" has been entered. I assume that just starting a new record doesn't automatically fill in PID1.

Yes

In that case, somebody would have to type in the value for PID1.

I set the PID1 = "P001" as Calculate field (dont' want user to key in to reduct the human error) for the default value for LookupC and LookupN

If that is true, you are really doing this the hard way. Instead of using this type of lookup, you should use the field rule "Table Lookup" on the PID1 field.

I don't want to use the Table Lookup due to I have a hundred product and don't want to select a wrong product and we have problem later with wrong input.

the concept I think when user create new record then all the default value is ready and shows at all field and then user can key just only the Start and End field only

My concept is it possible?
Please recommend

Thanks

[CALocklin]

Re: LookupC, LookupN cannot fill automatically

I think it's possible but I still don't understand where the value of PID1 comes from. Surely someone somewhere has to select it. If not, then it must always be the same value in every single record and that just doesn't make sense to me. My guess is that wherever that it's selected, that's where the other values should be created as well.

I could tell you more if I knew where PID1 was coming from. However, I haven't looked at the sample you posted above - I'll do that tomorrow and maybe that will help me understand. If you already know that it's not in there, please let us know where and how the value for PID1 is determined.

[CALocklin]

Re: LookupC, LookupN cannot fill automatically

I looked at your Test app this morning and the P_ID is set as a fixed default value. This doesn't make any sense to me - there might be a good reason for it but I don't understand what that would be. As I see it, if the P_ID is always going to be the same value, then they should not be stored repeatedly in the same table. [EDIT: I re-read your comments above and finally caught the fact that the values change twice a week which means the name and price would change but that still doesn't require a separate table if there is only one "item" per parent record - see next paragraph.]

This looks like you are setting up something like an order system and this is the "line items" table. If that's the case, I suspect that you are initializing it to a default value then allowing the user to change it. When the user changes it, there will still need to be a table lookup to fill in the other values (name and price) when then new P_ID is selected. That being the case, why not just leave the initial value blank and let the user select whatever he wants? And, if there is only one 'child' record per "order" (in which case the P_ID would not have to change), why not just put it in the main "order" table? A child table that always has only one record per parent table isn't really needed and would probably just add confusion.

If you really do need to do it the way you have it now, you will have to change the lookups to include the default P_ID value that is called out in the P_ID field. When the new record is first opened, regardless of what you enter as the default value for P_ID, the P_ID is initially blank and that's the value that your lookups in the other fields are trying to use - blank.
Change the lookups from this:
LOOKUPN("F", P_ID, "Price", "pd.dbf", "P_ID")
to this:
LOOKUPN("F", "P0003", "Price", "pd.dbf", "P_ID")

LATER:
I went back and tested something else that may work better for you. My assumption here is that the P_ID will most often be one value (hence the default) but occasionally the user will want to change it or add additional line items. If this is the case, you can set the default value of the P_ID just as you have but also add a table lookup to fill in the name and price. Then change the Name and TPrice fields to "User Entered" with no default value. If you do that, the Name and TPrice fields will fill in automatically to match the value in the P_ID field when a new record is started and they will also fill in automatically when the P_ID is changed. (See NY table in modified Test app attached.)

A few other misc hints:
- Don't use the same name for tables and sets. It works but it becomes confusing in some cases. Example - open the Forms tab in the A5 control panel and try to determine if a form attached to "NZ-Header" is in the NZ-Header table or the NZ-Header set.
- Don't use dashes or blank spaces in table names. In some cases A5 will change these to underscores. (See my "white paper" for other naming recommendations - this one is #8. If, like others, you don't want to use my specific recommendations, that's OK, BUT at least read and try to understand the reasons so you can develop a method of your own that will solve the issues.)

[peterth]

Re: LookupC, LookupN cannot fill automatically

Hi Cal,

Thank you for your quick response.
the application I try to develop is concern about assembly line for the part list. It has 5-6 parts so why I need to set it for default and don't want user select it by himself (to reduce the human error select the wrong part)

What you recommend me to do the below is I still have to touch some field?
However I will try it again.

Change the lookups from this:
LOOKUPN("F", P_ID, "Price", "pd.dbf", "P_ID")
to this:
LOOKUPN("F", "P0003", "Price", "pd.dbf", "P_ID")

[CALocklin]

Re: LookupC, LookupN cannot fill automatically

Check out the "LATER" section in my previous post.

I suspect there are still some missing details about exactly what you are trying to accomplish. If you have 5-6 parts (records), then the P_ID will be different on each of those 5-6 records and setting them all to the same default value won't work. If you are creating this table from some other table (vs. the user entering each line) then we need to know exactly how you are initializing this table. If you "don't want the user to select it by himself" then it must already be selected somewhere else. Knowing where that selection is will be critical to determining how to get it transferred to this new table.

[peterth]

Re: LookupC, LookupN cannot fill automatically

Thank you for your idea and many alternative solutions Cal.

I have the 6 part for the default. I create set (the attached file, my sample at the first post) I create set 1:1 one for each part (my sample I do it just for 2 parts NY and NZ)

However I will try the solution and your idea you gave.

Thank you for you and everyone for your help and idea.
I don't feel I'm alone and feel better to use Alpha5 and when I have problem we also have the community to discuss and share ideas with kindness people here

[Tim Kiebert]

Re: LookupC, LookupN cannot fill automatically

This is what I see as going on. ( as far as the default values not showing in your form)
Each of your two child tables have default values being set. As individual tables they work fine. You have those two tables added to a set, each one linked 1 to 1 with the parent. You have a form based on this set. When you start a new record in that form you are only creating a new record in the parent table. It is not until you actually enter one of the fields on the form that belong to a child table that a record is started in that child table.

It is not really any different than if you had the child tables linked 1 to many and had embedded browses on the form. You could start a new record in the parent but there would not be any child records created until you entered them in the browse.

(as far as the over all work flow I think I am still just as confused as most of the others)