gda-sql(1) | LIBGDA Manual Pages | gda-sql(1) |
gda-sql - an SQL console based on Libgda
gda-sql [--help] [-v] [--version] [-o] [--output-file <filename>] [-C] [--command] [-f] [--commands-file <filename>] [-i] [--interactive] [-l] [--list-dsn] [-L] [--list-providers] [-s] [--http-port <port>] [-t] [--http-token <token phrase>] [--data-files-list] [--data-files-purge <criteria>] [connection's spec] [connection's spec...]
gda-sql is an SQL console based on the Libgda library.
It enables you to type in queries interactively, issue them to be executed by a connection, and see the query results.
Several connections can be opened at the same time, allowing you to switch the active connection to any opened connection. When starting, gda-sql opens a connection for each connection specified on the command line (plus optionally one corresponding to the GDA_SQL_CNC environment variable). The prompt indicates the current connection used when executing commands. See the .c internal command for an explanation about the syntax to specify a connection on the command line.
Alternatively, input can be from a file. In addition, it provides a number of meta-commands and various shell-like features to facilitate writing scripts and automating a wide variety of tasks.
It is also possible to run the tool as a script using the classic '#!' string at the start of a script file, with the limitation that behaviour of arguments passed on the line after the '#!' command is undefined. Example:
#!/bin/path/to/gda-sql
#!/usr/bin/env gda-sql
gda-sql accepts the following options:
"non-dsn": remove all the files which do not correspond to a DSN (data source name). These are the files created when a connection is specified using connection parameters instead of using a DSN
"non-exist-dsn": same as "non-dsn" except it also removes the files which were for DSN which don't exist anymore
"all": remove all the files, for a complete cleanup
For example: --data-files-purge all,list-only lists all the files (which would be removed if the command was --data-files-purge all).
gda-sql can be configured through some environment variables:
gda-sql stores data source definitions (DSN) in Libgda defined files ($HOME/.local/share/libgda and /etc/libgda-5.0/config where ${prefix} is typically /usr).
For each connection defined by a DSN, all the information regarding the connection (such as the meta data) is stored in a $HOME/.local/share/libgda/gda-sql-<DSN>.db file.
You can run any SQL understood by the database engine of the current connection. Additionally SQL statement can contain variables expressed as ##<name>::<type> where <name> is the variable's name and <type> is its declared type (which can be "int", "string", "boolean", "time", "date", "timestamp" (and other types defined by GLib's syntax).
Use the .set internal command to set variable's values.
In addition to SQL commands, gda-sql supports internal commands which differ from SQL commands because they start with the "." or "\" character. These commands are:
.c <CNC_NAME> <DSN_NAME> opens a connection internally known as <CNC_NAME>, using the specified DSN.
.c <CNC_NAME> <CNC_DEFINITION> opens a connection internally known as <CNC_NAME>, using a connection specified by <CNC_DEFINITION> which is similar to the <DSN_DEFINITION> parameter of the .lc command.
.c <CNC_NAME> sets the current connection to the connection known as <CNC_NAME>.
.c ~ or .c ~<CNC_NAME> set the current connection to the meta data corresponding to the current connection (for the first notation) or to the meta data corresponding to the <CNC_NAME> connection.
.export <NAME> <FILE_NAME> exports the contents of the <NAME> parameter to the specified file.
.export <TABLE> <COLUMN> <ROW_CONDITION> <FILE_NAME> exports the value of the <TABLE> table, column <COLUMN> for the row selected by <ROW_CONDITION> to the specified file. This is most useful to export BLOBs.
The generated graph is created as the "gdaph.dot" file. If the GDA_SQL_VIEWER_PNG or GDA_SQL_VIEWER_PDF environment variables are set and if the "dot" program (from GraphViz) is found, then the graph is displayed (if a display is available).
If a DSN with a similar name already exists, it is first removed.
For example: ".lc mydsn PostgreSQL://HOST=moon;DB_NAME=mydb".
For multi valued attributes (such as "objectClass"), it is possible to specify how multiple values are handled by appending ::csv (values are listed in a CVS syntax), ::* (each row is duplicated with each value of the attribute), ::1 (only the 1st value of the attribute is shown), ::concat (all the values are made into a string, separated by newlines) or ::null (a NULL value is used). The default is an error value.
If the set option is passed, then all the set attributes are shown, if the all option is passed, then all attributes are shown, and if the unset option is passed, then only attributes which don't have a value are shown. The default is to show only the set attributes specified by the ldap_attributes option.
The .<OPERATION> argument specifies which operation must be performed, among DELETE, REPLACE and ADD.
Filter must be a valid LDAP filter expression (outer most parenthesis are optional though), "base", "onelevel" or "subtree" can optionally specify the search scope (default is subtree), and .<base DN> can be used to specify a different DN to search from (the default is to use the base DN specified when opening the connection).
If no option name is given, then all the available options and their current values are shown. If an option name is given without any value, its current value is shown, and to define the value of an option, give its name and new value.
The <SELECT> defines the data set to perform summarization on.
The <ROW_FIELDS> defines the fields from the data set from which each individual value will yield to a row in the analysis (it can be any valid selectable SQL expression on the data set's fields); multiple expressions can be provided, separated by commas (forming a valid SQL expression). In this case a row will be created for each combination of values of each of the expression.
The <COLUMN_FIELDS> defines the fields from the data set from which each individual value will yield to a column in the analysis. Its syntax is similar to the <ROW_FIELDS> one. If not specified (or if specified as a single dash ("-") caracter), then only one column will be created. Note that, if the <DATA_FIELDS> argument is specified each column created from the <COLUMN_FIELDS> will in fact lead to the creation of as many <DATA_FIELDS> arguments provided.
The <DATA_FIELDS> arguments are entirely optional and indicates the way data summarization is done for each pair of (row,column) values (the default is to count occurrences). The syntax for each <DATA_FIELDS> argument is: [aggregate]<SQL_expression>, where the aggregate part is optional and, if present must be among [SUM], [COUNT], [AVG], [MIN] or [MAX], and the SQL expression is a valid selectable SQL expression of the data set's fields.
Examples:
.pivot "SELECT * FROM food" person food
.pivot "SELECT * FROM products" category "CASE WHEN price < 15 THEN 'low' ELSE 'high' END" [AVG]price
.pivot "SELECT * FROM sales" category,product - [AVG]quantity
.set lists all the defined internal parameters.
.set <NAME> <VALUE> (re)defines the internal parameter named <NAME> to the specified value (which can be the _null_ literal to set it to NULL).
.set <NAME> shows the contents of the internal parameter named <NAME>.
.setex <NAME> <FILE_NAME> (re)defines the the internal parameter named <NAME> with the contents of the specified file name.
.setex <NAME> <TABLE> <COLUMN> <ROW_CONDITION> (re)defines the the internal parameter named <NAME> with the value of the <TABLE> table, column <COLUMN> for the row selected by <ROW_CONDITION>.This is most useful to export BLOBs.
.unset unsets all the internal parameters.
.unset <NAME> unsets the internal parameter named <NAME>.
Any bugs found should be reported to the online bug-tracking system available on the web at http://bugzilla.gnome.org/. Before reporting bugs, please check to see if the bug has already been reported.
When reporting bugs, it is important to include a reliable way to reproduce the bug, version number of gda-sql, OS name and version, and any relevant hardware specs. If a bug is causing a crash, it is very useful if a stack trace can be provided. And of course, patches to rectify the bug are even better.
Consult the Libgda's home page at http://www.gnome-db.org/.
Vivien Malerba (for Libgda's authors, please consult the AUTORS file within the Libgda's sources)
Version 5.2.10 |