Lookup problem

[gavinwebb]

I have a lookup on a webform done in exactly the way it works in the examples accounts application.  The one where it looks up the customer from the invoice update form.

If I uncheck "Display description instead of value" then it does the lookup and displays the ID value in my lookup field (as I would expect) and it stores the ID value in my form field when it saves.  All works fine.

However when I check "Display description instead of value" it behaves as expected in terms of it displaying the name I tell it to display, however it does not save the ID field anymore in my form field.

I have double checked everything by comparing to the accounts example but can't see what is wrong.

[Bruce]

In order for "display description instead of value" to work, the lookup-file needs a unique, single component, key on the description field. There is already a unique, single component, key on the value field, bu it needs one on the description field as well.

cheers
Bruce

[gavinwebb]

Yup, that solved it - thank you.  All working now, apart from one thing......if I check the box "auto-lookup on insert" then my form doesn't appear properly at run time - just a blank form.

Any idea?

[Bruce]

yes, "auto lookup on insert" appears to be a bit broken at the moment. I'll try and get that fixed for the next build.

update:  fixed for 6.18

[Robert Iliuta]

Hallo Bruce!

Code: [Select]

>In order for "display description instead of value" to work, the lookup-file needs a unique, single component, key on the description field.
There is already a unique, single component, key on the >value field, bu it needs one on the description field as well.
this description MUST be in docs! I search docs but didn't find so if it's there apologies. I never know that the "display description instead of value" must be a key... and I never know why sometimes doesn't work and return the ID instead of name. uhhh (fight with this many times ...hours)
Please maybe you can put a small description on the template under "Description Field:" (need to be a key)

and why description should be a key?


Thank you,
Robert

[Bruce]

Hi Robert,

The current doc for the "Display Description instead of Value" switch says;

If the foreign table has a key with just the description field in it, then you can display the Description field to the user, and the Value field is completely hidden. This makes a very good lookup because the user does not need to see, or remember, obscure or arbitrary codes.

Did you read this section, and miss the point about the key, or did you not see it? (real question - the answer helps me make it clearer)

>> and why description should be a key?

the description needs to be in a (preferably unique) key (by itself) because when the user completes the form only the visible description is sent to the server. The server then uses the GetDescription method to turn that into a code for storage in the table.

cheers
Bruce

[Robert Iliuta]

Hallo Bruce,

>Did you read this section, and miss the point about the key, or did you not see it? (real question - the answer helps me make it clearer)
I didn't found the answer on doc... now I found here: http://www.capesoft.com/docs/NetTalk8/NetTalkWebFunctionality.htm#FormFieldLookupSettings
but it will be good to make bold the KEY or to make a small note after with red color...

this part is also little bit confused: "If the foreign table has a key with just the description field in it"  better to see something like "the description field must be a key" and also on the template you can put a small note before or after the field, this will make more clearer the message.

also a bit hard to find in docs... much better to have a search locator for this to search in all docs related to web server.

Thank you,
Robert

[terryd]

Hi Bruce.

the description needs to be in a (preferably unique) key (by itself)

Is this correct, the key doesn't necessarily have to be unique? What happens if there are 2 keyed records with the same description?

[Bruce]

Hi Terry,

the key should be "conceptually" unique - but it doesn't enforce the actual Unique attribute.

If you do have multiple records, then it'll pick one. Whether that's the right one or not I guess depends on how non-unique the key actually is.

Of course using a unique key is preferable.

cheers
Bruce