MySQL Bugs: #51261: Import doesn't import anything

Bug #51261	Import doesn't import anything
Submitted:	18 Feb 2010 0:52	Modified:	22 Mar 2010 15:24
Reporter:	Barry Galbraith	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Workbench: Administration	Severity:	S3 (Non-critical)
Version:	5.2.16 Beta	OS:	Windows (XP Pro SP3)
Assigned to:	Alexander Musienko	CPU Architecture:	Any
Tags:	Import from disk

Description:
Import from disk doesn't import anything.
mysql client is never called from WB.

How to repeat:
Create a test db.
Create multiple tables in test db.
Export db to dump folder.
Drop tables.
Import from disk to restore all tables.
NO TABLES ARE RESTORED!
The Statistics shows blank.
The log shows one file attempted.

Suggested fix:
Fix import from disk function.
The import file is now quoted to account for spaces in the path, but mysql is not called.

Importing

Attachment: imported.png (image/png, text), 92.30 KiB.

Thank you for the bug report. I was able to import from disk see prior attached picture. Thanks in advance.

I still can't import anything, even if I dump/import to c:\temp as in your example.

mysql.exe is never called.
The statistics field remains blank.
The status shows Starting

But nothing is imported.

I've tried 2 different machines, and both (mis)behave the same.

mysqldump.exe is invoked to export OK, but mysql.exe is never called to import.

Same problem here: does not work on an XP (pro sp3) machine, but does work on a Vista machine. Same for versions 5.2.14 and 5.2.16 which I did install today.

I watched it with process monitor (from sysinternals) and noticed some differences (will post the log as an excel file):

Vista machine: 
- temp file created (length 27, containing the password to log on to the database)
- cmd.exe executed with the command line "mysql.exe --defaults-extra-file=... ..."
- mysql started by cmd.exe
- temp file deleted

XP machine:
- temp file created (length 27, containing the password to log on to the database)
- temp file deleted

Thus on an XP machine the cmd.exe does not get called at all, let alone the mysql.exe command.

Hope this helps to discover what is going on,
Best regards,

Erwin Derksen

process monitor log (yellow lines denote executing the import)

Attachment: Logfile.xlsx (application/vnd.openxmlformats-officedocument.spreadsheetml.sheet, text), 199.72 KiB.

imp fails with no errors

Attachment: ImpFails but no errors.pdf (application/pdf, text), 213.32 KiB.

I am quite certain that mysql is simply not in the path. 
devs - don't assume it will be in the path and there are cases where it shouldn't be in the path.
we have the path use it. 
check for mysql.exe 

error back if not found with proper error message.  "Can't find mysql.exe in path "\sdsdf\sdfsdf\sdf\" Import requires mysql.  please check the path the mysql by looking in Manager MySQL instance

postfix the path before mysql call for the import.
also you should be reading the $ERROR from the call and picking up stderr not just stdout

mysql is in the path on my machine(s).
But it doesn't need to be.
Edit | Preferences | Administrator
Set the path to mysql.exe or leave blank to use bundled version.

I have tried setting to path to my mysl installed version 'c:\program files\mysql\mysql Server 5.0\bin', and I have tried it blank.
Neither works.

Please attach the content of the Import logs (as a text file, I cant open xslx files, whatever it is).

Log file from process monitor for wroking Vista machine

Attachment: Logfile process monitor Vista.csv (application/vnd.ms-excel, text), 346.75 KiB.

Log file from process monitor on not working XP machine

Attachment: Logfile process monitor XP.csv (application/vnd.ms-excel, text), 276.42 KiB.

Process monitor is a tool (rom sysinternals) that monitors all thread, process, registry and file system actions from a process. In this case, it allows you to see that on the XP machine the cmd.exe never gets called  to execute mysql.exe.

It contains a lot of lines that apparently have nothing to do with the import action. I think that in the vista log the lines 6 - 1945 are related to the import, and in the XP log the lines 878 - 930.

Hope this helps,

Actually i am now playing a bit with the python script modules/wb_admin_export.py to see if I can add some testing logging

Erwin

This seems unrelated to the path of mysql.exe but it can be repeated and in XP only.

