Re: ODBC C API question(s)

Martin,

Strangely enough, I could only get this to work:

function_result= SQLDriverConnect(dbc, (void *)1, "DSN=myodbc3patg", 
SQL_NTS,
    NULL, 0, NULL, SQL_DRIVER_COMPLETE);


 If I made the 2nd arguement either "NULL" or "(void*) NULL" or "(void 
*)0", it would not connect, and I would get:


[unixODBC][MySQL][ODBC 3.51 Driver]Invalid window handle for connection 
completion argument. (0)

In regards to the other question you had, I am wondering if one provides 
all the connection parameters requires in the connect string, can one 
omit a DSN? I'm trying to determine what parameters one passes. Obviously:

UID
Password
Driver
Server
Database
Port
Socket
Option

Can all of these be specified on connect? If one provides say a 
different password or port than what the DSN they specify uses, does 
that 'override' what the DSN defines? Is the DSN essentially a 
'convenience' string?

Sorry if my questions are daft! The only DSNs I've dealt with before are 
with DBD::mysql.

Thanks for your response!

Patrick


Martin Evans wrote:

> Venu Anuganti wrote:
>
>> 1. There is no direct equivalent for the mysql_fetch_lengths; But you 
>> could use SQLDescribeCol or SQLColAttribute(s) with 
>> SQL_ATTR_DESC_LENGTH to get column length. But you need to iterate 
>> through all fields like..
>>
>> SQLExecDirect("select..");
>> SQLNumResultCols(&colCount);
>>
>> for (i=1; i <= colCount; i++) {
>>    SQLColAttribute(colCount, SQL_ATTR_DESC_LENGTH)..
>> }
>>
>> PS: its not a real example; but it is just a psedo code.
>>
>> 2. SQLDriverConnect has wrong usage; either you need to have valid 
>> window handle; else pass NULL for parameter 2.
>>
>> 3. UIDs/PWDs are optional. If you provide it overwrites the DSN 
>> UID/PWD. MySQL allows to store UID/PWD in DSN but few databases will 
>> not allow to store PWD due to security; For example; Oracle will not 
>> let you specify PWD in DSN.
>
>
> Oracle might not let you store the PWD but quite a few drivers do 
> (most encrypt the PWD some way). Just to add to what Venu said; the 
> basic mechanics an ODBC driver should go through are:
>
> 1. pull all attributes out of the connection string
> 2. if there are not enough attributes defined to allow the driver to 
> connect look for a DSN attribute (or FileDSN).
> 3. if the DSN attribute is found, pull any missing attributes from the 
> DSN (which effectively means calling SQLGetPrivateProfileString).
> 4. if there are now enough attributes defined to connect, connect, 
> else if a window handle is supplied, pop up a dialogue to get the 
> remaining attributes.
>
> Of course the last argument to SQLDriverConnect affects all this as it 
> may be SQL_DRIVER_COMPLETE (fill in the missing attributes from the 
> DSN), SQL_DRIVER_PROMPT (always throw up the dialogue) and 
> SQL_DRIVER_NOPROMPT (never throw up the dialogue, so if insufficient 
> attributes to connect it would be an error). Its actually a bit more 
> complex than this but it is all described under SQLDriverConnect in 
> the ODBC API.
>
> Regarding the window handle issue, Venu is right - it should be NULL 
> or a valid Window handle but this sort of goes out the window (pardon 
> the pun) on UNIX when there is not really any such thing as a valid 
> window handle. If you are using the unixODBC driver manager (which 
> uses QT for the GUI by default) you might indeed pass 1 for the window 
> handle to indicate to the driver that if it does support a GUI 
> interface, it can use it (but the driver does not actually use the 1 
> as a window handle, it uses something like QApp (can't remember off 
> the top of my head)). The Easysoft ODBC-ODBC Bridge can do this on 
> Linux where QT is installed and you have the right libstdc++ but it is 
> pretty difficult to do on other platforms due to libstdc++ issues and 
> the way unixODBC/QT are built and in any case the app using the driver 
> has to be a QT app.
>
>
>> 4. For complete ODBC; check:
>>
>> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/odbc/htm/dasdkodbcoverview.asp 
>>
>> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/odbc/htm/odbcabout_this_manual.asp 
>>
>>
>>
>> Patrick Galbraith wrote:
>>
>>> Hi all,
>>>
>>> I have been using the MySQL client API for quite some time now and 
>>> am in the middle of utilising ODBC C API for a current project. I'm 
>>> wondering if there is an equivalent call in ODBC for 
>>> 'mysql_fetch_lengths' ?
>>>
>>> Also, I am wondering what the difference is between
>>>
>>>
>>> SQLDriverConnect(dbc, (void *)1, "DSN=myodbc3patg", SQL_NTS,
>>>       outstr, sizeof(outstr), &outstrlen,
>>>             SQL_DRIVER_COMPLETE);
>>>
>>> This fails, and I don't know why.
>>>
>>>
>>> But this works:
>>>
>>> SQLConnect(V_OD_hdbc, (SQLCHAR*) "myodbc3patg", SQL_NTS,
>>>  (SQLCHAR*) "", SQL_NTS,
>>>  (SQLCHAR*) "", SQL_NTS);
>>>
>>> What is the difference between the two? Is there any 
>>> benefit/detriment to either? The first snippet is from Easysoft's 
>>> site, the second from the tutorial on UNIX odbc.
>>
>
> I have explained the "(void *)1" above but in the example on our site 
> for the tutorial it is not required and has confused you (I have asked 
> for it to be changed to NULL).
>
> I'd always use SQLDriverConnect over SQLConnect because it is a lot 
> more flexible and the driver manager will map it to SQLConnect for 
> REALLY OLD drivers that don't support SQLDriverConnect anyway.
>
>>> I often see that people use a UID/Password with  ODBC  DSN. Why use 
>>> a password and also a DSN? I thought the DSN provides that? If one 
>>> uses a DSN with UID/Pass, does the UID/Password for the DSN get 
>>> over-written?
>>>
>>> Also, where are some good sites for the ODBC C API, with examples, 
>>> descriptions of the API calls? I have found info at Easysoft's 
>>> website as well as UnixODBC website. It seems that so much ODBC 
>>> programming is targeted for GUIs. Mine is all system-level that I 
>>> want to accomplish.
>>>
>>> Kind regards, thanks in advance!
>>>
>>> Patrick
>>>
>>
>
> If you find areas not covered on our site that you think would be 
> useful let me know and I'll attempt to get any holes filled in.
>
> The strange thing is that many of our customers use ODBC in GUI 
> environments (mostly Windows) and yet much of my use of ODBC has been 
> on UNIX and from system tools or web servers. Being a lover of Perl 
> I'd much sooner write in Perl than in C with the ODBC API but for 
> speed the latter wins hands down in /a few/ circumstances (e.g. you 
> can set the SQL_ATTR_ARRAY_SIZE attribute and fetch 1000's of rows in 
> one go, which you can't do with DBD::ODBC and you can use cursors to 
> move around a result-set which DBD::ODBC does not do - I hope Tim does 
> not read this or I'll be getting a why don't you add support email 
> (and I've got my excuses ready in case he does).
>
> Martin



-- 
Patrick Galbraith, Senior Programmer 
Grazr - Easy feed grazing and sharing
http://www.grazr.com 

Satyam Eva Jayate - Truth Alone Triumphs
Mundaka Upanishad




-- 
MySQL ODBC Mailing List
For list archives: http://lists.mysql.com/myodbc
To unsubscribe:    http://lists.mysql.com/[email protected]