I've been using Emacs's sql interactive mode to talk to the MySQL db server and gotten to enjoy it. A developer has set up another db on a new non-default port number but I don't know how to access it using sql-mysql.
How do I specify a port number when I'm trying to connect to a database?
It would be even better if Emacs can prompt me for a port number and just use the default if I don't specify. Any chances of that?
After digging through the sql.el file, I found a variable that allows me to specify a port when I try to create a connection.
This option was added GNU Emacs 24.1.
sql-mysql-login-params
List of login parameters needed to connect to MySQL.
I added this to my Emacs init file:
(setq sql-mysql-login-params (append sql-mysql-login-params '(port)))
The default port is 0. If you'd like to set that to the default MySQL port you can customize sql-port
(setq sql-port 3306) ;; default MySQL port
There is a sql-*-login-params variable for all the popular RDMS systems in GNU Emacs 24.1. sql-port is used for both MySQL and PostreSQL
(setq sql-mysql-options (list "-P <port number>"))
I found the option using:
M-x customize-group
SQL
That included a setting labeled:
Mysql Options:
If you set the option and save it, there will be a new line added to your .emacs:
(custom-set-variables
'(sql-mysql-options (quote ("-P ???"))))
(Obviously, you ought to use the actual port number.)
I use XEmacs, so your mileage may vary.
Related
I have a dynamic sql file in which name of TBCREATOR changes as given in a parameter.
I use a simple python script to change the TBCREATOR=<variable here> and write the result to an output sql file.
calling this file using db2 -td# -vf <generated sql file>gives
DSNC105I : End of file reached while reading the command
Here is the file i need the TBCREATOR variable replaced:
CONNECT to 204.90.115.200:5040/DALLASC user *** using ****#
select REMARKS from sysibm.SYSCOLUMNS WHERE TBCREATOR='table' AND NAME='LCODE'
#
Here is the python script:
#!/usr/bin/python3
# #------replace table value with schema name
# print(list_of_lines)
fin = open("decrypt.sql", "rt")
#output file to write the result to
fout = open("decryptout.sql", "wt")
for line in fin:
fout.write(line.replace('table', 'ZXP214'))
fin.close()
fout.close()
After decryptout.sql is generated I call it using db2 -td# -vf decryptout.sql
and get the error given above.
Whats irritating is I have another sql file that contains exactly same data as decryptout.sql which runs smoothly with the db2 -td# -vf ... command. I tried to use the unix command cmp to compare the generated file and the one which I wrote, with the variable ZXP214 already replaced but there are no differences. What is causing this error?.
here is the file (that executes without error) I compare generated output with:
CONNECT to 204.90.115.200:5040/DALLASC user *** using ****#
select REMARKS from sysibm.SYSCOLUMNS WHERE TBCREATOR='ZXP214' AND NAME='LCODE'
#
I found that specifically on the https://ibmzxplore.influitive.com/ challenge, if you are using the java db2 command and working in the Zowe USS system (Unix System Services of zOS), there is a conflict of character sets. I believe the system will generally create files in EBCDIC format, whereas if you do
echo "CONNECT ..." > syscat.clp
the resulting file will be tagged as ISO8859-1 and will not be processed properly by db2. Instead, go to the USS interface and choose "create file", give it a folder and a name, and it will create the file untagged. You can use
ls -T
to see the tags. Then edit the file to give it the commands you need, and db2 will interoperate with it properly. Because you are creating the file with python, you may be running into similar issues. When you open the new file, use something like
open(input_file_name, mode=”w”, encoding=”cp1047”)
This makes sure the file is open as an EBCDIC file.
If you are using the Db2-LUW CLP (command line processor) that is written in c/c++ and runs on windows/linux/unix, then your syntax for CONNECT is not valid.
Unfortunately your question is ambigiously tagged so we cannot tell which Db2-server platform you actually use.
For Db2-LUW with the c/c++ written classic db2 command, the syntax for a type-1 CONNECT statement does not allow a connection-string (or partial connection string) as shown in your question. For Db2-LUW db2 clp, the target database must be externally defined (i.e not inside the script) , either via the legacy actions of both catalog tcpip node... combined with catalog database..., or must be defined in the db2dsdriver.cfg configuration file as plain XML.
If you want to use connection-strings then you can use the clpplus tool which is available for some Db2-LUW client packages, and is present on currently supported Db2-LUW servers. This lets you use Oracle style scripting with Db2. Refer to the online documentation for details.
If you not using the c/c++ classic db2 command, and you are instead using the emulated clp written in java only available with Z/OS-USS, then you must open a ticket with IBM support for that component, as that is not a matter for stackoverflow.
Yakuake provides a hotkey and a GUI way to rename commandline tabs/sessions.
I'd like to do the same via the command line, so I can script it and use it in an alias. (My goal is that if I use an alias which does an SSH to some server, then the tab is renamed according to this servers name...)
I tried the suggestions shown here Renaming a Konsole session from commandline after ssh so far no luck.
Since KDE4, one should use qdbus to control KDE apps (instead of deprecated and deleted DCOP).
For example, to change a title of the first session one may use:
qdbus org.kde.yakuake /Sessions/1 org.kde.konsole.Session.setTitle 1 "New title"
To explore available interfaces, methods and properties one may use qdbusviewer.
As a homework try to get a list of active sessions (before you going to change smth).
Like #fgysin pointed out, his command also works for me. BUT it needs the ` character and not " for the subcommand :
qdbus org.kde.yakuake /yakuake/sessions org.kde.yakuake.activeSessionId
It gives :
qdbus org.kde.yakuake /yakuake/tabs org.kde.yakuake.setTabTitle `qdbus org.kde.yakuake /yakuake/sessions org.kde.yakuake.activeSessionId` "NEW TAB TITLE";
I was reading the redis protocol and it says that you can send inline command with telnet by using "space-separated arguments in a telnet session". I had a few question about this
1) How does a redis-server know where the command ends if its space-separated? Does it end at \r\n? Since its not length prefixed I can't think of a different way. Maybe EOF...
2) If it ends with \r\n or something similar and is not length prefixed, does that mean that its not binary safe anymore (when the client sends inline commands)? i.e. if a client decides to send an inline command, it can no longer send any arbitrary character/byte it wishes?
3) Can any redis command be sent via telnet (with the only restriction that its not binary safe anymore) or is this only restricted to a PING? For example, a set would be:
SET key value\r\n
but SET key\r\n value\r\n is not allowed anymore (you are allowed to send that but the redis-server should sent a syntax error).
Our database has many tables with many columns. It takes a long time for the commandline mysql client to connect unless I pass it -A. I'd rather not have to put that in every time, so I tried adding the my.cnf option no-auto-rehash.
That works great until I have to use mysqldump:
mysqldump: unknown option '--no-auto-rehash'
Apparently mysqldump uses the options in my.cnf's [client] section, even if there is a separate [mysqldump] section. Is there any way to use no-auto-rehash and still have a functional mysqldump? Is there a [no-really-just-the-mysql-client] section?
Thanks.
The same question was asked on the mysql forums with no response:
http://forums.mysql.com/read.php?35,583759,583760
Put no-auto-rehash option in the [mysql] section, instead of [client]
[mysql]
no-auto-rehash
In this case mysqldump is functional.
I do this all the time:
[client]
compress
user=uuuuuuu
password=ppppppppp
[mysql]
prompt=\h\_\d>\_
no-auto-rehash
[mysqldump]
quick
max_allowed_packet=1G
I'm frequently updating my db on the server, and I run the following line from the command line:
mysqldump -u root --password=mypass mydb|mysql -h mysite.cc -u remotusr --password=remotpsw remotdb
The problem is that it loses the UTF characters along the way.
How can I keep the utf chars in cmd, or what is a better practice doing this?
( Upgrading to an answer )
As documented under mysqldump — A Database Backup Program:
--default-character-set=charset_name
Use charset_name as the default character set. See Section 10.5, “Character Set Configuration”. If no character set is specified, mysqldump uses utf8, and earlier versions use latin1.
[ deletia ]
--set-charset
Add SET NAMES default_character_set to the output. This option is enabled by default. To suppress the SET NAMES statement, use --skip-set-charset.
Therefore, unless you have settings in an option file which are overriding these defaults (you can specify --no-defaults to ensure they are not), the output from mysqldump should be more than capable of being redirected to another mysql session without loss of Unicode characters.
Instead, the conversion to a smaller character set appears to be occurring on retrieving & displaying your data from the new database. Since you are using PHP's Original MySQL API for this purpose, despite the warning in the introduction to its manual chapter (below), you should use mysql_set_charset() to set the connection character set.
This extension is not recommended for writing new code. Instead, either the mysqli or PDO_MySQL extension should be used. See also the MySQL API Overview for further help while choosing a MySQL API.