Adding these lines to:
class DumpThread
  def process_db
    try
        ...
        p1 = subprocess.Popen(logstr,stdout=respipe,stdin=subprocess.PIPE, stderr=subprocess.PIPE, shell=True)
        ...
    except Exception, exc:
        import traceback
        traceback.print_exc()
        Utilities.show_error("Error executing command", str(exc), "OK", "", "")

I got the following nice message: invalid handle
The exception is thrown on the given line (thus the subprocess.Popen call.

This means that, whatever the realcause, the error handling can/needs to be improved in this part of the source to get better error messages and logging

Anything I can do next? (note that:
- I have limited knowledge of Python
- Can I save the traceback? Passing a file name did not work, I probably have to pass in a file object? How to do so?
)

Hope this helps,

Erwin

Error message box

Attachment: error message.bmp (image/bmp, text), 176.66 KiB.

Debugging deeper down into the code I come to the following "stack trace":

class Popen(object):
    def __init__
        ...
        (p2cread, p2cwrite,
         c2pread, c2pwrite,
         errread, errwrite) = self._get_handles(stdin, stdout, stderr)

    if mswindows:
        #
        # Windows methods
        #
        def _get_handles(self, stdin, stdout, stderr):
            ...
            if stdout is None:
                c2pwrite = GetStdHandle(STD_OUTPUT_HANDLE)
            ...
            c2pwrite = self._make_inheritable(c2pwrite)

        def _make_inheritable(self, handle):
            """Return a duplicate of handle, which is inheritable"""
            return DuplicateHandle(GetCurrentProcess(), handle,
                                   GetCurrentProcess(), 0, 1,
                                   DUPLICATE_SAME_ACCESS

Other calls to _make_inheritable printed for str(handle) something like <subprocess_handle object at 0x...>. But this call, the failing one, printed <65537> for str{handle)

Thus it looks like that the STD_OUTPUT_HANDLE cannot be duplicated on XP (SP3)?????? or that GetStdHandle(STD_OUTPUT_HANDLE) returns a bogus handle????

I managed to get it working locally. If you're eagerly awaiting a solution do this:

file: modules/wb_admin_export.py
line: 1218 (class DumpThread, method process_db)

is (without indentation):
p1 = subprocess.Popen(logstr,stdout=respipe,stdin=subprocess.PIPE, stderr=subprocess.PIPE, shell=True)

change it into (but don't change the indentation of the line):
p1 = subprocess.Popen(logstr,stdout=subprocess.PIPE,stdin=subprocess.PIPE, stderr=subprocess.PIPE, shell=True)

Remove the wb_admin_export.pyc file (in the same directory) and start the MySql workbench, this will compile the (changed) .py to the .pyc.

This is not a thoroughly tested patch, nor do I know if the change is logical. Moreover, the code still lacks good error handling, thus use this only if you need to go on.

Erwin,

Your fix had no effect for me :(
Still no import.

Erwin,

Your fix had no effect for me :(
Still no import.

I'm sorry to hear that the (quick and dirty) fix does not work on your computer. Unfortunately I'm not the developer of this piece of software, so I'm afraid I'm cannot help you further at this moment other than some tips you can try yourself.

Debugging python code:
I'm sure there are more sophisticated ways of doing so, but I'm not a Python developer and do not know of these tools. So I debugged it by adding print statements and try - except statements.

The code that is giving the problem can be found in the file modules/wb_admin_export.py. This file has a compiled version  with the same name but extension .pyc. Whenever you make a change to the .py file, remove the .pyc file and restart the MySQL workbench. It will recompile the .py file upon not finding the .pyc file.

Start with putting a try except around the statement that (probably) causes the problem. In my case it is in the class DumpThread, starting on line 1167 and method def process_db. There is already a try - finally, so add the lines

except Exception, exc:
        import traceback
        errmsg = traceback.print_exception()
        Utilities.show_error("Error executing command", errmsg, "OK", "", "")

just before the finally line. This should give you a stack trace that may help you further in determining the problem and finding a workaround. Note that I have not tested these statements. Originally I used print_exc, but that did not work. The documentation says that print_exception returns a string containing the message and a stack trace.

I will add the .pyc that works for me as an attachment.

Hope this helps,
Erwin

original and changed py and pyc files

Attachment: wb_admin_export.zip (application/zip, text), 52.94 KiB.

fixed in repository

Added an entry to the 5.2.17 changelog:

After exporting a schema to disk, importing the schema did not restore the tables.