Ex- and Import definitly broken!

[chaos234]

1. I hate premade templates so I'll not use them!

Well, it's no longer possible to import an exported database because your software parses the following chars false:

'bla' ... bla ... "bla"

So this means that you have to do the following:

Simply give a drobdown of compression is wished or not and a field to give the exported file an own name. After that the "OK" button can follow.

If "OK" is clicked the ssh/shell cmd "mysqldump $database > $save_file" is send to the server and there it is ... a correct export from the selected database.

Now if you want to import over pma you have to provide your login details and to use the cmd: "mysql -u $username -p $password $database < $save_file" (well, pw in the cmd line ar not rly secure but you should finde a way to solve this problem.

But the actually way is no longer useable because it tells me stupied and false erros like syntax ones which can't be if you had programmed your software correctly but actually it is horrible!

Ok, if this critical bug is not fixed I going to use the cmd line for all backups and imports.

[ibennetch]

Could you please tell us your PHP and MySQL versions?

[chaos234]

Server: Localhost via UNIX socket
Server-Typ: MySQL
Server-Version: 5.6.23-1~dotdeb.3 - (Debian)
Protokoll-Version: 10
Benutzer: root@localhost
Server-Zeichensatz: UTF-8 Unicode (utf8)

nginx/1.8.1
Datenbank-Client Version: libmysql - 5.6.23
PHP-Erweiterung: mysqli Dokumentation
PHP-Version: 5.6.17-0+deb8u1

Versionsinformationen: 4.5.5.1 (auf dem neuesten Stand)

[ibennetch]

Sorry I don't think we'll implement your idea of using mysqldump directly, among other concerns some hosts would block this functionality and there are some security concerns with implementing that.

[chaos234]

mysqldum should not be a high security risk because it can only dump full databases in a file which can then packed as Gzip/tar ... only the import is a point where security risks are high which must be approved/checked an then programmed well but actually I can't use both functions :(

[nijel]

The problem is about using exec(), which is usually blocked on hostings. It would be indeed much easier if we didn't have to reimplement what it does, but that's not way which would work for most of our users.

Anyway can you please describe what problem do you face? Our software does indeed have bugs, but are fixing them.

[nijel]

Also there were quite a lot of fixed in the SQL parser recently, so try if you can reproduce your problem in QA_4_6 branch or upcoming 4.6.0...

[chaos234]

Ok, I'll do it and report all errors in this ticket.

The problem was that the exportet database wasn't importet because the sql query was false but the query can't be false if your software works correctly so it must be a problem by parsing any sql file eyported by your software with my current pma version.

Am 21.03.2016 14:40:45 schrieb Michal Čihař notifications@github.com:
Also there were quite a lot of fixed in the SQL parser recently, so try if you can reproduce your problem in QA_4_6 branch or upcoming 4.6.0...
—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub [https://github.com//issues/12111#issuecomment-199283463]

[nijel]

What specific problem was in the query? Sorry I currently ran out of crystal balls to be able to diagnose "false query" issue.

I've recently fixed several such issues (eg. #12084, #12077, #12076, #12065, #12054) and in all cases it was quite easy to fix the wrongly produced SQL manually, so that the data could be restored.

[chaos234]

Fixing a DB with over 500 MB data is a bit to high ^^.

Am 21.03.2016 17:57:41 schrieb Michal Čihař notifications@github.com:
What specific problem was in the query? Sorry I currently ran out of crystal balls to be able to diagnose "false query" issue.
I've recently fixed several such issues (eg. #12084 [https://github.com//issues/12084], #12077 [https://github.com//issues/12077], #12076 [https://github.com//issues/12076], #12065 [https://github.com//issues/12065], #12054 [https://github.com//issues/12054]) and in all cases it was quite easy to fix the wrongly produced SQL manually, so that the data could be restored.
—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub [https://github.com//issues/12111#issuecomment-199377954]

[nijel]

What is most likely wrong is just CREATE TABLE clause, but again I'm just using my crystal ball.