Don't want extended inserts on export

Just wondering why EXTENDED INSERTS OPTION ALWAYS ON.

See this screenshot http://www.mechanictoolsonline.com/HeidiSQL_Extended.png

Is there a way to NOT get extended inserts?

For two reasons:
- there may be a use case in which one would not want extended INSERTS but they seem very rare to me
- usability/simplicity: I'm not overcrowding the dialog with rarely used controls

Rare to you, maybe, but have you polled your users?

In the case if importing large export files using phpMyAdmin, there is NONE.

Then use of a utility called BigDump is preferable and it required your export to NOT have extended inserts.

That is the reason for the request.

Rare to you, maybe, but have you polled your users?

Well, you are the first to ask for that, so I think my guess is right that it's a rare case. Just look into the issue tracker, you won't find any request for this thing, while others have 10 or 20 stars.

In the case if importing large export files using phpMyAdmin, there is NONE.

pma is surely able to import extended INSERTs, where's the problem?

Then use of a utility called BigDump is preferable and it required your export to NOT have extended inserts.

Then, what about posting a feature request to the BigDump developer(s)?

I also have my own needs and opened a bug earlier this year, which was disregarded as duplicate. Feel free to comment on the latter.

I think that the main problem is that SQL dumps accept an infinite number of tweaks and options. If all of them get implemented, we'll end up with a GUI clone of mysqldump. Run mysqldump --help and you'll understand what I mean.

The only chance of getting new changes done on this area is coming with a really good idea that allows to keep it simple. My humble suggestion was the ability to define profiles, but I admit I didn't find the time to elaborate on it.

pma is surely able to import extended INSERTs, where's the problem?

The problem lies in the fact that pma chokes when trying to import a 300MB file!!

More and more databases are growing to that size and I'm sure you will have more requests for it. What does having 10 or 20 stars have to do with this, is that the only enhancements you work on? Seems to me that the enhancements that MAKE MORE sense are the ones you work on, not just the ones with the stars.

Then, what about posting a feature request to the BigDump developer(s)?

Because of the way it works, it is not possible for it to be modified in that manner.

What is the BIG DEAL about having an option to not have extended inserts? You add one option to the mysqldump call and that's it.

I agree with kalvaro that using this to export files for versioning is a good enhancement. I wrote a utility to do this for MSSQL using Delphi. It imported our DB, using single inserts into VSS.

- usability/simplicity: I'm not overcrowding the dialog with rarely used controls

Are you nuts? Adding another option to the combobox is not overcrowding the GUI. Geez...seems to me you are just lazy! If you don't want to do it, just release the source and I'll add it.

Better yet, I'll just use mysqldump to do all my exporting and drop HeidiSQL altogether and find another mySQL GUI.

The problem lies in the fact that pma chokes when trying to import a 300MB file

... which has nothing to do with the style of extended/simple INSERTs, has it?

... is that the only enhancements you work on?

No, but I prefer having much feedback on things on which I am undecided about or even disagree.

What is the BIG DEAL about having an option to not have extended inserts?

It's a big deal in that way that it adds more code complexity to a critical part where users do not accept any bug. Have a look at tabletools.pas -> DoExport() and you'll know what I mean.

Are you nuts? Adding another option to the combobox is not overcrowding the GUI. Geez...seems to me you are just lazy! If you don't want to do it, just release the source and I'll add it.

Man, calm down please. I'm developing on HeidiSQL in my spare time, when wife and kids have gone to bed. And I'm everything but lazy on it - I have put 1000s of hours into it. Reading such stuff is demotivating.

Additionally, HeidiSQL is OpenSource, so feel free to modify and compile it yourself.

Then, the new option would not be something mutually exclusive to the other combobox options, so that would need a new checkbox or whatever.

Geez...seems to me you are just lazy! If you don't want to do it, just release the source and I'll add it.

Come on, relax. You'd never talk like that to a coder you're actually paying; what do you expect to get from an open source project contributor?

You can find the source code in the Downloads section. It's always been there!

I don't know if this is enough of a reason to justify "non-extended inserts" but for me, I need to move a database from a MySQL server to Microsoft SQL Server. Unfortunately, as far as I can tell (and I'd be happy to be shown that I'm wrong) MSSQLServer doesn't know about extended inserts. There are other things I'll need to modify so I'll need to massage the SQL to get it to import correctly anyway but this would save me a lot of work.

Aren't there more appropriate tools for migrating data between different database systems? HeidiSQL does pure MySQL stuff currently.

SQL dialects normally differ in more than that. Doesn't SQL Server provide tools to import data from other DBMS? You just need that they can talk ODBC.

