This issue is related to old version of DataObjects.Net!

We have found an issue in version 3.9.5 where the domain upgrade seems to erroneously delete records in a ValueTypeCollection table. If I dump the SchemaUpdateSQL.txt it shows the problem commands. In this example we have removed a base type in the object hierarchy so the number of records it is deleting is large.

First it gets a list of the types that need to be deleted.

Create table #idTable (ID bigint primary key)
Insert into #idTable Select distinct [dbo].[doDataObject].[ID] as ID from [dbo].[doDataObject] where [dbo].[doDataObject].[TypeID] in (70, 105, 39, 119)

Next it nullifies any references that may be pointing to these types.

Update [dbo].[doItemBase] set [Category] = 0 where [Category] in (Select ID from #idTable)

Finally it deletes any records that are of these types.

Delete from [dbo].[doItem] where [ID] in (Select ID from #idTable)

The problem is when it performs the same action for a ValueTypeCollection. ValueTypeCollection tables have their own IdGenerator tables and as such their identity generation is self-contained. Therefore if the command above is executed against a ValueTypeCollection table it will remove unwanted records.

The domain upgrade executes these commands against ValueTypeCollections:

Delete from [dbo].[doRelationship-AggregateKeys] where [ID] in (Select ID from #idTable)

Delete from [dbo].[doRelationship-AggregateKeys] where [Owner] in (Select ID from #idTable)

The second delete is fine as the owner of the ValueTypeCollection is a dataobject and may need to be removed. The problem is the first command as the IDs are self-contained in the ValueTypeCollection and may exist in the #idtable list. It can then mistakenly remove a whole host of ValueType records where the intention was to clean up a removed dataobject type.

Please respond ASAP as this is effecting production code.



asked Sep 07 '10 at 21:20

slamb2k's gravatar image


edited Sep 17 '10 at 14:23

Alex%20Ustinov's gravatar image

Alex Ustinov

2 Answers:

The issue must be fixed for now. Please see and try nightly build.

answered Sep 14 '10 at 05:22

Alex%20Ustinov's gravatar image

Alex Ustinov

edited Sep 14 '10 at 05:24

Thanks guys, we appreciate the quick turnaround on this one. My only concern when looking at the changelog is this other line:

2010.06.07 - Object model builder now sorts field names. Model built is no longer depends on an order properties extracted by reflection via 'GetProperties' method But negative consequence at the same time old FastLoadData content becomes unusable (it is better to nullify FastLoadData field).

We would prefer not to have to nullify the FastLoadData as it usually means a hell of a lot of deadlocks in the meantime while it rebuilds. Could you just clarify what the impact of installing this version is on FastLoadData? Do we have to nullify everything?

answered Sep 14 '10 at 07:06

slamb2k's gravatar image


Recently we resolved the issue described here: fastloaddata not rebuilding correctly. The resolution is the following: we now sorting PropertyInfos extracted while building ObjectModel. So new FastLoadData is incompatible with old ones. And Yes you have to nullify everything.

(Sep 17 '10 at 14:31) Alex Ustinov Alex%20Ustinov's gravatar image
Your answer
Please start posting your answer anonymously - your answer will be saved within the current session and published after you log in or create a new account. Please try to give a substantial answer, for discussions, please use comments and please do remember to vote (after you log in)!
toggle preview

powered by OSQA