Feature Request: Allow Filter For Export As Csv, Etc.

[larsen]

Hello,

it would be handy if I could define a sql clause to limit the number of exported records.

Example:

Define filter as “where art = 2”

CSV-Export would then only export records with art = 2

Hope my explanation is good enough =)

Lars

[peterlaursen]

You explanation is good enough for me to understand!

But I think it is not the scope of SQLyog to define the SQL language!

We have no plan to add our own extensions the language like this.

[larsen]

peterlaursen wrote on Nov 17 2006, 07:22 AM:

But I think it is not the scope of SQLyog to define the SQL language!

We have no plan to add our own extensions the language like this.

Well, I think you got me wrong. I don´t want to change sql.

At the moment it is only possible to export whole tables as CSV data. But I just want to export records of a certain kind.

[Mike_123]

larsen wrote on Nov 17 2006, 02:20 AM:

Well, I think you got me wrong. I don´t want to change sql.

At the moment it is only possible to export whole tables as CSV data. But I just want to export records of a certain kind.

I agree. CSV export is something easy to add if you have the source code and can be done in a single procedure. You have access to the table definition so you know which fields require quoting.

Mike

[peterlaursen]

Quote:

At the moment it is only possible to export whole tables as CSV data

NO – not correct!

You can export from the RESULT tab as well. The query generating the result can have a WHERE-clause.

Please understand that (except for parsing for DELIMITERS (the “;” character and the “DELIMITER” string)), there is no parsing of the SQL language that are done in SQLyog. That is how database CLIENTS generally are: they interface to the functionalities of the SERVER. It is the server that parses, executes, converts character sets etc. etc. – not SQLyog.

You can save frequently used strings such as WHERE-clauses in 'favorites'

[larsen]

peterlaursen wrote on Nov 21 2006, 06:34 AM:

NO – not correct!

You can export from the RESULT tab as well.

Ooops, I guess I just missed that.

Quote:

there is no parsing of the SQL language that are done in SQLyog. That is how database CLIENTS generally

Please understand: I didn´t want SQLyog to parse the sql string. That string should just have been forwarded to the server. No parsing.

[peterlaursen]

I understand that you do not suggest tha SQLyog should parse for SQL-syntax itself. However if this (or similar)

Code:

Define filter as “where art = 2”
Select * from all_arts filter;

should be possible we would need to parse for our own language constructs. MySQL server does not understand this, so SQLyog would need to rewrite it before sending. That is possible in principle. We actually do something similar with the word DELIMITER (what is NOT a MySQL Keyword and the server does not understand the meaning of it. Support for that must be implemented in the client).

Another example is the SOURCE statement support by MySQL command line client. Actually this client parses for the occurence of this word as it is also not a SQL keyword/command and must be rewritten before sending to the server.

I think that with autocomplete and favorites we did a good part of the job. GUI query builder, 'smart filtering' from a cell context menu will be next step in this.

[larsen]

I thought of a textbox within CSV export where I would enter “where art = 2”. SQLyog just had to append this string to it´s query.

Anyway, as it is possible to export from result tab this feature is not needed 🙂

[Author]

Posts