Smalltalk › Pharo › Pharo Smalltalk Developers

ODBC on W7 and Pharo 1.4

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

3 messages Options

Torsten Bergmann

ODBC on W7 and Pharo 1.4

>But it does not declare anything which is needed e.g for
>understanding SQLDouble and the like.

Because FFI is a general callout mechanism for native APIs
and the ODBC package is just implemented on top of it.

So why should the FFI docu cover the ODBC stuff?
FFI docu just describes how to call external libs (written in C or
others).

The ODBC package is nothing more than a wrapper around
some Win32 API functions like SQLAllocEnv, etc. The docu
for them can be found in MSDN (just Google).

If you want to track problems in the ODBC package
check the code and see if it does correct callouts
and use correct data types according to Microsoft specs.

Just by looking at the code, maybe
- #initializeDataTypes has a wrong definition
- maybe the ODBCConstants definition is wrong
- maybe #initializeResultSet:number: has a problem

You should debug your problem since you have a reproducable case
or switch to a newer, more supported package like DBXTalk with
an active mailinglist.

>Sorry, does that mean the name I gave to the Data source must be placed
>in host?

Yes, that worked for me. "host" is a bit misleading - for an
SQLite connection it can be the local path, for ODBC its the DSN name
for a network database it is the hostname or IP address.

>I'm sorry but how should one know that?

Note that is a general interface to databases. You can not
assume that the developers of OpenDBX/DBXTalk test any kind
of database (here MS Access) and give you a docu for database
specific connections.

DBXTalk covers typical relational databases used in enterprise these
days (oracle, MSSQL, MySQL, ...), includes tests
and its nice to have such an initiative.

>So what am I supposed to write into database? A table name?

Did you try to leave it blank or use the same name as the DB?

If I were you I would create a simple DB with Access with a
simple predefined table. Then setup the ODBC connection and
try to connect to it. If that works do a simple query.
If that communication works it should be no problem to
create/query tables from Smalltalk. However - if you have
DBXTalk specific questions switch to the DBXTalk mailinglist

(http://dbxtalk.smallworks.com.ar then "Support")

Bye
T.

Guillermo Polito

Re: ODBC on W7 and Pharo 1.4

On Thu, Jul 26, 2012 at 12:35 PM, Torsten Bergmann <[hidden email]> wrote:

>But it does not declare anything which is needed e.g for
>understanding SQLDouble and the like.

Because FFI is a general callout mechanism for native APIs
and the ODBC package is just implemented on top of it.

So why should the FFI docu cover the ODBC stuff?
FFI docu just describes how to call external libs (written in C or
others).

The ODBC package is nothing more than a wrapper around
some Win32 API functions like SQLAllocEnv, etc. The docu
for them can be found in MSDN (just Google).

If you want to track problems in the ODBC package
check the code and see if it does correct callouts
and use correct data types according to Microsoft specs.

Just by looking at the code, maybe
- #initializeDataTypes has a wrong definition
- maybe the ODBCConstants definition is wrong
- maybe #initializeResultSet:number: has a problem

You should debug your problem since you have a reproducable case
or switch to a newer, more supported package like DBXTalk with
an active mailinglist.

>Sorry, does that mean the name I gave to the Data source must be placed
>in host?

Yes, that worked for me. "host" is a bit misleading - for an
SQLite connection it can be the local path, for ODBC its the DSN name
for a network database it is the hostname or IP address.

Yes! I know it is misleading, the thing is we've made only one common protocol for every database. Specific methods to be more friendly to special cases like SQLite ODBC are maybe a good idea, isn't it? :^)

>I'm sorry but how should one know that?

Note that is a general interface to databases. You can not
assume that the developers of OpenDBX/DBXTalk test any kind
of database (here MS Access) and give you a docu for database
specific connections.

DBXTalk covers typical relational databases used in enterprise these
days (oracle, MSSQL, MySQL, ...), includes tests
and its nice to have such an initiative.

Yeap, the normal cases are covered in the docs in the website. For specific stuff I recommend you to have a look at the tests...

>So what am I supposed to write into database? A table name?

Did you try to leave it blank or use the same name as the DB?

If I were you I would create a simple DB with Access with a
simple predefined table. Then setup the ODBC connection and
try to connect to it. If that works do a simple query.
If that communication works it should be no problem to
create/query tables from Smalltalk. However - if you have
DBXTalk specific questions switch to the DBXTalk mailinglist

(http://dbxtalk.smallworks.com.ar then "Support")

Yeap, you're welcome to subscribe :).

Then again, if you want to have a look at some DBX examples, you can have a look at the tests. In particular, a connection example to a MSSQL database over ODBC can be found in

DBXOdbcMSSQLFacility>>createConnection

in the package OpenDBXDriverTests. It looks like:

DBXConnectionSettings host: 'MSSQL' port: '3004' database: 'sodbxtest' userName: 'crapodino' userPassword: 'florynano'.

I really don't know how this will behave with Access (I don't have access installed either :/). If you can give it a try and provide us any idea we can put it into the tests/website :).

Bye
T.

FDominicus

Re: ODBC on W7 and Pharo 1.4

In reply to this post by Torsten Bergmann

"Torsten Bergmann" <[hidden email]> writes:

>>But it does not declare anything which is needed e.g for
>>understanding SQLDouble and the like.
>
> Because FFI is a general callout mechanism for native APIs
> and the ODBC package is just implemented on top of it.
You are right, but it does not declare the handling of pointer
or I have not understand it.
> Just by looking at the code, maybe
> - #initializeDataTypes has a wrong definition
> - maybe the ODBCConstants definition is wrong
> - maybe #initializeResultSet:number: has a problem
Well I did exactly what you suggested and the problem is very likely in
here:
checkSQLReturn: (ODBCLibrary default
sqlDescribeCol: resultSetHandle
columnNumber: number
columnName: columnName
bufferLength: BUFFERSIZE
nameLength: nameLenght
dataType: columDataType
columnSize: columnSize
decimalDigits: decimalDigits
nullable: columnNullable)

The problem here is that columnSize gives 53 with Access 2003.
and this surely is wrong it may even be a problem in Access for ages
because I found a hotfix for it for Access 2007
http://www.everythingaccess.com/tutorials.asp?ID=The-lowdown-on-Access-2007

I guess this may explain my problem. Anyway I'm not sure about it.

So to me it seems this is a problem in the ODBC Driver vor Access, but I
could not imagine that no-one ever have treated Doubles while trying to
access MS Access with Pharo.

>
>>Sorry, does that mean the name I gave to the Data source must be placed
>>in host?
>
> Yes, that worked for me. "host" is a bit misleading - for an
> SQLite connection it can be the local path, for ODBC its the DSN name
> for a network database it is the hostname or IP address.
Sorry having a Database name in host is all but obvious.

Regards
Friedrich