MySQL Bugs: #32531: Reverse Engineering gets errors with triggers

Bug #32531	Reverse Engineering gets errors with triggers
Submitted:	20 Nov 2007 15:35	Modified:	18 Jan 2008 16:20
Reporter:	marc castrovinci (Basic Quality Contributor)	Email Updates:
Status:	No Feedback	Impact on me:	None
Category:	MySQL Workbench	Severity:	S2 (Serious)
Version:	5.09 SE BETA	OS:	Windows (XP SP2)
Assigned to:	Assigned Account	CPU Architecture:	Any
Tags:	finished, parsing, qc, reverse engineer, statement skipped, syntax error, triggers

Description:
After reverse engineering a full DB (tables, stored procedures and triggers) I receive the message "Execution completed successfully". But when I click advanced I see Multiple errors..

Line 4679: syntax error. Statement skipped.
Line 4718: syntax error. Statement skipped.
Line 4757: syntax error. Statement skipped.
Line 4798: syntax error. Statement skipped.
Line 4811: syntax error. Statement skipped.
Line 4824: syntax error. Statement skipped.
Line 4837: syntax error. Statement skipped.
Line 4850: syntax error. Statement skipped.
Line 4863: syntax error. Statement skipped.
Line 4876: syntax error. Statement skipped.
Line 4896: syntax error. Statement skipped.
Line 4909: syntax error. Statement skipped.
Line 4952: syntax error. Statement skipped.
Line 4973: syntax error. Statement skipped.
Line 4991: syntax error. Statement skipped.
Line 5004: syntax error. Statement skipped.
Line 5029: syntax error. Statement skipped.
Line 5042: syntax error. Statement skipped.
Line 5055: syntax error. Statement skipped.
Line 5069: syntax error. Statement skipped.
Line 5088: syntax error. Statement skipped.
Line 5122: syntax error. Statement skipped.
Line 5154: syntax error. Statement skipped.
Line 5189: syntax error. Statement skipped.
Line 5213: syntax error. Statement skipped.
Finished parsing SQL script. Totally processed statements: successful (130), errors (25), warnings (0).

After reviewing, the errors are all triggers.

How to repeat:
1. Go to Database> Reverse Engineer>
2. Reverse engineer tables and triggers.
3. Click next> to start the process.

You should see similar output to the above noted. The server is version 5.0.26.

Suggested fix:
Not sure. But I think we should be able to see the script file that the error is pointing to (e.g. Line 5088) so that I can figure out the problem.

Also, don't give a success message when there were errors.

I had put wrong version

Thanks for report & suggestions. Rev-eng really requires changes in its behavior.
Could you also provide original DDL statements for some of those triggers that were not parsed?

I added it in a private comment. Also, it seems that no triggers are getting created.

Thank you for the feedback. I wasn'

Sorry for the prior incomplete comment. I wasn't able to repeat against a
server 5.0.41. Below the log I got:

Reverse engineering started

Started parsing SQL script.
Created MySQL Schema: db9
Created MySQL Table: db9.tm_base
Created MySQL Table: db9.tm_client
Created MySQL Table: db9.tm_project
Created MySQL Trigger: db9.tm_base.trupd_tm_base
Created MySQL Trigger: db9.tm_client.trupd_tm_client
Created MySQL Trigger: db9.tm_project.trupd_tm_project
Finished parsing SQL script. Totally processed statements: successful (7), errors (0), warnings (0).

Notice that I needed to change your sample script using delimiter //
and changing the ; by // in the end of every trigger.

That was just me taking the ddl and trigger statements from my own files. This was occuring when I was doing a direct reverse engineer from the db I was connecting to.

There was a bug related to absence of quotation of definer in 'create trigger' statement. For compatibility reasons metadata is used to restore DDL statement for triggers, - not all 5.x DBMS versions support 'show create'. Now that bug is fixed, however I'm not sure if it was the case, since I failed to reproduce current bug even with provided original scripts.

Anyway reverse engineering was improved by several meanings to track down the problem:
1) Now it shows generated SQL script (dedicated page) before parsing it, so you can always find the source line number referenced by syntax error.
2) Now syntax error message also provide statement context when possible along with line number, the way similar to how DBMS does it.

All these changes will be accessible in forthcoming WB 5.0.11.

Please let us know if the problem is still there or close the bug otherwise.

No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".