Problem with database providers

Well, if the value holders are optional, you should take that into consideration in your provider also.

if (string.IsNullOrEmpty(param))

{

    return null;

}

else

{

    return query(...); 

}

There are solutions you can try with nesting of code templates, but you will still have to have a provider that handles exceptions for the corner cases.

Regards, 

Jostein 

I realize that I wasn't clear enough in explaining what I was trying to do.  I have a minor code table with a key code and a description.  I want to display the description so that a business user can pick say "Administrator" or "Power User" and the SRL that gets generated is "AD" or "PU".  So when the User is at the RMA they see the descriptions rather than the codes. I defined two values holders one for the code and one for the description, but I keep getting two selections and when I change the selected description, the code does not automatically change to the new selection's value.  How can I make this happen?

     Thanks,

     Tom

To achive that I assume you should have already tried the Dynamic Options in the Value Holder where the description needs to be retrieved based on the key.

On a very different note, I have faced issues with Database Providers when the data retrieved from database is quite large. At the RMA level, the providers almost freeze. This was an issue with 6.1.8 although I feel that there has been some improvement in new versions.

Quick thought: did you try using Custom Providers ? As Jostein mentioned, the coding can always be handled so that you are in complete control on the data retrieved from database.

If I have understood you wrong then do let me know !!

Now I understand

I would probably solve this in one of two ways. First, provider implementations are capable of returning different values for different contexts, i.e. a separate value for the display (RMA/user) and the generated code (SRL content). A very simple solution is to select your (code, display) data as key, value pairs, and return the key as the content value and the value as the display value.

If you have a slightly more complex code table, e.g. separate numeric primary key, valid from/to dates, etc, you could solve this using two value holders. The first value holder would select identifier and the display value as the key, value pair. This is the provider you use to make the user select a value. The content value will now be the unique identifier corresponding to the selection the user made, and you use this as the argument in a dynamic override to the second, hidden provider that selects the content value based on the identifier. 

The second provider should handle invalid input without failing, as you will have several  situations where the input will be invalid. It should also extend the NdTemplateLogicalValueProvider (or something similar - can't remember the exact name right now). By implementing that interface you tell blaze that this is a derived value holder, and that the value should not be stored but computed when needed. 

HTH, 

Jostein 

Here's what I ended up doing.  I created a separate code template with two value holders.  One was used for the display and one for the SRL.  The trick was to change the SRL value holder to use "All - No Selection".  Then it always retrieved the value I needed (if there ends up being two rows with the same value for the description but different keys, then I hope the testing catches it).  That way, each time the selected value changed, the code value changed with it.  I didn't need to write a custom provider after all (client is not fond of those because of the testing cycle for the code).

     Thanks for all your help,

     Tom