Connection string for Gupta/Centura's SQLBase

[mfl...@gmail.com]

Hi!

I'm having problems connecting to a SQLBase through ODBC. This works
great through both PHP and isql (see under), but when I try the same
with pyodbc, I'm experiencing problems.

$ isql gupta1 SYSADM SYSADM
+---------------------------------------+
| Connected! |
| |
| sql-statement |
| help [tablename] |
| quit |
| |
+---------------------------------------+
SQL>

# this also works
$db = odbc_connect("gupta1", "SYSADM", "SYSADM");

In Python:

>>> pyodbc.dataSources()
{'gupta1': '/tmp/gupta/libsqlbaseodbc.so'}
>>> cnxn = pyodbc.connect('DSN=gupta1;UID=SYSADM;PWD=SYSADM')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
pyodbc.Error: ('IM002', '[IM002] [unixODBC][Driver Manager]Data source
name not found, and no default driver specified (0)
(SQLDriverConnectW)')
>>> cnxn = pyodbc.connect('DRIVER=gupta1;UID=SYSADM;PWD=SYSADM')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
pyodbc.Error: ('IM002', '[IM002] [unixODBC][Driver Manager]Data source
name not found, and no default driver specified (0)
(SQLDriverConnectW)')
>>> cnxn = pyodbc.connect('DRIVER=/tmp/gupta/libsqlbaseodbc.so;UID=SYSADM;PWD=SYSADM')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
pyodbc.Error: ('IM002', '[IM002] [unixODBC][Driver Manager]Data source
name not found, and no default driver specified (0)
(SQLDriverConnectW)')

Any ideas?

Marius

[mkleehammer]

> I'm having problems connecting to a SQLBase through ODBC. This works
> great through both PHP and isql (see under), but when I try the same
> with pyodbc, I'm experiencing problems.
>

> >>> pyodbc.dataSources()
>
> {'gupta1': '/tmp/gupta/libsqlbaseodbc.so'}>>> cnxn = pyodbc.connect('DSN=gupta1;UID=SYSADM;PWD=SYSADM')
>
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
> pyodbc.Error: ('IM002', '[IM002] [unixODBC][Driver Manager]Data source
> name not found, and no default driver specified (0)
> (SQLDriverConnectW)')>>> cnxn = pyodbc.connect('DRIVER=gupta1;UID=SYSADM;PWD=SYSADM')
>
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
> pyodbc.Error: ('IM002', '[IM002] [unixODBC][Driver Manager]Data source
> name not found, and no default driver specified (0)
> (SQLDriverConnectW)')>>> cnxn = pyodbc.connect('DRIVER=/tmp/gupta/libsqlbaseodbc.so;UID=SYSADM;PWD=SYSADM')

Can you turn on ODBC tracing and make the connection with Perl and
then pyodbc so I can compare?

I'm not sure where the tracing flag would go:
http://www.unixodbc.org/odbcinst.html
http://www.easysoft.com/support/kb/kb00945.html

If you could post the log file here I can probably figure something
out. (Check for private information first: db names, passwords, etc.)

[mfl...@gmail.com]

On Dec 6, 5:15 pm, mkleehammer <mkleeham...@gmail.com> wrote:
> Can you turn on ODBC tracing and make the connection with Perl and
> then pyodbc so I can compare?

Hm. I've tried turning on the tracing, but I believe that reports back
the same issues as pyodbc did:

[ODBC][25275][__handles.c][444]
Exit:[SQL_SUCCESS]
Environment = 0x9d428d0
[ODBC][25275][SQLSetEnvAttr.c][182]
Entry:
Environment = 0x9d428d0
Attribute = SQL_ATTR_ODBC_VERSION
Value = 0x3
StrLen = -6
[ODBC][25275][SQLSetEnvAttr.c][349]
Exit:[SQL_SUCCESS]
[ODBC][25275][SQLAllocHandle.c][345]
Entry:
Handle Type = 2
Input Handle = 0x9d428d0
[ODBC][25275][SQLAllocHandle.c][463]
Exit:[SQL_SUCCESS]
Output Handle = 0x9e59f90
[ODBC][25275][SQLDriverConnect.c][678]
Entry:
Connection = 0x9e59f90
Window Hdl = (nil)
Str In = [gupta1][length = 6]
Str Out = 0xbfc999c8
Str Out Max = 2048
Str Out Ptr = 0xbfc999c2
Completion = 0
[ODBC][25275][SQLDriverConnect.c][1085]Error: IM002
[ODBC][25275][SQLError.c][424]
Entry:
Connection = 0x9e59f90
SQLState = 0xbfc9973a
Native = 0xbfc99740
Message Text = 0xbfc99748
Buffer Length = 511
Text Len Ptr = 0xbfc99746
[ODBC][25275][SQLError.c][461]
Exit:[SQL_SUCCESS]
SQLState = IM002
Native = 0xbfc99740 -> 0
Message Text = [[unixODBC][Driver Manager]Data source name not
found, and no default driver specified]
[ODBC][25275][SQLError.c][424]
Entry:
Connection = 0x9e59f90
SQLState = 0xbfc9973a
Native = 0xbfc99740
Message Text = 0xbfc99748
Buffer Length = 511
Text Len Ptr = 0xbfc99746
[ODBC][25275][SQLError.c][461]
Exit:[SQL_NO_DATA]
[ODBC][25275][SQLConnect.c][3549]
Entry:
Connection = 0x9e59f90
Server Name = [gupta1][length = 6]
User Name = [SYSADM][length = 6]
Authentication = [******][length = 6]
UNICODE Using encoding ASCII 'ISO8859-1' and UNICODE 'UCS-2LE'

[ODBC][25275][SQLConnect.c][4123]
Exit:[SQL_SUCCESS]
[ODBC][25275][SQLSetConnectOption.c][262]
Entry:
Connection = 0x9e59f90
Option = SQL_ATTR_AUTOCOMMIT
Value = 1
[ODBC][25275][SQLSetConnectOption.c][525]
Exit:[SQL_SUCCESS]
[ODBC][25275][SQLGetInfo.c][214]
Entry:
Connection = 0x9e59f90
Info Type = SQL_DRIVER_ODBC_VER (77)
Info Value = 0x9db5624
Buffer Length = 20
StrLen = 0xbfc999c6
[ODBC][25275][SQLGetInfo.c][528]
Exit:[SQL_SUCCESS]
[ODBC][25275][SQLGetInfo.c][214]
Entry:
Connection = 0x9e59f90
Info Type = SQL_DBMS_NAME (17)
Info Value = 0x9db5638
Buffer Length = 64
StrLen = 0xbfc999c6
[ODBC][25275][SQLGetInfo.c][528]
Exit:[SQL_SUCCESS]
[ODBC][25275][SQLGetFunctions.c][147]
Entry:
Connection = 0x9e59f90
Id = SQLMoreResults
Supported = 0xbfc999c4
[ODBC][25275][SQLGetFunctions.c][182]
Exit:[SQL_SUCCESS]
Supported = 0xbfc999c4 -> 1
[ODBC][25275][SQLGetFunctions.c][147]
Entry:
Connection = 0x9e59f90
Id = SQLDescribeParam
Supported = 0xbfc999c4
[ODBC][25275][SQLGetFunctions.c][182]
Exit:[SQL_SUCCESS]
Supported = 0xbfc999c4 -> 0
[ODBC][25275][SQLSetConnectOption.c][262]
Entry:
Connection = 0x9e59f90
Option = SQL_ATTR_AUTOCOMMIT
Value = 1
[ODBC][25275][SQLSetConnectOption.c][525]
Exit:[SQL_SUCCESS]
[ODBC][25275][SQLGetConnectOption.c][219]
Entry:
Connection = 0x9e59f90
Option = SQL_ATTR_AUTOCOMMIT
Value = 0xbfc9a2d8
[ODBC][25275][SQLGetConnectOption.c][499]
Exit:[SQL_SUCCESS]
[ODBC][25275][SQLDisconnect.c][204]
Entry:
Connection = 0x9e59f90
[ODBC][25275][SQLDisconnect.c][341]
Exit:[SQL_SUCCESS]
[ODBC][25275][SQLFreeHandle.c][268]
Entry:
Handle Type = 2
Input Handle = 0x9e59f90
[ODBC][25275][SQLFreeHandle.c][317]
Exit:[SQL_SUCCESS]
[ODBC][25275][SQLFreeHandle.c][203]
Entry:
Handle Type = 1
Input Handle = 0x9d428d0

If you see there at entry 461:

[ODBC][25275][SQLError.c][461]
Exit:[SQL_SUCCESS]
SQLState = IM002
Native = 0xbfc99740 -> 0
Message Text = [[unixODBC][Driver Manager]Data source name not
found, and no default driver specified]

That was basically the same error I got in PyODBC.

But ODBC works from all other tools, like:

$ odbcinst -q -s
[gupta1]

$ odbcinst -j
unixODBC 2.2.11
DRIVERS............: /etc/odbcinst.ini
SYSTEM DATA SOURCES: /etc/odbc.ini
USER DATA SOURCES..: /home/marius/.odbc.ini

$ odbcinst -q -d
[Gupta SQLBase]

$ cat /etc/odbcinst.ini
[Gupta SQLBase]
Driver = /tmp/gupta/libsqlbaseodbc.so
Setup = /tmp/gupta/libsqlbaseodbcsetup.so

[ODBC]
Trace = yes
TraceFile = /tmp/sql.log

$ cat /etc/odbc.ini
[gupta1]
Driver=/tmp/gupta/libsqlbaseodbc.so
Description=Gupta SQLBase DSN
DSN=gupta1
Servername=server1
LoginID=SYSADM
Username=SYSADM
Password=SYSADM
Database=RB3
ini=/tmp/gupta/sql.ini
InputMessageSize=2000
IsoLevel=Release Locks
LockTimeOut=300

$ cat .odbc.ini
[gupta1]
Driver=/tmp/gupta/libsqlbaseodbc.so
Description=Gupta SQLBase DSN
DSN=gupta1
Servername=server1
LoginID=SYSADM
Username=SYSADM
Password=SYSADM
Database=RB3
ini=/tmp/gupta/sql.ini
InputMessageSize=2000
IsoLevel=Release Locks
LockTimeOut=300

- Marius

[mkleehammer]

On Dec 8, 7:03 am, mfl...@gmail.com wrote:
> On Dec 6, 5:15 pm, mkleehammer <mkleeham...@gmail.com> wrote:
>
> > Can you turn on ODBC tracing and make the connection with Perl and
> > then pyodbc so I can compare?
>
> Hm. I've tried turning on the tracing, but I believe that reports back
> the same issues as pyodbc did:

I'm not exactly sure what you mean here. I was hoping you could turn
on tracing, then connect successfully with PHP (though I wrote Perl
earlier, my mistake) and then trace the failure using pyodbc. Then I
would compare the two traces.

1) What does the trace you have submitted represent? That is, what
did you do when tracing was turned on?

2) What do you mean "same issues as pyodbc"? Do you mean that the PHP
program also fails if you have tracing turned on?

[mfl...@gmail.com]

On Dec 9, 1:14 am, mkleehammer <mkleeham...@gmail.com> wrote:

> I'm not exactly sure what you mean here.  I was hoping you could turn
> on tracing, then connect successfully with PHP (though I wrote Perl
> earlier, my mistake) and then trace the failure using pyodbc.  Then I
> would compare the two traces.

Yeah, so that's why you got the trace when I tried connecting through
Perl ;) And connecting through Perl has exactly the same issues/
implications as trying to connect through Python.

> 1) What does the trace you have submitted represent?  That is, what
> did you do when tracing was turned on?

Connecting from Perl.

> 2) What do you mean "same issues as pyodbc"?  Do you mean that the PHP
> program also fails if you have tracing turned on?

