I am defining the table in DDT, creating a BO, then pointing the BO to the table via the BOM.  These are derived fields from the DB, to be sure, but they are technically not custom.  I don't think I would need custom bindable property descriptors.  I'll take a look at this.

The BO isn't even completed with the data retrieval method and I get this:

orderid = 'this.orderid' threw an exception of type 'System.InvalidCastException'

The orderid field is set to INT.  The field that I am retrieving to fill the table is an INT, as well.  This is quite confusing.  I am going to blow away the table, the BO and the references on the form to the BO and start over.  I have been working on this for almost 6 hours.  I doubt starting from scratch will make any difference. 

Btw, I have confirmed that the stored procedure used to fill the table works perfectly.  An orderid is being returned that is an INT.

Confusing.
Bill

Added a watch to the variable loValue (which looked like it had a value).  It shows this:

loValue 0x0000000000004ff8 object {long}

Long?!?  The type ought to be Int.  Hmmmm.  Maybe I am on to something here...

The table in SQL Server has the orderid field defined as INT.  That field is selected in a stored procedure, like this:

SalesOrderMaster.orderid AS orderid

When I saw that the field was showing up in the BO as a LONG, I did this:

CAST(SalesOrderMaster.orderid AS int) AS orderid

Now, it works.  This is a SQL Server 2000 application.  Could anyone provide a reason for this kind of behavior?

Thanks!
Bill

I would have to set this up on an SQL Server 2000 machine...but it was actually SQL Server passing it over as long...not the BO converting the value.  It has been a while since I lived in SQL Server 2000 as we only use 2005 (and soon 2008) any more in the field.  However, if I am not mistaken, I think that when a field was derived in SQL Server 2000 and it was not explicity defined in a variable or from an underlying field table, it always went the the larger of the values...in this case LONG (BIGINT) over INT.  I would have to get my head back into the older rules...but at any rate, I am glad you got it figured out.

Now you have my curiosity up...I will have to load a 2000 machine up and give it a go

Thanks for the response.  I long to be on SQL Server 2008.  Our adoption of newer versions is a bit slow.  I did get authorization to obtain SS2008 for installation and migration later this summer.  I expect to be blown away by the improvements.  But, I also expect a good chunk of work getting all of the databases relocated.  It will be fun work, though!