none
No Feedback about a showstopper bug from Microsoft RRS feed

Answers

  • If this is a show stopping issue, you should do a MSDN support incident for quicker response. They come with hte MSDN universal subscriptions, very handy. Once contacted, they will research the problemm and get back to you in a very timely fashion and tell if there is a hotfix or work on getting one to you if it is a true problem. The connect method does accept reports, but is not intended for a quick turnaround.
    Friday, October 10, 2008 9:01 PM
    Moderator

All replies

  • If this is a show stopping issue, you should do a MSDN support incident for quicker response. They come with hte MSDN universal subscriptions, very handy. Once contacted, they will research the problemm and get back to you in a very timely fashion and tell if there is a hotfix or work on getting one to you if it is a true problem. The connect method does accept reports, but is not intended for a quick turnaround.
    Friday, October 10, 2008 9:01 PM
    Moderator
  •  

    Thanks, I did so yesterday. I have no MSDN subscription, so I agreed with the support to file a request at costs of 300 Euro (!), however they said that Microsoft will not charge me if this is a bug and I think it is one, so I take the risk.

     

    I'll post the results here (I hope soon).

     

    Karlo

    Saturday, October 11, 2008 6:45 AM
  • GetChangeSet is throwing this error because the object is in an invalid state. I'm not convinced the original design for this method was to clean up invalid objects before SubmitChanges.

    [)amien
    Friday, October 17, 2008 3:28 PM
    Moderator
  • Whatever the original design was, GetChangeSet should not throw an error in this situation because SubmitChanges wouldn't either. So I don't think one can say that the object is in an invalid state _before_ GetChangeSet is called. However, after GetChangeSet throws the error, the object is de facto in invalid state as a subsequent call to SubmitChanges will fail thereafter. So GetChangeSet _puts_ the object into an invalid state.

     

    I understand this situation was not considered in the original design (and that's often the reason for bugs). Why doesn't Microsoft at least comment the bug report on the connect.microsoft.com page? It has not been answered since five months. Looks like a unidirectional "connect" to me.

     

    Karlo

    Saturday, October 18, 2008 5:34 AM
  • In the repro we have here SubmitChanges throws exactly the same error as GetChangeSet regardless of whether you call GetChangeSet or not - they both call the same sync code in the object tracker.

    [)amien
    Saturday, October 18, 2008 5:40 PM
    Moderator
  • Damien,

     

    If you look at the original bug log, you'll see that one way to use this is in validation - i.e. we want to display validation messages to the user, by iterating over the changeset and the running validation logic on the changed objects.  In that scenario, the fact that SubmitChanges would give the same error doesn't really help.  (We aren't going to call SubmitChanges if the validation fails).

     

    Also, as per the original bug log and the thread in this forum where I first raised the issue, Microsoft people certainly felt it was a bug at that time.  Subsequently, I have corresponded by email with Microsoft and again the indication was that this was a real bug.  The only question was whether the fix would make it into SP1.

     

    The fix didn't make it into SP1.  Currently, I am using the workaround which I posted on MS Connect.  I'm not 100% happy about it, but it is working.  Workaround or no workaround, this definitely seems to be a real bug.

     

    John

     

     

     

    Monday, October 20, 2008 4:20 AM
  • The problem here is that the GetChangeSet method is designed to return the logical change set that SubmitChanges will operate on which is not really the same as the requirement described in the bug "which objects have been edited".

    I agree that an API to get the changes currently being tracked without any processing/syncronization would be useful but I don't think changing the existing method and breaking existing applications would be the right approach.

    [)amien
    Monday, October 20, 2008 6:22 AM
    Moderator
  • Returning the logical change set that SubmitChanges will operate on would be fine.  Throwing the exception is the problem ;-) (Yes, I can see that one possible implementation would throw an exception.)

     

    But I still feel strongly that Matt Warren was right when he wrote "You should not be getting the exception. It must be a bug. ".

     

    Having said that, if it really is impossible to provide a non-throwing implementation, how about throwing an exception which actually has some extra properties - in particular a property that contains the instance of the object on which the "null foreign key" exists, and ideally another property which contains MetaAssociation object for the relevant association.  At least that would let us catch the error and do something meaningful in order to respond to it.  Right now, all we get is an InvalidOperationException, which doesn't contain enought programmatically-readable information for a meaningful response.

     

    John

    Monday, October 20, 2008 6:43 AM
  • Damien,

    I have now put together a repro sample that demonstrates a situation where SubmitChanges will succeed without GetChangeSet being called before but will fail if it was called.

     

    So I still think that GetChangeSet in fact can put the data context into an invalid state.

     

    I have sent this sample to Mr. Ryszard Gawron (Developer Support in Germany) who is responsible for my service request. If you want me to send this sample somewhere else, please let me know here.

     

    Karsten

     

    Saturday, October 25, 2008 1:17 PM
  • Interesting. I'm dealing with Ryszard on the issue so far so will take a look at this when he forwards it on.

    [)amien
    Saturday, October 25, 2008 4:32 PM
    Moderator