When connecting from Perl I get the exact same error as trying to
connect through Python :)

This is the trace when I try to connect through PHP:

[ODBC][14479][__handles.c][444]
Exit:[SQL_SUCCESS]
Environment = 0xb92932d0
[ODBC][14479][SQLAllocHandle.c][345]

Entry:
Handle Type = 2

Input Handle = 0xb92932d0
[ODBC][14479][SQLAllocHandle.c][463]
Exit:[SQL_SUCCESS]
Output Handle = 0xb90fa738
[ODBC][14479][SQLConnect.c][3549]
Entry:
Connection = 0xb90fa738
Server Name = [gupta1][length = 6 (SQL_NTS)]
User Name = [SYSADM][length = 6 (SQL_NTS)]
Authentication = [******][length = 6 (SQL_NTS)]

UNICODE Using encoding ASCII 'ISO8859-1' and UNICODE 'UCS-2LE'

[ODBC][14479][SQLConnect.c][4123]
Exit:[SQL_SUCCESS]
[ODBC][14479][SQLDisconnect.c][204]
Entry:
Connection = 0xb90fa738
[ODBC][14479][SQLDisconnect.c][341]
Exit:[SQL_SUCCESS]
[ODBC][14479][SQLFreeHandle.c][268]

Entry:
Handle Type = 2

Input Handle = 0xb90fa738
[ODBC][14479][SQLFreeHandle.c][317]
Exit:[SQL_SUCCESS]
[ODBC][14479][SQLFreeHandle.c][203]

Entry:
Handle Type = 1

Input Handle = 0xb92932d0

This is just issuing an odbc_connect("gupta1", "SYSADM", "SYSADM") and
then a odbc_close(). And it works just perfectly.

- Marius

[mfl...@gmail.com]

*bump*

Could you help me out here?

Since I haven't been able to resolve this problem, I've had to use PHP
to do my work, which I'm quite frankly is a bit uncomfortable with. I
want my Python! :)

To summarize:

It works using PHP's built-in odbc_connect(), but not with either
Python or Perl.