The option character-set-database should not be configured in my.cnf
.
Please note what the MySQL Documentation says on character-set-database
:
The character set used by the default database. The server sets this variable whenever the default database changes. If there is no default database, the variable has the same value as character_set_server.
Footnote : This option is dynamic, but only the server should set this information. You should not set the value of this variable manually.
Even the Documentation says it is dynamic, it not supposed to be dynamically by any manual intervention against my.cnf
. If you look inside the database subfolder, you will find a file called db.opt
. EXAMPLE : When you run use dbname
in the mysql client, the file /var/lib/mysql/dbname/db.opt
is read in order to set character-set-specific database options contained in that file. For this reason, the variable has to be dynamic.
If you cannot access the database from the OS to see db.opt
, simply run this command:
SHOW CREATE DATABASE dbname;
on any database and you will see what db.opt
contains (or defaults if db.opt
is not there)
mysql> show create database mysql;
+----------+------------------------------------------------------------------+
| Database | Create Database |
+----------+------------------------------------------------------------------+
| mysql | CREATE DATABASE `mysql` /*!40100 DEFAULT CHARACTER SET latin1 */ |
+----------+------------------------------------------------------------------+
1 row in set (0.00 sec)
mysql>
In light of this, you should try setting character-set-server
in my.cnf
only (or at least remove character-set-database
from my.cnf
). Then, run service mysql restart
.
Give it a Try !!!
UPDATE #1
I sort of dealt with a question like this before : Why default character_set_server is latin1?
Looking back at my old link, I had an idea: I ran this:
mysql> select version();
+-----------+
| version() |
+-----------+
| 5.6.10 |
+-----------+
1 row in set (0.00 sec)
mysql> select * from information_schema.collations where COLLATION_NAME like '%kor%';
+-----------------+--------------------+----+------------+-------------+---------+
| COLLATION_NAME | CHARACTER_SET_NAME | ID | IS_DEFAULT | IS_COMPILED | SORTLEN |
+-----------------+--------------------+----+------------+-------------+---------+
| euckr_korean_ci | euckr | 19 | Yes | Yes | 1 |
+-----------------+--------------------+----+------------+-------------+---------+
1 row in set (0.00 sec)
mysql>
You could set a Korean character set if need to.
UPDATE #2
You should leave wait_timeout and interactive_timeout out of the [client]
and [mysql]
groups.
You say the directory has rw
permission; does it also have x
permission. You need x
permission to access the files in a directory (so you might set the permissions on the directory to ... gritted teeth ... 777, but you shouldn't. Is the directory owned by user informix
and does it belong to group informix
? Ideally, it should be owned by informix:informix
, and the permissions should be 770 (or drwxrwx---
).
Best Answer
In theory, you would need to specify an actual tab, possibly using Bash's ANSI C quoting:
Unfortunately, that looks like you're not allowed to use tab either. (Test: Informix 12.10.FC5 on Mac OS X 10.11.6.)
Incidentally, I tried some alternatives:
$'\a'
(alert, aka Control-G) and$'\b'
(backspace, aka Control-H) are both accepted, but none of$'\f'
(formfeed, aka Control-L),$'\v'
(vertical tab, aka Control-K),$'\r'
(carriage return, aka Control-M) of$'\n'
(newline, aka Control-J) are allowed. Any other control character from$'\0'
through$'\037'
(octal numbers, all except 9-13 decimal, 011-015 octal) seems to be OK (and NUL or 0 being OK did surprise me!). Do you have any tabs in your main data? If not, you could export with one of the acceptable alternative characters and then map that to tab. If you have tabs, life is harder because you'd need to protect any tabs that are in a data field with a backslash.DB-Access allows
DBDELIMITER=$'\t'
without problem and produces an unload file with tab delimiters, so the problem is not in the shell code I'm using.If you're certain you must have tabs, then investigate Art Kagel's
myexport
which is part of hisutils_ak
package from the IIUG Software Repository, which also uses my SQLCMD, available from the same source. UsingDBDELIMITER=$'\t' sqlunload -d stores -t customers
(orsqlcmd -U -D $'\t' -d stores -t customers
, or various other twists of the command line) produces output in a tab-delimited format. (On its own, SQLCMD does not handle a full export; it will cheerfully unload single tables, though. It does not yet handle NUL as a field separator or line separator — a design decision or artefact that I need to review.)