Hi, I've just found this thread as I'd very much appreciate the option to turn off extended imports because often imports fail due to a single row with a dodgy contents (I maintain db's that contain alot of escaped HTML code for a CMS) and one bad egg spoils the whole import.

Oh and because this is my first post I'd like to thank you very much for the software - I've just started to use it to get away from phpmyadmin.

I have intentionally left out some features in the export dialog which I consider as cosmetic or unimportant - such as "Single INSERTs". So the database beginners can use HeidiSQL without being afraid of what they're doing and if they clicked the right or wrong checkbox.

As I pointed out earlier, "cosmetic or unimportant " is YOUR opinion, not that of your users. You still haven't polled your users to find out if this feature would be helpful, have you?
I know I've encountered it many times and I'm an advanced user.

In this thread, there are 3 reasons to have the option and only ONE against it, your reluctance to listen.

kalvaro:

If all of them get implemented, we'll end up with a GUI clone of mysqldump.

Well, isn't that what HeidiSQL aims to be anyway?
Also

You'd never talk like that to a coder you're actually paying

You bet, if I didn't get what I wanted, hell, yes, I'd speak to them that way. I'm a developer, myself, so I listen to my users and implement the features that THEY ask for, not the ones that I want to add.

@anse - I understand I am simply pointing out that I do find the feature important (I hope politely in contrast to...) but if there are no plans - I will find a different route

> Well, isn't that what HeidiSQL aims to be anyway?

No, HeidiSQL is not some clone of any other software. And no, I'll not just implement everything users ask for, as there are tons of nonsense requests (not this one, this is not nonsense, it's just a bit cosmetic to me).

HeidiSQL is not some clone of any other software

Not exactly, it is very similar to the old SQL Server Management Studio.

Now, explain to me how actual useful functionality can be cosmetic. Seems like you are not as professional a developer as you let out to be.

I worked for a company recently that put out a statement to their developers that no new features would be added without customers paying for the development of added features outright. They have been left behind by their competitors because several crucial features to their software have never been added and the product is now only in maintenance mode and no new licenses are being sold.

Sounds like the same predicament here, only you don't sell your software. Your competitors will leave you in the dust and your product will go the way of it's predecessor.

This is actual useful functionality that, at least in this thread, several people have asked for and shown the benefits of it's implementation.

If you have no intentions of adding this feature, then I'll write it in myself.

Oh, and another thing, while I'm on a rant, here. Why is this product NOT multi-threaded? If I run a lengthy query, I should be able to do other things not have the application freeze up and have to kill the process if things take too long.

Hehe, good attempt, but I'm surely not blocking just all requests, only those which sound unimportant and which do not have enough user requests. If you don't believe me, please look at the issue tracker. Multithreading is the most wanted feature there, please look at issue #1509.

MrBaseball, please realize you are talking to real people, not to some stereoptype of developer.

One more reason why I don't like single inserts can be found in issue #2272 - the overhead of single queries when importing them can be such a pain in the ass so one user wrote a request how to speed that up. And for what reason should we support creating slow exports when we do it the fast way?

And to come back to some practical argumentation:
> often imports fail due to a single row with a dodgy contents
Could you be more detailed what you mean by dodgy contents, so we can probably fix that dodgyness in HeidiSQL? Doing single INSERTs would be only some half solution, as they would just make it a bit easier to remove the erroneous portion.

Sorry for such a late reply - I will try and get you some examples - but it is not an easy task the files with the problems are very large and I'll need to log the import instead of watchign the window fly past with errors

Dear all

I have been watching this thread for a while now. I am very displeased by the strange arguments used to convince Anse.

Please note the following:
1. HeidsSQL is a great program to facilitate normal use.
2. Anything but extended inserts tends to be dreadfully slow
3. If extended inserts do not work for, consider that there is something wrong with the data or the structure of your database or both. The fact that it doesn't work should serve as a big WARNING.
4. You are always free to use MySQLdump for special cases. It does work for remote servers!! So does MySQL to get your data back in!!
5. If you have direct access to the server you can also do "select * into outfile yourfile" and "load data infile yourfile".

This information should be common knowledge to all people using MySQL and MariaDB databases.

I request you to please be more considerate and supportive towards Anse

Olaf

1. HeidsSQL is a great program to facilitate normal use.

Haven't seen anything claiming otherwise here.

2. Anything but extended inserts tends to be dreadfully slow

As with most slow things - it is safer and less error prone. This is exactly the case for me... using the extended inserts mean 70% of data improts as apposed to ~99% without them

3. If extended inserts do not work for, consider that there is something wrong with the data or the structure of your database or both. The fact that it doesn't work should serve as a big WARNING.

yes it's a WARNING - and I am not asking for help with this. Just so you know *my* database is managed via a great ORM/MVC piece of software called silverstripe (the only web app cms endorsed by microsoft) and the data for a large part is storing page data that user of the CMS maintain. So *my* data and *my* datbase is entrily created and managed by someone else - ain't life grand!

4. You are always free to use MySQLdump for special cases. It does work for remote servers!! So does MySQL to get your data back in!!

ok!! ok!!

5. If you have direct access to the server you can also do "select * into outfile yourfile" and "load data infile yourfile".

Olaf there are a lot of options, I've politly requested this feature and it's low priority to me because I am working around it - I have replied here mainly becasue I think you should be more considerate to my point of view :)

You it's the strangest thing - if I use the msyl command line with source <file> I get errors, but if I use HeidsSQL it seems to batch up the commands and it works - i think - so I guess I can live without this... :)

*correct that was supposed to start "You know,"