I am having a problem configuring the Windows PostgreSQL ODBC driver to connect to HSQLDB 2.5.0. As per the HSQLDB documentation I have installed version 11.01 of the PostgreSQL ODBC driver. When I test the connection from the ODBC Data Source Administrator I see the following in the ODBC log file: [0.000]Driver Version='11.01.0000,May 24 2019' linking 1915 dynamic Multithread library
[0.000]PQconnectdbParams: host='localhost' port='9001' dbname='test' user='test' sslmode='disable' password='test'
[0.109]PQsendQuery: 000000000033BCA0 'SET DateStyle = 'ISO';SET extra_float_digits = 2;show transaction_isolation'
[0.109] (ERROR) 42501 'user lacks privilege or object not found: DATESTYLE'
[1.157]PQfinish: 000000000033BCA0
It looks like the driver is sending a "SET DateStyle" command that HSQLDB doesn't understand. I've tried changing all the datasource options with no success. I have tried both the Unicode and ANSI versions of the driver.
The documentation on the web site is for version 2.5.1 which is in Release Candidate stage. You can download a snapshot jar from http://hsqldb.org/download/
Related
Unfortunately, I will not be able to create a good repro for this issue without sharing confidential creds to the database I am having issues with. Hopefully I have enough information below to flag any obvious problems that ODBC experts will understand.
Background
I am running a MacBook Pro with the following specs:
Model Name: MacBook Pro
Model Identifier: MacBookPro15,1
Processor Name: 6-Core Intel Core i7
Processor Speed: 2.6 GHz
Number of Processors: 1
Total Number of Cores: 6
L2 Cache (per Core): 256 KB
L3 Cache: 9 MB
Hyper-Threading Technology: Enabled
Memory: 32 GB
Boot ROM Version: 1037.0.78.0.0 (iBridge: 17.16.10572.0.0,0)
My ODBC connection is set using FreeTDS as specified here.
The relevant portion of freetds.conf is as follows:
# The POC SQL Server
[POC]
host = 172.22.238.154
port = 1433
tds version = 7.3
My odbcinst.ini file is as follows:
[FreeTDS]
Description=FreeTDS Driver for Linux & SQL Server
Driver=/usr/local/lib/libtdsodbc.so
Setup=/usr/local/lib/libtdsodbc.so
UsageCount=1
My odbc.ini file is specified as follows:
[POC]
Description = Connecton to Partners for our children SQL Server
Driver = FreeTDS
Servername = POC
I am trying to make a connection to a SQL Server 2012 database (via VPN) using the following connection information in R:
con <- DBI::dbConnect(odbc::odbc()
,dsn = "POC"
,uid = Sys.getenv("MSSQL_UN")
,database = "CA_ODS"
,pwd = Sys.getenv("MSSQL_PW"))
This generates the following connection object:
> con
<OdbcConnection> POC2
Database: CA_ODS
Microsoft SQL Server Version: 11.00.7001
In general, this connection works as expected. I can query the database using DBI::dbGetQuery(con, "select * from MyTable"), dplyr::tbl(con, MyTable), etc. without issue.
Problem
RStudio, however, is only displaying every other letter of the database objects, and truncating the object names after the first several letters. The following screenshot should illustrate the issue well:
The database I am trying to connect to is called CA_ODS. However, the RStudio object browser is only displaying every other letter of the database name (i.e. the DB is listed as C_D).
This does not appear to be limited to RStudio per se either. While the results of the actual database queries work fine as described above, the returned names from the INFORMATION_SCHEMA appear to match the information in the object browser. Below, when run directly from SQL Server Management Studio, the returned TABLE_CATALOG is CA_ODS, TABLE_SCHEMA is ndacan, etc. When run via the DB connection, however, I get the following.
> DBI::dbGetQuery(con, "SELECT * FROM INFORMATION_SCHEMA.TABLES WHERE
TABLE_SCHEMA='ndacan'")
TABLE_CATALOG TABLE_SCHEMA TABLE_NAME TABLE_TYPE
1 C_D naa f21v BASE TABLE
Question
Any suggestions as to how I can respecify my ODBC connection in R or in my FreeTDS configs to get the full name of database objects returned?
As noted in #r2evans comments, this appears to be an issue with odbc, running in R 3.6.0, on a Mac.
In general, it appears that this can be fixed by reinstalling odbc from source install.packages("odbc", type = 'source').
As also noted in the comments, I had recently upgraded my Mac to Catalina. Prior to installing odbc from source I needed to first reinstall XCode using xcode-select --install from my terminal.
As can be seen in the screen capture below, I am now getting the full object names displayed from the odbc connection.
I followed these steps to config the odbc drive for drill:
Configuring ODBC on Linux
After that I try to test the drill connection according Testing the ODBC Connection Instruction
/usr/bin/iodbctest
iODBC Demonstration program
This program shows an interactive SQL processor
Driver Manager: 03.52.0709.0909
Enter ODBC connect string (? shows list): DSN=Drill;ConnectionType=ZooKeeper;ZKQuorum=192.168.0.253:2181,192.168.0.254:2181;ZKClusterID=drillbits1
Driver: 1.2.0.1000 (MapR Drill ODBC Driver)
SQL>select columns[0] as 'Year',columns[1] as Revenues from 'hdfs.root'.'./user/hdfs/R/DisneyFinancialTest.csv'
1: ERROR [HY000] [MapR][Drill] (1070) Drill fails to execute the query with error [30017]Communication error. End of file
It works well with the connection to sql, but it shows that the drill fails to execute. What does the issue means? Can anyone help me trouble shot this problem?
quit; is interpreted as a SQL command, which is not valid for Drill. If you want to quit isql, then just use quit.
Finally I found out what was the issue, the problem was that my odbc driver version and my drill version is not match. I uninstalled the drill odbc driver 1.2 and installed version 0.8, it works well.
I solved the problem by referencing this link.
I want to connect to a Postgres Database with Lotus Notes 8.5.3 in win32 server. I tried to install Pg odbc driver 9.3 and the odbc connection is successful when i launch it in odbcad32. But it doesn't work through the domino server with ndctest command , i have this message error : "Data source name not found and no default driver specified" . Does anyone have an idea about this?
Problem resolved , the odbccad32 where i should configure my ODBC connection should be in SysWOW64 and not in System32. I don't know why but it's Microsoft.
I'm trying to connect to SQLite through ODBC/Windows 7 with VbScript.
Using Werner's SQLite ODBC driver (http://www.ch-werner.de/sqliteodbc) to connect to a local SQLite file (c:\test.db).
Using the connection string suggest at https://www.connectionstrings.com/sqlite3-odbc-driver
Dim dbConn : Set dbConn = CreateObject("ADODB.Connection")
ConnectionString = "DRIVER=SQLite3 ODBC Driver;Database=c:\test.db;LongNames=0;Timeout=1000;NoTXN=0; SyncPragma=NORMAL;StepAPI=0;"
dbConn.open ConnectionString
I already tried reinstalling the driver and restarting the system. The error message is always there:
Error: [Microsoft][ODBC Driver Manager] Data source name not found and no default driver specified
Code: 80004005
Source: Microsoft OLE DB Provider for ODBC Drivers
Any ideas?
Quoted from the SQLite ODBC Driver developer (Christian):
Check your installation. Version 0.992 is pretty old, current version
is 0.999. If you have a 64 bit Windows, install both 64 and 32 bit
drivers. It could be that the VB stuff is still 32 bit.
The program launching the script was 32Bit (despite the OS is 64Bit). Hence the need to install both 32 and 64Bit versions of the driver.
I'm using the RPostgreSQL 0.4 library (compiled on R 2.15.3) on R 2.15.2 under Windows 7 64-bit to interface to PostgreSQL. This works fine when connecting to my PostgreSQL databases on localhost. I'm trying to get my R code to run with a remote PostgreSQL database on Heroku. I can connect to Heroku's PostgreSQL database from the psql command shell on my machine, and it connects without a problem. I get the message:
psql (9.2.3, server 9.1.9)
WARNING: psql version 9.2, server version 9.1.
Some psql features might not work.
WARNING: Console code page (437) differs from Windows code page (1252)
8-bit characters might not work correctly. See psql reference
page "Notes for Windows users" for details.
SSL connection (cipher: DHE-RSA-AES256-SHA, bits: 256)
Clearly, psql uses SSL to connect. When I try to connect using the RPostgreSQL library routine dbConnect(), however, supplying exactly the same credentials using dname=, host=, port=, user=, password=, the connection fails with the complaint:
Error in postgresqlNewConnection(drv, ...) :
RS-DBI driver: (could not connect <user>#<hostname> on dbname <dbname>)
Calls: source ... .valueClassTest -> is -> is -> postgresqlNewConnection -> .Call
Execution halted
I know that Heroku insists on an SSL connection if you want to access their database remotely, so it seems likely that the R interface routine dbConnect() isn't trying SSL. Is there something else that I can do to get a remote connection from R to PostgreSQL on Heroku to work?
To get the JDBC URL for your heroku instance:
Get your hostname, username and password using [pg:credentials].
Your jdbc URL is going to be:
jdbc:postgresql://[hostname]/[database]?user=[user]&password=[password]&ssl=true&sslfactory=org.postgresql.ssl.NonValidatingFactory
Proceed as you would normally with JDBC.
Apparently there is a way using RJDBC. See:
http://ryepup.unwashedmeme.com/blog/2010/11/17/working-with-r-postgresql-ssl-and-mssql/
Please note that in order to connect to Heroku database with JDBC externally, it is important to set the sslfactory parameter as well. Hope Heroku team goes through it and modifies their documentation.
String dbUri = "jdbc:postgresql://ec2-54-243-202-174.compute-1.amazonaws.com:5432/**xxxxxxx**";
Properties props = new Properties();
props.setProperty("user", "**xxxxx**");
props.setProperty("password", "**xxxxx**");
props.setProperty("ssl", "true");//ssl to be set true
props.setProperty("sslfactory", "org.postgresql.ssl.NonValidatingFactory");// sslfactory to be set as shown above
Connection c=DriverManager.getConnection(dbUri,props);
See answer to related Q at https://stackoverflow.com/a/38942581. The suggestion of using RPostgres (https://github.com/rstats-db/RPostgres) instead of RPostgreSQL resolved this same issue for me.