New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Export does not stop if destination db does not exists #299

Closed
endo64 opened this Issue Jul 4, 2018 · 4 comments

Comments

Projects
None yet
3 participants
@endo64

endo64 commented Jul 4, 2018

Steps to reproduce this issue

  1. use table tools / SQL Export
  2. output a large schema to another server
    2.1. don't select Create database
    2.2. select "Same as on source server"
    2.3. be sure that the db doesn't exists on destination server
  3. start exporting

Current behavior

I get Unknown Database for each table for the source database.

Expected behavior

If Unknown Database error happens whole process should stop

Possible solution

Could be related to #285

Environment

  • HeidiSQL version:

Version 9.5.0.5278 (64 Bit)

  • Database system and version:

MySQL / MariaDB

@ansgarbecker ansgarbecker added this to the v9.6 milestone Oct 18, 2018

@ansgarbecker

This comment has been minimized.

Collaborator

ansgarbecker commented Oct 18, 2018

Confirmed. I get the repeated error for each table:

grafik

@ansgarbecker

This comment has been minimized.

Collaborator

ansgarbecker commented Nov 25, 2018

Especially for error code 1049, Heidi now cancels processing in the export dialog.

I wonder whether it makes sense to cancel on all errors during the export. For example on error code 1044 ("access denied for user x to database y"), it makes little sense only to proceed with remaining tables, does it?

@endo64

This comment has been minimized.

endo64 commented Nov 25, 2018

I agree better to cancel the operation on most errors, but may be not all. If possible, showing a popup to user, asking to continue (and a checkbox to continue on all errors in the current operation) would be the best solution.
Or we can choose "some" error to cancel and others continue.

@fifonik

This comment has been minimized.

fifonik commented Nov 25, 2018

Are you sure that you really want to stop it?
It might be commands later in the dump related to other database(s)...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment