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
