Azure to local SQL 2012 error

• 
  Sorry for the inconvenience. Can you click on the "send error report" button and include your email address? This should give us some usable information about the error.

  Brian Donahue September 10, 2012 11:09

  - 0 +
• 
  did that about an hour before I posted here but I will do that again asap. the error details say: property_list_id. Hopefully more is being sent behind then scenes that isn't on the screen.
  
  Working with this same azure database in SQL Data Compare also produces the same result.
  
  Edit: support message successfully sent. I'd be happy to work with you in any way to try to resolve this error. Let me know.

  lightyeare September 10, 2012 11:21

  - 0 +
• 
  Can you try setting the SQL Compare project option "Ignore->Full-text indexing"? I think the text of the error message refers to a column name in the information schema that refers to a table containing fulltext indexes.

  Brian Donahue September 12, 2012 07:18

  - 0 +
• 
  Tried Ignoring:
  Full-text indexes
  Indexes
  The LOCK property of indexes
  Constraint and index names
  and then turned all the ignore options on.
  
  Still fails same error.

  lightyeare September 12, 2012 07:32

  - 0 +
• 
  It looks like the SQL Compare code is treating the Azure database as if it were regular 2012, which has the index property "property_list_id" on full-text indexes. The source code indicates that it should gather this information on 2012 and ignore it on Azure... possibly SQL Compare is not detecting Azure correctly. Will have to look into that.

  Brian Donahue September 12, 2012 10:35

  - 0 +
• 
  If you run this:
  select SERVERPROPERTY('EngineEdition')
  against the Azure database, SQL Compare expects it to be 5.

  Brian Donahue September 12, 2012 10:39

  - 0 +
• 
  select SERVERPROPERTY('EngineEdition') returns 5

  lightyeare September 12, 2012 10:41

  - 0 +
• 
  keep in mind the same error occurs for both SQL compare AND Sql Data compare

  lightyeare September 12, 2012 10:46

  - 0 +
• 
  Sure it would - they are both tied to the same schema reader code.

  Brian Donahue September 12, 2012 11:07

  - 0 +
• 
  which would have been obvious if I had taken 2 seconds to think about it. let me know if I can provide any other info.

  lightyeare September 12, 2012 11:16

  - 0 +
• 
  I'll let you know if I can think of anything...
  I just did a SQL Compare between AdventureWorks on SQL 2102 vs Azure and did not get this error though.

  Brian Donahue September 13, 2012 05:07

  - 0 +
• 
  yep, i am able to work just fine with one of our other azure dbs. also, i can work just fine with the azure db when i do the compare from our win2008 server. doesn't seem to work in my environment.

  lightyeare September 13, 2012 08:15

  - 0 +
• 
  If it's any help, it looks like the live database in your error report is using SQL Server 2008 compatibility mode. I tried that in my test, but it did not reproduce the error. However, it may explain why you have this problem with some databases and not others. The bug that your error report got filed with mentions that it's a problem with SQL 2000 backward-compatibility.

  Brian Donahue September 14, 2012 12:36

  - 0 +
• 
  i can work with the db fine using SQL Compare installed on our Window 2008 server.
  
  so this is specifically related to my windows8 environment?

  lightyeare September 14, 2012 12:44

  - 0 +
• 
  I'm afraid I can't comment as to whether or not Windows is at fault. All I can tell is tat this code path comes out if the database version is determined not to be Azure. But we already tested for that.

  Brian Donahue September 17, 2012 04:18

  - 0 +
• 
  I think I've found the problem - it seems to only happen on indexed views. That would explain why the error is so uncommon.

  Brian Donahue September 17, 2012 09:42

  - 0 +
• 
  Hello,
  
  This issue is fixed in trhe latest release of SQL Compare, 10.3.8.406, that you can get from Check for Updates.

  Brian Donahue May 17, 2013 04:51

  - 0 +
• 
  This is meant to be fixed in SQL Compare 10.7.

  Brian Donahue April 24, 2014 03:43

  - 0 +

Add comment

Please sign in to leave a comment.