MySQL Bugs: #93143: Crash during migration

Bug #93143	Crash during migration
Submitted:	9 Nov 2018 14:59	Modified:	12 Nov 2018 11:56
Reporter:	Timothee BARON	Email Updates:
Status:	Can't repeat	Impact on me:	None
Category:	MySQL Workbench: Migration	Severity:	S2 (Serious)
Version:	8.0.13	OS:	Windows (Windows 10)
Assigned to:		CPU Architecture:	x86 (64 bit)

Description:
During migration from SQL Server 2008 database to MySQL, the application crashes and close itself directly.

In the logs I can see this:
16:24:32 [INF][            grt]: Object DM_xxxxxxx_GROUPS was renamed to dbo_DM_xxxxxxxx_GROUPS	
16:24:32 [INF][            grt]: Object DM_xxxxxxxEVENTS_CODES was renamed to dbo_DM_xxxxxxxEVENTS_CODES	
16:25:53 [INF][         Wizard]: Starting thread for 'Migrate Selected Objects'
16:31:21 [INF][         Wizard]: Starting thread for 'Generate SQL CREATE Statements'

I can see also in eventlog, that .NET Framework crashed with exception code c0000005.

I can't find on the Internet any solution.

Thank in advance for your help.

How to repeat:
I can't provide the data set to reproduce but it crashed every time.

Suggested fix:
I have no idea.

Thank you for the bug report. We need a test case to verify this bu report, isn't necessary your private data set but we  would appreciate if you provide a create table, insert data script for MS SQL Server which possibility to reproduce the issue. Thanks in advance.

Thank you for the feedback.

Please let me explain the context. We have migrated a database on the same  machine from the same MS SQL Server with success. The successful migration was with a database was much smaller than the one we try to migrated and which is 14GB compressed.

I understand you need something to reproduce the bug but I would need to provide with a similar database. There are more than thousand of objects and views to be migrated. I am not a DBA professional but I don't how I can provide with "a create table, insert data script". Please could you provide some clues to do it?

Thank you in advance.

On before migration reporter, the user was able to identify i.e. the table were was occurred the issue and then isolated it an new created database and provided it to be attached and test on our side. Generally the issue was a large field varchar.