Feature Request: Backup To Clipboard

[DAE51D]

I often find myself shoving in rows of fake table data while developing a new project. It is cumbersome to always have to load in a row using the editor or create a .sql file. What I would really like is a way to EXPORT (CTRL+ALT+C) to CLIPBOARD (you have SQL, CSV, HTML, XML, Excel already. This would be another checkbox that allows the output to go to the Copy/Paste clipboard buffer instead of a file.

Also add this checkbox feature to the “Backup Table as SQL dump” (CTRL+ALT+E) option.

Therefore, I can take some rows, 'export' them to the buffer, and immediately paste that back into the SQL window and modify as needed and execute it without having to save the file and re-load it (often times the file is something I don't ever want or need to use again since it's just bunk data)

In fact, maybe instead of just the clipboard, SQLyog would load the clip buffer AND automatically create a new Query Tab (CTRL+T) and paste this SQL into it, switching to it for me as well.

[Khushboo]

Hi,

Thank You for your valuable suggestion.

I have added your request “Add an option to “export to clipboard” in ExportAs… Dialog” in our issue tracker:

http://code.google.com/p/sqlyog/issues/detail?id=1375

This feature is marked with the label 'scheduled' which means that it will be discussed at next review meetings in the SQLyog team.

Regards,

Khushboo

[peterlaursen]

Isn't this a duplicate of this very old request:

http://code.google.com/p/sqlyog/issues/detail?id=99

Both of you please explain the difference (if any).

The problem with 'export to clipboard is in my understanding that there is no safe way to ensure that Windows will not truncate. Nobody knows in advance how big the clipboard is. It depends on what else is running. (but maybe I am wrong here?)

[DAE51D]

'peterlaursen' wrote on '09:

The problem with 'export to clipboard is in my understanding that there is no safe way to ensure that Windows will not truncate. Nobody knows in advance how big the clipboard is. It depends on what else is running. (but maybe I am wrong here?)

I wouldn't worry about the buffer size. I think in most (if not ALL use cases), we're talking about very small amounts of data — hence the reason it's irritating to have to export to a file, then load it back in, just to get a “quick” SQL dump.

As mentioned, I often need to just blast in a few records and once I have inserted one via the GUI, I want a quick and easy way of “duplicating” that record with some minor changes. Say I am creating a user table to test my new super amazing world changing social network, well then I need more than 1 user to test with, so I'll take user.id == 1 (me usually) and clone my “INSERT INTO users (id, name, gender) VALUES (1, 'daevid', 'm')” statement and tweak the second “(…)” part to make user (null, 'joe', 'm'), (null, 'bob', 'm'), (null, 'mary', 'f') etc… so I have some data to play with. Exporting a file for a schema or data for a single row is overkill.

But a quick Google search reveals this: http://www.techtalkz.com/windows-xp/423447-clipboard-limit.html

Quote:

The amount of data a that can be placed on the clipboard depends on the amount of free memory available. Programs running shares the available memory with the clipboard. Less programs running the more data that you can store on the clipboard. To see the contents of your clipboard: Start > Run > type clipbrd.

So your concern is moot. 🙄

[Author]

Posts