Thanks for the heads up.  in this case I'm joining to another table in the stored proc so I think there will always be a column.  Since I'm doing a left join, I'm testing for null in the initial select and returning a "NO PO NUMBER" string in the case of a null value.

This exercise was a reminder, however, to actually look at the test data before making ***-umptions about the results. (hey that's cool, I put in a hyphen to emphasize the old trope about assumptions and the parser censored me ) The ORDERS table in the Strataframe Sample Data is mostly blank in the or_ponumber field and I really suspected I was having a series of senior moments when I finally got the binding to work, did my thing to check nulls and still ended up with a blank textbox on the screen and a blank in the field in the currentview.  Thought I may have forgotten everything I knew about SQL. 

But of course I was getting just what I asked for - I just didn't know I'd asked for a column where most of the values were blank

I am going to test now to see if an exception is thrown if there is no data at all in the cursor as I'm starting to think the gist of your suggestion may be that custom props do not behave like bomapper props when the query pulls an empty recordset. 

Honestly I only do this when there is the potential for this to occur.  If this should never occur based on my logic, then I don't do this so I get an error message preventing any other downstream errors.

I understand Greg's suggestion for a try - catch so you can have fill methods that do not use that joined column, but my question is :

Do custom field properties behave differently from bomapper field properties if the fill method returns no records and is that what we are testing for and would that need to be handled if there were no customer field props?

If you are just pulling from thr CurrentRow, then no.  They behave just like any of the other properties.  Obviously if you add additional logic past just retrieving the value then you have need to take this into account.  But otherwise it will behave like any other field property.