Group: StrataFrame Developers
Posts: 6.6K,
Visits: 6.9K
|
This is not a bug as is designed this way. You are trying to perform a CopyDataFrom and then performing a save immediately afterward assuming that the BO will copy the data in as dirty...it doesn't. The CopyDataFrom WILL NOT COME IN AS DIRTY (as you have discovered). So if you want to move data into the BO then save it from a data table, either enumerate the rows in the inbound data table and manually add each row, or after you have performed the CopyDataFrom, enumerate the rows in the CurrentDataTable and set the row state of each row to Modified and that should make the records dirty.
One major issue of note here if you take the second approach would be primary keys. If you are bringing data into the BO that already has a primary key set, then you will have to account for this when the record is being saved (one of the several reasons the CopyDataFrom comes in as clean data). That is why in this example, I would take the first approach and manually add the records into the BO so that the BO logic can then work as it is designed to save the PKs (by creating new ones if necessary), etc. as they would if they were new records. On the flip hand side, if you want to keep the PKs the same, then you will need to set the PrimaryKeyIsUpdatable property on the BO to true as well as the PrimaryKeyIsAutoIncremented property to false. If you are using a SPROC on the INSERT, then you will most likely want to set the CRUD property on the BO InsertUsingStoredProcedure to false as well to prevent any PK issues. One last thought is that you will need to execute a SPROC prior to the save allowing PKs to be inserted (SET IDENTITY INSERT ON).
|