On Thu, Jul 26, 2012 at 12:35 PM, Torsten Bergmann <[email protected]> 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. > >
