|
| | | StrataFrame User
 
Group: StrataFrame Users
Last Login: Yesterday @ 3:00:39 PM
Posts: 244, Visits: 816 |
| | 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. |
| |
| | | StrataFrame User
Group: StrataFrame Users
Last Login: Yesterday @ 3:00:39 PM
Posts: 244, Visits: 816 |
| | 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 |
| |
| | | StrataFrame User
Group: StrataFrame Users
Last Login: Yesterday @ 3:00:39 PM
Posts: 244, Visits: 816 |
| | 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... |
| |
| | | StrataFrame User
Group: StrataFrame Users
Last Login: Yesterday @ 3:00:39 PM
Posts: 244, Visits: 816 |
| | 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 |
| |
| | | 
StrataFrame Developer
Group: StrataFrame Developers
Last Login: Yesterday @ 3:24:00 PM
Posts: 3,733, Visits: 3,926 |
| Now, it works. This is a SQL Server 2000 application. Could anyone provide a reason for this kind of behavior? 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  |
| |
| | | StrataFrame User
Group: StrataFrame Users
Last Login: Yesterday @ 3:00:39 PM
Posts: 244, Visits: 816 |
| | 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! |
| |
|
|