SourceForge has been redesigned. Learn more.
Close

#11 Null reference after meddling with Objectified type

closed-fixed
None
8
2006-11-14
2006-11-12
No

Not exactly sure how I caused this, but it's broken my
project (model of scoring database for orienteering)
and I can't fix it after more than an hour trying.
The file's attached.

"Event" was related to "Series" incorrectly and I
objectified the relationship before trying to delete
it, and now most is deleted but any reference to the
remaining bits cause a "not set to an instance of an
object" or Visual Studio crashing.

If you do work out the cause, I'd appreciate knowing
how I can recover my project without re-entering
everything.

Discussion

  • Anonymous

    Anonymous - 2006-11-12

    orienteering data model

     
  • Kevin M. Owen

    Kevin M. Owen - 2006-11-12

    Logged In: YES
    user_id=1014759

    Hi Clifford. I believe I have identified what was causing this to happen, and I'll make sure it gets fixed for our next release. In the mean time,
    I have manually fixed your model file to remove the remaining parts of that relationship. The corrected file is attached.

    Thank you for reporting this, and I apologize for any inconvenience this bug has caused.

     
  • Kevin M. Owen

    Kevin M. Owen - 2006-11-12
    • priority: 5 --> 8
     
  • Kevin M. Owen

    Kevin M. Owen - 2006-11-12

    Fixed version of Orienteering.orm

     
  • Anonymous

    Anonymous - 2006-11-12

    Logged In: YES
    user_id=1608419

    Wow - that was super-quick! Thanks!
    I hope my little model is interesting to someone.
    BTW, the sourceforge documentation file about how
    to create a database schema has been redundant for
    some time now.

     
  • Brian Nalewajek

    Brian Nalewajek - 2006-11-13

    Logged In: YES
    user_id=1501525

    Hi,
    I'm not on the team, just another tester. Saw that same
    error message "not set to instance..." (actually got the
    error when trying to rename the objectified prediacte to a
    better (and shorter), name, and wasn't sure why that popped
    up. I deleted the whole objectified predicate, and readded
    it. I had some sample data associated with the fact type,
    and it may have had something to do with it. I made sure I
    cleared out any sample data before re-entering the fact
    elements (BTW, I also realized that the 4 arity type I had
    should have been a trinary fact objectified, and that then
    used as the object in a binary to keep all the facts
    elementary - had to think that one through a few times to be
    sure. I guess it's possible that the non-elementry fact I
    first used, somehow caused the error). In any case, the new
    trinary fact type worked, and I was able to give the nested
    fact type a new name, without error - of course the IUCs
    were a bit different with the 3 arity fact too.
    Obviously, there's no definite answer in the above, but
    there are things to try. Clear the sample data, check the
    arity, the IUCs, and the properties of the OP. Also, make
    sure that there are no (other), errors or warnings in the
    errors ist tab, before and after rentering the fact type.
    Yea, it would be great if we had the fully functional,
    fully tested and documented product to work with, but I
    guess this is the only way to get there. BRN..

     
  • Kevin M. Owen

    Kevin M. Owen - 2006-11-14

    Logged In: YES
    user_id=1014759
    Originator: NO

    A fix for this has been checked in with revision 850 in the Subversion repository, so this should hopefully no longer occur in future releases.

     
  • Kevin M. Owen

    Kevin M. Owen - 2006-11-14
    • assigned_to: nobody --> mcurland
    • status: open --> closed-fixed
     

Log in to post a comment.