I am using Perl 5.14.2 on Ubuntu wheezy 64 bit.
I am trying to connect to a Pervasive SQL server v9.5 that is installed on a windows 2008 machine.
I tested the connection with isql and it works properly, I tested with the following command:
isql -v <db_name>
I use the DBD:ODBC v1.39 (latest version) perl module installed from cpan.
I am using the following command to connect to sql server:
use DBI;
my $db = DBI->connect('dbi:ODBC:Moked');
Moked is the connection name that was defined in the unixodbc v2.2.14 in odbc.ini.
/etc/odbc.ini
[Moked]
Driver=PERVASIVE_ODBC
Description=Pervasive ODBC Interface: Moked
ServerName=<ip>:<port>
DBQ=MIDA
UID=
PWD=
OpenMode=0
PvTranslate=
when I try to connect with the command i showed above I get error SQL-HY001 that by googling I understood that it relates to memory allocation, usually people get these while querying and not while trying to connect/
it seems that DBI does recognize the connection because if I type a different name, for example 'Moked2', i get the error SQL-IM002 instead.
any ideas?
how can I debug this issue further?
any information regarding the issue would be greatly appreciated.
thanks!
You are getting the memory allocation error because the PSQL v11 client cannot reliably connect to a PSQL v9.5 server. If you want to use the v11 client, you need the v11 server too. You might be able to get away with the v11 client at a Btrieve level but there were significant changes between v9 and v11 on the ODBC side.
Related
I am having problems with odbc psql link on centos8 and with postgres-odbc version 10.3(this one was the default one in the repository)
I have defined my ssl cert files as such
pqopt={sslrootcert=/etc/ssl/certs/db_ssl_cert/client.crt \
sslcert=/etc/ssl/certs/db_ssl_cert/postgresql_client.crt \
sslkey=/etc/ssl/certs/db_ssl_cert/postgresql_client.key}
But I keep getting error(when using isql), even though I can connect using psql
[08001][unixODBC]libpq connection parameter error:invalid connection option "{sslrootcert"
I get this error no matter what I put in front of the first = sign.
Should the certificates be in ~/.postgresql/ directory?
What is the problem? On my windows machine I input parameters as above and no problems with the driver version 11.0, should I simply update the driver to the latest version, or what would be the solution as pgopt was supported from 9.6 postgres-odbc?
I've asked this question on serverfault and someone told me to ask here.
Can I make a connection to a PostgreSQL server using FreeTDS, more specifically using the tsql command?
I've been trying for a few days now, using many different configurations. Even though I am able to connect to the DB using isql and PostgreSQL odbc driver, I can't make it work using tsql (it also doesn't seem to use odbc.ini or odbcinst.ini). So, I was wondering if the tsql command only works with SQL Server.
If you want, I can post the files freetds.conf, odbc.ini and odbcinst.ini.
Thanks.
FreeTDS only supports the TDS protocol (hence the name). And this protocol is only implemented by Microsoft SQL Server and the Sybase database.
So, no you can not use FreeTDS to connect to a Postgres database.
You need to use the Postgres ODBC driver, the Postgres .Net driver or the Postgres JDBC driver to do this - depending on the programming language of your application. From a C program you can also connect to Postgres directly using the libpq library.
I have two CentOS 6.7 machines (server A and B). Same package versions are installed on each system.
Last week I enabled the openSSH FIPS 140-2 module on Server A, and that system works flawlessly (including tsql queries to a SQL Server instance).
Today I went through the same steps on Server B (in the link above). After rebooting, fips showed enabled and tested OK - but tsql (to the same SQL Server instance) stopped working with the following error:
[serverB ~]# tsql -S egServer80 -U myusername
Password:
locale is "en_US.UTF-8"
locale charset is "UTF-8"
using default charset "UTF-8"
Error 20002 (severity 9):
Adaptive Server connection failed
There was a problem connecting to the server
I check the log files and find this:
tsql: Libgcrypt warning: MD5 used - FIPS mode inactivated
Enabling debug in freetds yielded this additional error:
14:56:46.617196 3577 (net.c:1366):'''handshake failed: GnuTLS internal error.
Backing out the FIPS module (removing fips=1 from grub.conf) and rebooting set things back and I was again able to tsql into my SQL Server instance.
Both CentOS machines use the same libgcrypt version (1.4.5).
Why (or how) is enabling FIPS in grub causing libgcrypt to fail on this one machine? Clearly something configuration is off between the machines, but I cannot spot it, and have exhausted resources in finding where to look next.
NOTE #1:
I can reproduce the tsql problem on Server B without enabling FIPS 140-2 in grub, by creating an empty file /etc/gcrypt/fips_enabled. Removing this file sets the system back to normal, and tsql works again.
NOTE #2:
Adding file /etc/gcrypt/fips_enabled on Server A does not affect tsql function at all.
Additional Information
libgcrypt version 1.4.5
freetds version 0.91
openssl version 1.0.1e
CentOS version 6.7
I'm encountering a weird problem after I restored Firebird database. Production database (Firebird 2.1) runs on 64bit server and we're using FreeAdHoc library with extra functions. I've backed up production database with gbak, moved to local machine (64bit Ubuntu 13.10). Installed firebird 2.1.5 locally and downloaded latest FreeAdHoc library.
Now when I try to execute some function from it via iSQL:
/opt/firebird/bin/isql db.fdb -user sysdba -password masterkey -i /opt/firebird/bin/command.sql
and the content of command.sql is
select f_addday(current_timestamp,10) from rdb$database;
it runs properly and executes that UDF function.
HOWEVER, when I try to execute the same command via Flamerobin or PHP script, I get this error:
Engine Code : 335544343
Engine Message :
invalid request BLR at offset 59
function F_ADDDAY is not defined
module name or entrypoint could not be found
Can someone advise? I think that the fact that isql executes and flamerobin/php doesn't is a good lead but I lack an experience to figure out why it could be the case.
Thanks, Michal
I have a database file (*.db) that need to be recovered.
The bad is, the end-user have null idea of the version of the database. Not know the password. The original developer is lost. The computer where was installed was formatted. We have not experience in this database software. Yeah, nightmare.
My guess is a old database. I'm trying to open it in Sybase 11, dev edition.
I follow this steps: http://dcx.sybase.com/1101en/sachanges_en11/unloading-reloading-upgrading-newjasper.html
I try to use the UNLOAD utility from command line & from the Sybase central utility. From command line I do:
./dbinfo -c "DBF=/Users/mamcx/Downloads/CEMDE_ENDOCRINO_S.A.DB;UID=DBA;PWD=sql"
SQL Anywhere Information Utility Version 11.0.1.2045
Unable to start specified database: '/Users/mamcx/Downloads/CEMDE_ENDOCRINO_S.A.DB' was created by a different version of the software
Ok, I try to unload:
./dbunload -c "DBF=/Users/mamcx/Downloads/CEMDE_ENDOCRINO_S.A.DB;UID=DBA;PWD=sql" -n /Users/mamcx/Desktop/
SQL Anywhere Unload Utility Version 11.0.1.2045
Connecting and initializing
***** SQL error: Unable to start database server
Ok, from the server admin tool:
dbunload -v -c "UID=dba;PWD=***;DBF=/Users/mamcx/Downloads/CEMDE_ENDOCRINO_S.A.DB" -an "/Users/mamcx/Desktop/baba.db" -ap 4096 -ea None -ii -sa -so _sc866192545
Connecting and initializing
***** SQL error: Unable to start database server
An error occurred while attempting to unload the database '/Users/mamcx/Downloads/CEMDE_ENDOCRINO_S.A.DB'.
Exist a way to know the version of the database server used to create this? Is possible to recover this file?
I don't know how to get the version out of the Database File if you are not able to start it.
You could get a hint from the hopefully existing Client PC's. Check the ODBC Driver Version they have installed.
I had good success with the support of Sybase. If you or your client has a support contract you can get them involved.
HTH
Try to simply start a server with that database and capture the output with -z -o server.out. The server.out file should contain a more specific error telling you why it can't start the database. This error can occur if you are trying to start something that is not a SQL Anywhere database.
You may also want to post this question over at http://sqlanywhere-forum.sap.com/.