MySQL Bugs: #33904: add log file, report reason for failure

Bug #33904	add log file, report reason for failure
Submitted:	17 Jan 2008 18:34	Modified:	18 Feb 2008 20:21
Reporter:	William Surowiec	Email Updates:
Status:	No Feedback	Impact on me:	None
Category:	MySQL Workbench	Severity:	S4 (Feature request)
Version:	5.0.12 beta	OS:	Any
Assigned to:	Assigned Account	CPU Architecture:	Any
Tags:	reverse engineering

Description:
Every time I try to reverse engineer a clients' database (either from the sql script generating the db or the db itself) the application reports an error has occurred and closes.

I suggest a log file be added and used to record whatever meaningful details could be reported back to you.

Unfortunately the db script - wordy but not rocket science - is proprietary (client, not I.)

How to repeat:
While i do not believe the problem is unique to the clients' database, I cannot offer suggestions on how to reproduce the error. However, my suggestion is how you can make the failure more transparent.

As I understood error happens on stage of parsing. Your help is needed to track down and narrow the problem, because given info is not enough to reproduce the bug. Could you split your script by two equal parts consequently in loop (leaving problematic part for further iterations) until only one problematic statement left. Then to preserve privacy of your client, you can change names present in the statement to obscure purpose of the structure, generally you may remove from it everything unrelated to the problem. Also note there is a flag making comment, that you are adding, private, that is accessible only for MySQL. Also point version of your DBMS please.

I hope I do not sound unappreciative. The client's db is built in several files. The first (the one I tried to import) is over 3800 lines long. It creates approximately 110 tables. The statements for one table are spread out - basically all table create, then all primary key, then all foreign key, etc. Your suggestion wourld require a lot of work - from me and anyone with a similar problem.

I do realize no one can fix a problem with the information I was able to provide. That is why I made a feature request - add error messages, log what the application is doing. In short, add features that make it easy for me - and anyone else - to find the offending statement. Then I - or others - could provide the information needed to debug problems.

WB already has log messages panel. You may open log panel beforehand through menu "View->Advanced->Output Window". Messages should start to appear (one per each parsed object) once you've started "Import->Reverse Engineer from MySQL script". Even if plugin crashes, log is expected to contain message corresponding to last processed statement. That is most probably problem is with nearest consequent statement.

Aha, enlightenment - thank you Sergei. We have an expression - RTFM- it means "read the fine manual," or something like that :-) (please do _not_ suggest RTFM to a user - allow the better ones to realize that on their own, the others would not appreciate the suggestion.)

Anyway, right after the program starts, that panel indicates a problem:

Looking for user plugins in C:\Documents and Settings\user1\Application Data\MySQL\Workbench\modules
Registered 16 modules (from 14 files).
Error scanning for modules: Invalid path (10001)
Using software rendering.

Reverse engineering from a script did not add to the output in the above panel. But I can now tell (not sure if it is because I am now looking or because a panel became available when I followed your directions) that it was 2 statements away from the end of the script. It was now working on (I believe) the first of the Triggers.

I will try reverse engineering from the database and report back.

Bill

Reverse engineer from a database:

1) connects, finds all of the db in the catalog, I select the one of interest, it is able to get it (103 tables, 1 stored proc, 2 triggers)

I put nothing on the ignore list, hit next, it asks me to review the ddl script it has generated (too big, I really do not, but i do note it is in a different order than the manually created one.)

I believe I hit next, I could see it was processing - got maybe 2/3 done when another dialog box popped up - it had dies and told me so. Unfortunately, while i could see a message in the output panel had been changed - the 2 dialog boxes obscured the message - and when the dialog boxes were cleared away - so was the message.

Is there an option to log what is being generated on the screen - and please do _not_ suggest RTFM :-)

Bill

WB changed to accept "-log" command line parameter, meaning it will store some info (depending on module) to "MySQL Workbench/wb.log" file placed in windows user temp directory. Rev-eng module changed to duplicate all messages to log file when mentioned cl parameter is set. Write buffer is disabled, every message is flushed synchronously. Changes will become effective in v5.0.13.
Let us know about results. If it helps you to spot problematic statement, please provide more details on it then.

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".