[ODBC][MyODBC] SQLSetConnectAttr ValuePtr

[Verwijderd]

Ik heb een vraag over SQLSetConnectAttr i.c.m. SQL_ATTR_CONNECTION_TIMEOUT.

code:

SQLRETURN SQLSetConnectAttr
(
    SQLHDBC ConnectionHandle,
    SQLINTEGER   Attribute,
    SQLPOINTER   ValuePtr,
    SQLINTEGER   StringLength
);

An SQLUINTEGER value corresponding to the number of seconds to wait for any request on the connection to complete before returning to the application
(...)
If ValuePtr is equal to 0 (the default), then there is no timeout.

Ik gebruik MyODBC (v3.51.xxx).

Bij de aanroep van deze functie kan je zoals hierboven lezen dat je als parameter ValuePtr een 32-bits integer kan opgeven met de timeout in seconden. Echter, wanneer ik dit doe krijg ik bij de aanroep van SQLDriverConnect een Memory Access Violation.

Geef ik echter als ValuePtr een pointer naar een 32-bits integer op dan krijg ik geen foutmelding (maar of dat ook daadwerkelijk die timeout gekozen wordt weet ik niet).

Kan ik hieruit concluderen dat niet ValuePtr de timeout moet bevatten maar *ValuePtr? Want dat hadden ze er dan wel even bij mogen zetten...

[Orphix]

Geen idee, maar je zegt dat je niet weet of die time-out dan werkt .. kan je niet gewoone een hele kleine time-out opgeven?

[Verwijderd]

Op zaterdag 23 februari 2002 15:13 schreef Orphix het volgende:
Geen idee, maar je zegt dat je niet weet of die time-out dan werkt .. kan je niet gewoone een hele kleine time-out opgeven?

De kleinste timeout die je op kan geven is 1 seconde. Lokaal met MS-SQLServer en Mysql zit ik daar ver onder. Ik kan eventueel verbinding proberen te maken met een Mysql database op internet, maar ook daar zal ik onder de 1 seconde zitten (hoewel, ik zou een grote download kunnen starten; dan zou ik daarboven kunnen komen).

Dat zal ik eens proberen.

Ik heb nog een vraag:

Als ik

code:

SQLExecDirect(hStmt, "UNLOCK TABLES", SQL_NTS);

uitvoer dan krijg ik een function sequence error (terwijl er een sucessvolle lock table xxx write aan vooraf gegaan is).

Als iemand daar nog een verklaring voor heeft?

[Verwijderd]

Net even geprobeerd: de timeout is niet ingesteld (ondanks een sucessvolle aanroep van SetConnectAttr [SQL_SUCCESS]).

Geef ik n.m.l. bij hoge bandbreedte een geldige mysql server op dan krijg ik na een seconde of vijf gewoon verbinding (terwijl de timeout op 1 seconde staat) en wanneer ik een ongeldige host (1.1.1.1) opgeef dan krijg ik na zo'n 30 seconden SQL_ERROR van SQLDriverConnect.

Ofwel:
1) Mijn aanroep van SetTimeout is niet correct (most likely)
2) MyODBC ondersteunt geen customizable timeouts (maar dat zou in tegenspraak zijn ten opzichte van de myodbc manual op [http://www.mysql.com/products/myodbc/manual.html]).

dus... wat nu?

Nu zijn die timeouts niet zo cruciaal, maar toch zou ik ze er graag in hebben.

En is er iemand die iets over de unlock tables kan zeggen? Want een function sequence error betekend dat op zich de query wel goedgekeurt is maar dat er iets aan vooraf moet zijn gegaan maar wat? (op een lock tables na dan).

[Verwijderd]

Ik heb even een SQL trace gestart (24+ MB...) en dit zijn een aantal interessante entries:

SQLSetConnectAttr with return code 0 (SQL_SUCCESS)
SQLINTEGER 113 <SQL_ATTR_CONNECTION_TIMEOUT>
SQLPOINTER 0x00FAFE5C (10)
SQLINTEGER -5

SQLSetConnectAttr with return code 0 (SQL_SUCCESS)
SQLINTEGER 103 <SQL_ATTR_LOGIN_TIMEOUT>
SQLPOINTER 0x00FAFE5C (10)
SQLINTEGER -5

SQLDriverConnectW with return code 1 (SQL_SUCCESS_WITH_INFO)

DIAG [IM006] [Microsoft][ODBC-stuurprogrammabeheer] SQLSetConnectAttr van het stuurprogramma is mislukt (0)

DIAG [IM006] [Microsoft][ODBC-stuurprogrammabeheer] SQLSetConnectAttr van het stuurprogramma is mislukt (0)

en:

SQLExecDirect with return code 0 (SQL_SUCCESS)
"LOCK TABLES deTabel WRITE"
SDWORD 28

...

SQLExecDirect with return code -1 (SQL_ERROR)
"UNLOCK TABLES"
SDWORD 13

DIAG [HY010] [Microsoft][ODBC-stuurprogrammabeheer] Fout in functievolgorde (0)

En zo te zien gaan er bovendien nog meer SQLSet###Attr's fout. Maar wat is er dan fout aan bijvoorbeeld de volgende code:

code:

SQLUINTEGER     timeout;

timeout = 10; /* seconds */

SQLSetConnectAttr((SQLHDBC) *lphConnect, SQL_ATTR_CONNECTION_TIMEOUT, (SQLPOINTER) &timeout, SQL_IS_UINTEGER);
SQLSetConnectAttr((SQLHDBC) *lphConnect, SQL_ATTR_LOGIN_TIMEOUT,    (SQLPOINTER) &timeout, SQL_IS_UINTEGER);
SQLSetConnectAttr((SQLHDBC) *lphConnect, SQL_ATTR_ODBC_CURSORS,  (SQLPOINTER) NULL, SQL_CUR_USE_IF_NEEDED);
SQLSetConnectAttr((SQLHDBC) *lphConnect, SQL_ATTR_QUIET_MODE,      (SQLPOINTER) NULL, 0);
SQLSetConnectAttr((SQLHDBC) *lphConnect, SQL_AUTOCOMMIT,          (SQLPOINTER) NULL, SQL_AUTOCOMMIT_OFF);

...

SQLSetStmtAttr((SQLHSTMT) *lphStatement, SQL_ATTR_CURSOR_SCROLLABLE, (SQLPOINTER) SQL_NONSCROLLABLE,     0);
SQLSetStmtAttr((SQLHSTMT) *lphStatement, SQL_ATTR_CURSOR_TYPE,   (SQLPOINTER) SQL_CURSOR_FORWARD_ONLY, 0);
SQLSetStmtAttr((SQLHSTMT) *lphStatement, SQL_ATTR_NOSCAN,       (SQLPOINTER) SQL_NOSCAN_ON,      0);
SQLSetStmtAttr((SQLHSTMT) *lphStatement, SQL_ATTR_QUERY_TIMEOUT,     (SQLPOINTER) (SQLUINTEGER) 20,   0);

Uiteraard zijn het geldige pointers.