I would structure the WHERE clause in the SQL which retrieves the code like this:

WHERE activeCode = 'Y' OR codeId = :xyz

Where the parameter 'xyz' is the code value on the record you are displaying.

alternatively you can retrieve all rows and then apply a filter like the 'WHERE' clause above.

You may insert two column objects for the same column in the datawindow:

One column make visible for the current row. Show here only values that are valid for selection. You have to change the list if the current row changes, so you need a little bit coding. You could retrieve as Matthew suggested or you may simple use a filter.

One column make visible for rows that are not the current row. Use a DDDW that contains all values. So you can always see description even if you filter the DDDW of the other column.

Hi David;

    Yes, this seems easy but it can be a bit interesting from the historical reporting perspective. That is, you often need to older deprecated values so that the column information displays correct, yet in update mode - you need to restrict what the user sees selection wise.

   To make sure that the users see the current value (regardless of its status) just let the AutoRetrieve feature handle the DDDW value set with no restrictions. This will allow older assigned codes to display correctly. However, when the user wants to change a DDDW value you need to only show them the active codes. Here is what I do in this case ...

1. Add a DDDW "drop" and "Close" event to the DC
2. On the "Drop" - use  a GetChild() command to get a reference to the DDDW
3. Now filter the DDDW result set to display only the "active" codes
4. On the DDDW "Close" event, remove the filter

With the above approach you can now handle historical code display and active code assignment to the column in question.

HTH

Regards ... Chris

Chris those would handle the "dropping down' of the dddw but how do you handle the use of scrolling using the keyboard?  Would you also create a key event and prevent it?

    I was thinking that the column would be protected and thus no updating for users that have display only authorization or where the data is "historical" only and thus logically "locked" from updating. For an example, a PO that has been processed and thus the data is "historical" only.

    Where the data represents an active business transaction and can still be modified, allowing the user to have the DDDW "Drop" and then scroll through the values would not be an issue IMHO. However, I have also seen the case where certain subsets of the DDDW result set are applicable based on the state of the business transaction or context of the surrounding data. Thus a second filtering may be required to further restrict what the user sees (or scrolls through) when the DDDW "Drop" occurs.

HTH

A simple answer would be to examine the ACTIVE flag in the selected row of the DDDW.
If the value is ACTIVE, proceed as normal.
If the value is INACTIVE, display an error message and do NOT proceed as normal.

Olan