I have my unixodbc odbc.ini configure file like this:
[test]
Driver = /usr/local/lib/libmyodbc5-5.1.8.so
Description = Connector/ODBC 5.1.8 Driver DSN
SERVER = 127.0.0.1
PORT = 3306
USER = root
Password =
DATABASE = test
OPTION =
SOCKET =
And the problem is that it will not use the database as specified above, which is 'test'.
What I have to do is to manually execute a direct sql to change to database and run my query:
SQLExecDirect(stmt, "USE test", SQL_NTS);
SQLExecDirect(stmt, "SELECT * FROM mytable", SQL_NTS);
Any idea on how should I get rid of the 'USE test' which is a mysql command.
Why is unixodbc not setting 'test' as the default db since it's already specified in the conf file?
As on windows the driver manager (unixODBC in this case) only acts on the Driver tag, all other entries in the DSN are up to the driver to interpret. It doesn't notice there is a database= entry and know by magic that in this driver it should execute a "USE" command, and for another call SQLSetConnectAttr( SQL_ATTR_CURRENT_CATALOG ).
On my copy of the MySQL driver, it certainly uses the database= entry. However, I would check that 1. The copy of the driver you are using is built to use the unixODBC lib to access the shared config file (libodbcinst.so), or the driver is reading it directly, and is reading the same ini file as unixODBC. Possibly check with strace to see what ini is opened after the driver is loaded. Maybe try setting ODBCINI=/path/to/your/odbc.ini
[test]
Driver = /usr/local/lib/libmyodbc5-5.1.8.so
Description = Connector/ODBC 5.1.8 Driver DSN
SERVER = 127.0.0.1
PORT = 3306
USER = root
Password =
**DATABASE** = test
**OPTION** = **3**
**SOCKET** =
and can change options between 1,2 too
Related
I am running an R application in a Docker container and would like to connect to a MySQL 8 database using the RMySQL library. I can connect to the database from the container using the mysql terminal command without any problems, but when I call dbConnect() in my R script I get an unknown SSL connection error (see below).
As I am using the same SSL certificates with the terminal command as well as in my R script, it must have something to do with the MySQL version used by RMySQL. I need to have MySQL 5.7 installed in the container, too, as some other R packages cannot be built otherwise. However, according to the thread below you can specify the directory of the MySQL version to be used when installing RMySQL:
adding RMySQL package to R fails (on Windows)?
So I set $MYSQL_HOME in /etc/R/Renviron.site and called install.packages('RMySQL',type='source').
Apparently you also need to copy some .lib and .dll files to make it work in Windows, but where do I find the equivalent files in Linux?
Database handler script:
#' #import DBI
#' #import RMySQL
connectToDatabase <- function(myproject.db_config) {
dbConfig <- read.properties(myproject.db_config)
print(dbConfig)
dbHandle <- dbConnect(
MySQL(),
dbname = dbConfig$databaseName,
host = dbConfig$host,
port = as.integer(dbConfig$port),
user = dbConfig$user,
password = dbConfig$password
)
return(dbHandle)
}
Config file passed to the read.properties() command:
host=domain.subdomain.de
port=3306
user=john.doe
password=mypassword
databaseName=my_db
ssl-ca=/staging/mysql-ssl/ca.pem
ssl-cert=/staging/mysql-ssl/client-cert.pem
ssl-key=/staging/mysql-ssl/client-key.pem
Error message in R:
Error in connection_create(host, username, password, dbname, as.integer(port), :
Failed to connect: SSL connection error: unknown error number
I found the solution by myself. The SSL certificates were not applied in the dbConnect() call. They need to be defined in a mysql.cnf file which is passed to dbConnect() in the default.file parameter:
dbHandle <- dbConnect(
MySQL(),
dbname = dbConfig$databaseName,
host = dbConfig$host,
port = as.integer(dbConfig$port),
user = dbConfig$user,
password = dbConfig$password,
default.file = dbConfig$configFile
)
Config file passed to the read.properties() command:
host=domain.subdomain.de
port=3306
user=john.doe
password=mypassword
databaseName=my_db
configFile=/staging/config/mysql.cnf
mysql.cnf:
[mysqld]
ssl-ca=/staging/mysql-ssl/ca.pem
ssl-cert=/staging/mysql-ssl/client-cert.pem
ssl-key=/staging/mysql-ssl/client-key.pem
On my Mac I'm trying to connect to databases with unixodbc (v. 2.3.7 from Homebrew).
odbcinst -j shows:
DRIVERS............: /usr/local/etc/odbcinst.ini
SYSTEM DATA SOURCES: /usr/local/etc/odbc.ini
FILE DATA SOURCES..: /usr/local/etc/ODBCDataSources
USER DATA SOURCES..: /Users/homer/.odbc.ini
SQLULEN Size.......: 8
SQLLEN Size........: 8
SQLSETPOSIROW Size.: 8
Partial contents of ~/.odbc.ini and /usr/local/etc/odbc.ini:
[mysql-local]
description = local server
Driver = MySQLDriver
SERVER = localhost
USER = testuser
PASSWORD = testpass
DATABASE = testdb
Partial contents of /usr/local/etc/odbcinst.ini
[MySQLDriver]
Driver = /usr/local/lib/libodbc.dylib
Setup = /usr/local/lib/libodbc.dylib
FileUsage = 1
The Driver/Setup file links to a file that links to actual driver: /usr/local/Cellar/unixodbc/2.3.7/lib/libodbc.2.dylib. I have set the perms on this file to 755.
Then I try to connect:
isql mysql-local testuser testpass -v
The result is:
[IM004][unixODBC][Driver Manager]Driver's SQLAllocHandle on SQL_HANDLE_HENV failed
[ISQL]ERROR: Could not SQLConnect
For some reason I have osql, which the Web tells me is used to connect to SQL Server. (Perhaps it comes with the Brew's unixodbc?) I can use it to verify that the .ini files are being parsed correctly. Thus
osql -I /usr/local/etc -S mysql-local -U testuser -P testpass
results in:
"" is NOT a directory, overridden by
"/usr/local/etc".
checking odbc.ini files
reading /Users/homer/.odbc.ini
[mysql-local] found in /Users/homer/.odbc.ini
found this section:
[mysql-local]
description = local server
Driver = MySQLDriver
Server = 127.0.0.1
USER = testuser
PASSWORD = testpass
DATABASE = testdb
looking for driver for DSN [mysql-local] in /Users/homer/.odbc.ini
found driver line: " Driver = MySQLDriver"
driver "MySQLDriver" found for [mysql-local] in .odbc.ini
found driver named "MySQLDriver"
"MySQLDriver" is not an executable file
looking for entry named [MySQLDriver] in /usr/local/etc/odbcinst.ini
found driver line: " Driver = /usr/local/lib/libodbc.dylib"
found driver /usr/local/lib/libodbc.dylib for [MySQLDriver] in odbcinst.ini
/usr/local/lib/libodbc.dylib is an executable file
"Server" found, not using freetds.conf
Server is "127.0.0.1"
looking up hostname for ip address 127.0.0.1
Configuration looks OK. Connection details:
DSN: mysql-local
odbc.ini: /Users/homer/.odbc.ini
Driver: /usr/local/lib/libodbc.dylib
Server hostname: localhost
Address: 127.0.0.1
Attempting connection as testuser ...
+ isql mysql-local testuser testpass -v
[IM004][unixODBC][Driver Manager]Driver's SQLAllocHandle on SQL_HANDLE_HENV failed
[ISQL]ERROR: Could not SQLConnect
sed: /tmp/osql.dump.44362: No such file or directory
Everything I try always comes down to the same error:
[IM004][unixODBC][Driver Manager]Driver's SQLAllocHandle on SQL_HANDLE_HENV failed
For good measure, here are the logs from isql mysql-local testuser testpass:
[ODBC][54953][1538867223.117217][__handles.c][460]
Exit:[SQL_SUCCESS]
Environment = 0x7f9829010400
[ODBC][54953][1538867223.117416][SQLAllocHandle.c][377]
Entry:
Handle Type = 2
Input Handle = 0x7f9829010400
[ODBC][54953][1538867223.117521][SQLAllocHandle.c][493]
Exit:[SQL_SUCCESS]
Output Handle = 0x7f982903e800
[ODBC][54953][1538867223.117601][SQLConnect.c][3721]
Entry:
Connection = 0x7f982903e800
Server Name = [mysql-local][length = 11 (SQL_NTS)]
User Name = [testuser][length = 8 (SQL_NTS)]
Authentication = [********][length = 8 (SQL_NTS)]
UNICODE Using encoding ASCII 'UTF-8' and UNICODE 'UCS-2-INTERNAL'
[ODBC][54953][1538867223.126854][SQLConnect.c][1380]Error: IM004
[ODBC][54953][1538867223.127046][SQLFreeHandle.c][290]
Entry:
Handle Type = 2
Input Handle = 0x7f982903e800
[ODBC][54953][1538867223.127191][SQLFreeHandle.c][339]
Exit:[SQL_SUCCESS]
[ODBC][54953][1538867223.127276][SQLFreeHandle.c][220]
Entry:
Handle Type = 1
Input Handle = 0x7f9829010400
Notes:
I have seen the same error discussed elsewhere, where odbc-mediated connections to other databases (e.g., SQL Server) are desired. Solutions proposed in those cases do not appear to apply to MySQL connections.
I am hoping to make the connections this with linuxodbc, as this is the instrument said to be required for maximum SQLintegration in the R Studio IDE.
On Linux I find that unixodbc works fine.
Much thanks in advance to anyone who can point me in the right direction.
I have grafana 4.4.3 on an ubuntu 16.4 LTS which is installed on an vm and its IP is 1.2.3.4 .
I also have a mysql database version 5.0.95 on a CentOS 5.9 and its ip is 5.5.5.5 and mydatabase name is : voip
I want to set mysql as backend for grafana. I'v changed my grafana.ini file like this:
###[database]###
type = mysql
host = 5.5.5.5:3306
name = voip
user = root
password = t#123
###[session]###
provider: mysql
provider_config = `root:t#123#tcp(5.5.5.5:3306)/voip`
I also set my root account to be used as a remote account.
when I want to start grafana-server service, it gives me this error:
Fail to initialize orm engine" logger=sqlstore error="Sqlstore::Migration
failed err: this user requires old password authentication. If you still
want to use it, please add 'allowOldPasswords=1' to your DSN. See also
https://github.com/go-sql-driver/mysql/wiki/old_passwords\n"
what should I do? Did I don anything wrong?
allowOldPasswords error is given when you are using old version of mysql database. to change this you should go to /etc/my.cnf and change oldpasswords = 1 to oldpasswords = 0. next you have to login to your mysql and then enter these commands:
SET SESSION old_passwords=FALSE;
SET PASSWORD FOR 'user_name'#'%'=PASSWORD('<put password here>');
flush privileges;
and at last, restart your mysql service.
hope this post is helpful...
I have two systems. my first system is ubuntu 16.04. which, work as remote.
and another is centos 6. which, run in virtually. In centos, freeswitch installed. I have to send data from freeswitch to remote system means ubuntu.
on centos, my configuration of odbc.ini as :
[freeswitch]
DRIVER = /usr/lib64/libodbcmyS.so
SERVER = <ipaddress>
USER = root
PASSWORD = <password>
PORT = 3306
DATABASE = freeswitch
OPTION = 67108864
and odbcinst.int as below:
[MySQL]
Description = ODBC for MySQL
Driver = /usr/lib64/libmyodbc.so
Setup = /usr/lib64/libodbcmyS.so
FileUsage = 1
Threading = 0
after setup above code.
I have to check odbc connection. for this, command fire as :
isql -v freeswitch
but, it show error as :
[IM004][unixODBC][Driver Manager]Driver's SQLAllocHandle on SQL_HANDLE_HENV failed
[ISQL]ERROR: Could not SQLConnect
wrong driver description arise this type of error.
I have set proper driver description. wrongly, setup description mention in driver field.
I think you need to change the line
DRIVER = /usr/lib64/libodbcmyS.so
to
DRIVER = MySQL
Thanks.
I'm a little green at this, and I hope the issue I'm having is a simple one...edit: new information at bottom
I need to make a connection to a remote mysql (Amazon RDS) database.
After following a few tutorials, I have unixodbc and libmyodbc installed and configured on the client, but when I try to connect via isql, I get the error
[08S01][unixODBC][MySQL][ODBC 5.1 Driver]Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (2)
[ISQL]ERROR: Could not SQLConnect
The most confusing part about this error is that I'm not trying to connect to a local database, but rather to a remote one. I do not have a mysql.sock file on the client...this isn't the issue though is it?
I'm sensing a configuration error but I'm just not sure what it could be.
If I run odbcinst -j then the output is:
DRIVERS............: /etc/unixODBC/odbcinst.ini
SYSTEM DATA SOURCES: /etc/unixODBC/odbc.ini
USER DATA SOURCES..: /root/.odbc.ini
The content of /etc/unixODBC/odbcinst.ini is:
[MySQL]
Description = ODBC for MySQL
Driver = /usr/lib64/libmyodbc5.so
Setup = /usr/lib64/unixODBC/libodbcmyS.so
UsageCount = 5
[MySQL ODBC 515 Driver]
Description = ODBC 5.515 for MySQL
DRIVER = /usr/lib64/libmyodbc5-5.1.5.so
SETUP = /usr/lib64/unixODBC/libodbcmyS.so
UsageCount = 3
Please note that I had to make up this configuration myself, I did a find for libmyodbc* and found these two .so files, thus set up a driver for each of them. A search for libodbcmyS* yields:
/usr/lib64/unixODBC/libodbcmyS.so.1
/usr/lib64/unixODBC/libodbcmyS.so
/usr/lib64/unixODBC/libodbcmyS.so.1.0.0
So, I don't know what else that configuration could be.
The content of /etc/unixODBC/odbc.ini is:
[target_db]
Driver = MySQL
Server = [servername.com]
Port = 3306
Database = [databasename]
Option = 2
User = [username]
Password = [password]
I've tried different options in "Driver", changing it from MySQL, to MySQL ODBC 515 Driver, to the path to the .so file (eg: /usr/lib64/libmyodbc5.so) and all yield the same result.
I'm running:
odbcinst -i -d -f /etc/unixODBC/odbcinst.ini
Followed by:
odbcinst -i -s -l -f /etc/unixODBC/odbc.ini
Followed by:
odbcinst -s -q
Which prints out the name of my connection, ie [target_db]
Then, I try the connect:
isql -v target_db user password
or just
isql -v target_db
and get the error shown above.
Anyone happen to know what I'm doing wrong here? Thanks a bunch-
EDIT:
Wanted to mention that I'm able to connect to the database from this server using the mysql command line tools.
I installed a local mysql database, and I'm able to connect to this using isql. It seems to be ignoring my odbc.ini file entirely, i have to enter a name with the command, ie isql -v test-database, but it still tries to connect to localhost despite my settings.
I feel as though I've tried everything but will keep at it and will post if i find a solution.
You could try to connect using the ip of your server instead of the dns entry on the "Server" line of odbc.ini.. Have you verified the driver is installed with phpinfo()?
Try to set the environment variable ODBCINI with the path of your odbc.ini file.
Keep in mind that the odbc.ini file you point to must be "write-accessible" by the user that is running the program (i.e. the user must have permissions to write in this file).
chmod g+w .odbc.ini did it for me since we run the DB with ORACLE-Start and the crs-User seems to be in charge