[Gambas-devel] gb.odbc probably won't work correctly

danielcampos at ...45... danielcampos at ...45...
Fri Oct 14 01:51:45 CEST 2005

>At the moment, the behaviour of gb.db is the following:
>- If the query_init() driver function returns a row count >= 0, then this 
>value is used for testing the row index when extracting a row.
>- If query_init() returns a count of -1, then no test is done, and the 
>query_fill() driver function can get any value in its pos argument.
>This behaviour is not a problem, if there wasn't the second one you >describe 
>after (that I wasn't aware of)...

OK, then it seems I mixed both errors in my test and I didn't notice that the first one could be solved by gb.db... I'll try tomorrow...

>FetchScroll() exists from ODBC 3.0. ODBC seems to be as well designed as >the 
>SQL pseudo-standard... :-(
>It seems that Andrea replaced the use of Fetch() by FetchScroll(). I don't 
>know why, if he could explain us?
>Anyway, if there is no way to move to any row in the result set, and if >there 
>is no way to rewind the recordset to its beginning, then the driver must 
>raise an error.
>What to do?
>1) Find a function to get the ODBC version implemented by the ODBC >driver.

I think it is possible...

>2) If ODBC >= 3.0, then use FetchScroll(). Otherwise raise an error when >this 
>function must be called.

I'll try to do it

>If we need one ODBC gambas driver for each database system, then ODBC >is 

In fact IBM offers their own ODBC implementation with non-standard functions (ClientSDK). However It is not free at all...

>But it will be cool if you can do in gb.db.odbc what I described just before: 
>getting ODBC version implemented by the underlying driver, and raise an >error 
>if FetchScroll() is impossible.
> However, I think something more  clean should be done with that, may be a
> complete component for ODBC with a different interface, or modify the
> current gb.db component so it can handle drivers having not row 

I'll try to mix all code, I'll tell you more

>Anyway, I continue thinking that:
>- ODBC is a pain.


>- Direct drivers are better. After all, almost all databases are doing about 
>the same things, and SQL is absolutely not standard.

But big databases does not offer a free SDK, and I do not want to compile Gambas code with propietary code. Too hard to mantain even if there's not legal problems. 

>- ODBTP is a good and more efficient way to use ODBC from a Linux box: 

I'll try it


Daniel Campos 

NetCourrier, votre bureau virtuel sur Internet : Mail, Agenda, Clubs, Toolbar...
Web/Wap : www.netcourrier.com
Téléphone/Fax : 08 92 69 00 21 (0,34 € TTC/min)
Minitel: 3615 NETCOURRIER (0,16 € TTC/min)

More information about the Devel mailing list