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

[danielcampos at ...45...]

>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 
>useless!
>

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.

Yes

>- 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: 
>http://odbtp.sourceforge.net

I'll try it

Regards,

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)