[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
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