SQL Compare 13.7 Crashes when Reading Columns

HeatheringtonSteve

SQL Compare 13.7 is crashing when I compare two databases. I have also submitted a support request. My database has synonyms, derived columns, but no temporal tables and is SQL 2016 SP1 Enterprise.

SQL Prompt and SQL Source Control continue to work fine for me. Both SQL Compare and Data Compare are useless on my primary databases because it fails on the following step (from verbose log):

13:39:08.282|Info   |SQL Compare Engine  |15 |Reading columns
13:39:08.291|Info   |SQL Compare Engine  |16 |Reading columns

The UI dissappears and the exe terminates in rather short order with no explanation or popup box.

HeatheringtonSteve

To anyone who is following this issue, I can say that SQLCompare 14.0.7.13517 does allow for me to compare two databases with large computed column definitions (140+ columns). There is a catch though, the time to compare such databases can be in the 10 to 15 minute timeframe.

Jessica R

Hi @HeatheringtonSteve!

It looks like you're already working on this through your support request with my colleague, Alex (Ticket #134925), so we can update here once we find the issue.

HeatheringtonSteve

It seems a particularly crafted computed column is the reason for the termination without error of SQL Compare. Alex has all the details and schema scripts to recreate the issue.

Alex B

Hi @HeatheringtonSteve,

I have reproduced the issue with your table and column definition and passed this on to the team as SC-10469 and I will update you via the ticket and here when I have more information from the team.

Kind regards,
Alex

HeatheringtonSteve

Thank you Alex. I look forward to the successful resolution of this ticket.

RomasK

Any resolution on this issue described above?

Alex B

Hi @RomasK,

The issue is still under investigation - in this case the issue is related to a very large column definition with many nested parentheses causing a stack overflow.

The current possible workaround to this is to try adding a system environment variable named <b>REDGATE_COMPARE_BIGSTACK</b> and set it to <b>64MB</b> - this will set the stack to the maximum possible size and may get things working. 

For the original issue with just the column itself this helped but when the remainder of the table and other objects were included it still crashed out unfortunately.

Hopefully the workaround will help in your case, but otherwise we'll need to await further progress on SC-10469.

Kind regards,
Alex

SteveC

Hello,

We are also having this same issue where version 13 is crashing on Compare and probably is due to nested parantheses.  I followed the advice from Alex B and was able to get the compare to work normally.  Just wanted to add in my results if anyone else is having this issue like we are.

Thanks,

SteveC

HeatheringtonSteve

Alex, the workaround only helps with the smaller tables. Wide tables used in reporting (75+ columns) continue to break SQL compare. I know that it will take the resolution of SC-10469 to use SQL compare to it's fullest for our implementation. As of SQL Compare 13.7.17.11774, the problem remains.

Alex B

Hi all,

The team are working on several things related to this currently, but some of it is related to detecting whether it's going to overflow and preventing SQL Compare from crashing and it may still not be able to handle some situations.

When any of the work is available I'll let you all know!

Kind regards,
Alex

SBrooks

Hi All,
Wondering if there was any resolution to this issue?  I'm using Data Compare 14.2.16.16006 and this issue still persists.  I urgently need to compare between a backup and live source to recover some changes to a table in a very large db (backup size in excess of 1.5TB)
Thanks.