in

The ORM Foundation

Get the facts!

IComparer.Compare method error.

Last post Tue, Nov 5 2013 13:09 by mnnoon. 5 replies.
Page 1 of 1 (6 items)
Sort Posts: Previous Next
  • Fri, Nov 1 2013 21:32

    • mnnoon
    • Top 10 Contributor
      Male
    • Joined on Wed, Apr 16 2008
    • Lawndale, CA
    • Posts 60

    IComparer.Compare method error.

    I have an error IComparer.Compare() method and looking for fixed:

     Occurs after I added sql ER Extensions.

    ---------------------------
    Microsoft Visual Studio
    ---------------------------
    Cannot save 'C:\file\OrmImport.orm': Unable to sort because the IComparer.Compare() method returns inconsistent results. Either a value does not compare equal to itself, or one value repeatedly compared to another value yields different results. IComparer: 'System.Array+FunctorComparer`1[Microsoft.VisualStudio.Modeling.ModelElement]'.
    ---------------------------
    OK  
    ---------------------------

    Filed under: ,
  • Sat, Nov 2 2013 1:37 In reply to

    Re: IComparer.Compare method error.

    Hi Marc,

    Could you give a few more details here? I don't have 'sql ER' extensions. I'm guessing you mean the 'Map to Relational Model' and 'Map to Barker ER Model' extensions have been turned on in the 'Extension Manager' dialog.

    • Did you turn the view extensions on as well (Relational View, Barker ER View)?
    • Do you have problems with one extension (try both)?
    • Were you able to turn on the initial extensions and only have issues with the subsequent save?
    • Can you easily repeat this with your model?
    • What version of VS and NORMA are you running (look in the Help/About dialog to find the NORMA version)
    • Did you attach another instance of VS and try to get a callstack?
    • Is your file in a project with an ORMCustomTool generator, or do you just have it in a solution?
    • Are you willing to send me a file that does this?
    • What is the origin of the file (its name suggests and import).
    • <Be proactive and answer some questions of your own>.

    I'm sure you've seen a legitimate failure and I'd really like to help here, but you haven't given me enough information to even consider investigating this issue. If you could spend a little more time drilling down your issue for me I'm sure we could get it resolved.

    -Matt

  • Mon, Nov 4 2013 12:48 In reply to

    • mnnoon
    • Top 10 Contributor
      Male
    • Joined on Wed, Apr 16 2008
    • Lawndale, CA
    • Posts 60

    Re: IComparer.Compare method error.

    I sent an email with more details.  But I think the problem has to do with either the underscores for field names like "_Namepart1_Namepart2" or fields that have the same name. Either that or there is some kind of reference where two object reference each other and it turns into infinite loop as the program builds a list of variables.  Also the table names start with an "_" underscore which may be illegal or be a special character in the Norma tool.

     Thanks,

    Marc

  • Tue, Nov 5 2013 1:07 In reply to

    Re: IComparer.Compare method error.

    Hi Marc,

    Thanks for the files. I have the issue sorted out locally. This comes from a sort return on lin 2920 in ORMModel\Framework\Shell\SerializationEngine.cs, which tries to get a consistent sort order when two named elements have the same name. The comment says that deferring to a guid compare wreaks havoc on baselined tests (this is true, it makes the files effectively uncomparable). However, to account for this situation the code simply picked an arbitrary value. It looks like VS2012 is using a slightly different sort algorithm that calls back a second time with (y,x) instead of (x,y). Favoring one over the other based on position has worked through three VS versions, but blows up badly here. The fix is easy: just return 0.

    Your model does have a ton of duplicate names in it. These will be noted in the next VS release, which flags duplicate readings in the model. I'm not 100% that this is what is causing you to hit this, but there is a pretty good change. I'd suggest scanning the model browser for duplicate fact types to fix and then seeing if you can generate and save the relational model.

    I should release the next official NORMA version within the next couple of weeks. If you're totally blocked on this, let me know and I can get you an intermediate build that fixes the problem.

    -Matt

  • Tue, Nov 5 2013 2:54 In reply to

    • mnnoon
    • Top 10 Contributor
      Male
    • Joined on Wed, Apr 16 2008
    • Lawndale, CA
    • Posts 60

    Re: IComparer.Compare method error.

    Hi Matt, 

    Thanks for the info.  Yes I definitely am interested in testing out an intermediate build.  I wished the orm model would say dupe so I'd know which entity or fact was causing the problem (like two red lines instead of just one).  I'm trying to build the model after connecting everything up in the tool.   Then verifying everything is working by verifying that the data matches correctly especially the primary keys identity and seeds. http://tinyurl.com/o53msc6

    So I could probably get this thing working in VS2010. Hmmmm  I didn't even consider that. lol  I think Microsoft is now constantly in flux with these updates.   Everything seems to be devolving into web matrix and these Eclipse like Nuget updates so that probably the cause of the change to the sort algorithm.  Hopefully that is not in the options somewhere.

    I would do more testing but I need the process to be dirt simple and I feel bad bothering you if it slows you down during the next build cycle.  Can't wait to get my hands on the next version btw. 

    Marc 

     

  • Tue, Nov 5 2013 13:09 In reply to

    • mnnoon
    • Top 10 Contributor
      Male
    • Joined on Wed, Apr 16 2008
    • Lawndale, CA
    • Posts 60

    Re: IComparer.Compare method error.

    I noticed in vs2010 orm dbimport  it changes the value type to decimal(38,38) by default from an import for ints, money, decimal.   Seems like if its a number it just makes this a default type.  Is there a way to make it use the exisitng type during a data import?

     Also text gets converted to nvarchar (2147483647).  I just convert it back.

    It seems like the primary keys kept their int keys but all the other ints were also converted to decimal(38,38).  Doesn't seem to be a big deal just different.  Seems like money fields are easy to change back and forth but time consuming if there are hundreds of tables that are different.

Page 1 of 1 (6 items)
© 2008-2024 ------- Terms of Service