Hello there,
I think i encountered a huge bug.
I was trying to do: delete an instance of an context by marked it as Delete, and, if it return this error:
The DELETE statement conflicted with the REFERENCE constraint
I secondly i mark it as EntityState.Unchanged, and count the Navigation Properties to show the user, how many references that instance has and where they are like this:
Example: veicleBrandinstance.VEICLES.Count
veicleBrandinstance.BRANDMODELS.Count
The problem is, the second time i try to delete that instance, the model automatically sets in the DB the VEICLES and BRANDMODELS reference to NULL and DELETES the reference allowing the model delete the instance of veicleBrandinstance. ___I didn't program the Set null , the model does that himself.___ It only happens if the foreing keys propertyes in VEICLES and BRANDMODELS are ALLOW NULL.
Other Problem is doing the same process but the VEICLES and BRANDMODELS foreign keys to BRAND are NOT NULL i can only make the count the first time i try to delete. The second time i try to delete doing the same process above:
1- mark as deleted
2 - save changes
3 - Check the error
4 - if error like above mark as unchanged
5 - count the properties
this time the count returns zero to all the properties.
Solution:
if i don't count the properties, this wrong behaviour of setnull does not happen. Simple as that.
Maybe counting the properties makes some other stuff in the background and does that.
To reproduce the error follow those steps:
1- mark as deleted (instance referenced ellsewere)
2 - save changes
3 - Check the error
4 - if error like above mark as unchanged
5 - count all the properties
6 - Expected result - Succsess
7- Do the same process again
8 - result: deletes the instance and deletes all referenced propertyes
9 - try again the above steps with no count of properties.
Please let me know if something does not make sense.
Thanks.
Comments: Hi Skiptpawa. Since I haven't heard back from you in a while, I'll close this bug as no repro. If this is still an issue for you, please to provide a small _test_ code to reproduce this issue.
I think i encountered a huge bug.
I was trying to do: delete an instance of an context by marked it as Delete, and, if it return this error:
The DELETE statement conflicted with the REFERENCE constraint
I secondly i mark it as EntityState.Unchanged, and count the Navigation Properties to show the user, how many references that instance has and where they are like this:
Example: veicleBrandinstance.VEICLES.Count
veicleBrandinstance.BRANDMODELS.Count
The problem is, the second time i try to delete that instance, the model automatically sets in the DB the VEICLES and BRANDMODELS reference to NULL and DELETES the reference allowing the model delete the instance of veicleBrandinstance. ___I didn't program the Set null , the model does that himself.___ It only happens if the foreing keys propertyes in VEICLES and BRANDMODELS are ALLOW NULL.
Other Problem is doing the same process but the VEICLES and BRANDMODELS foreign keys to BRAND are NOT NULL i can only make the count the first time i try to delete. The second time i try to delete doing the same process above:
1- mark as deleted
2 - save changes
3 - Check the error
4 - if error like above mark as unchanged
5 - count the properties
this time the count returns zero to all the properties.
Solution:
if i don't count the properties, this wrong behaviour of setnull does not happen. Simple as that.
Maybe counting the properties makes some other stuff in the background and does that.
To reproduce the error follow those steps:
1- mark as deleted (instance referenced ellsewere)
2 - save changes
3 - Check the error
4 - if error like above mark as unchanged
5 - count all the properties
6 - Expected result - Succsess
7- Do the same process again
8 - result: deletes the instance and deletes all referenced propertyes
9 - try again the above steps with no count of properties.
Please let me know if something does not make sense.
Thanks.
Comments: Hi Skiptpawa. Since I haven't heard back from you in a while, I'll close this bug as no repro. If this is still an issue for you, please to provide a small _test_ code to reproduce this issue.