[Gambas-user] [Gambas Bug Tracker] Bug #1113: ODBC driver problem: driver connects but does not exec query

Cristiano Guadagnino criguada at ...626...
Wed Jun 21 15:41:35 CEST 2017


This is in no way "bad behavior of the ODBC and SQL standard", nor a
problem of Microsoft. It is standard practice (I have encountered it in ALL
the dbms with which I have been working through the years) that when a SQL
query returns no data the engine return a SQLCODE 100.
Negative SQLCODES always mean some kind of error has happened. Positive
SQLCODES are warnings.
SQLCODE 100 is one such warning, and rightly so. It means: your query has
returned no data. It there was no such warning, who could know if the query
returned no data because there's no data to be returned or because, for
example, you lost connectivity mid-way through the query?
So, SQLCODE 100 is a perfectly legal return code and should be treated as
success, at least if the program logic admits that there could be no data
to return.

Cris



On Wed, Jun 21, 2017 at 4:36 AM, <bugtracker at ...3416...> wrote:

> http://gambaswiki.org/bugtracker/edit?object=BUG.1113&from=L21haW4-
>
> Comment #13 by PICCORO LENZ MCKAY:
>
> i think your patch are not so "ugly" due relies on the bad behaviour of
> the ODBC and SQL standar, i mean umm jajaja its very confusing that the
> ODBC paper said after a "susessfull sql ddl" return SQL_NO_DATA event
> SQL_SUCCESS, but with M$ behind scenes.. no surprises..
>
> analizing, if the SQL running was successfully and its no a SQL DML must
> retrieve as response SQL_SUCCESS, the problem maybe are on that cases:
>
> UPDATE, DELETE and INSERT does not retrieve any rows, only notifies was
> afected rows.. so return a SQL_NO_DATA, but are DML, so the only case that
> return data its the SELECT case... so we can assume that any other
> statement will no return never some data.. only "affected rows" so for any
> SQL query made, we can assumed SQL_SUCCESS if no problem was happened.. the
> only exception will be SELECT and for those are not usefully due we not
> have proper CURSOR, only a FORWARD ONLY cursor...
>
> due that explanation, i think the only you can do its to assume that
> behaviour of the "ugly patch", so or SQL_SUCCESS or not...
>
>
> as a informative for others, SQL querys can be divided into two parts: The
> Data Manipulation Language (DML) querys and the Data Definition Language
> (DDL) querys
>
> CAUTION: in the stupid mysql and sqlite, the ALTER query has a "afected
> rows" behavior due some info are stored on tables...
>
> EXAMPLES OF SQL DML:
>
> SELECT – this retriebve data always or not
> UPDATE – not retrieve data, only "affected rows"
> DELETE – not retrieve data, only "affected rows"
> INSERT INTO – not retrieve data, only "affected rows"
>
> EXAMPLES OF SQL DDL:
>
> CREATE DATABASE – no any data, only "succesfull or not"
> ALTER DATABASE – no any data, only "succesfull or not"
> CREATE TABLE – no any data, only "succesfull or not"
> ALTER TABLE – no any data, only "succesfull or not"
> DROP TABLE – no any data, only "succesfull or not"
> CREATE INDEX – crea un índice.
> DROP INDEX – borra un índice.
>
> PICCORO LENZ MCKAY changed the state of the bug to: Accepted.
>
>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Gambas-user mailing list
> Gambas-user at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gambas-user
>



More information about the User mailing list