ODBC C API question(s)

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

--
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/myodbc?unsub=gcdmo-myodbc@m.gmane.org

Re: ODBC C API question(s)

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.

4. For complete ODBC; check:

http://msdn.microsoft.com/library/default.asp?url=/library/e n-us/odbc/htm/dasdkodbcoverview.asp
http://msdn.microsoft.com/library/default.asp?url=/library/e n-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 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
>

--
MySQL ODBC Mailing List
For list archives: http://lists.mysql.com/myodbc
To unsubscribe: http://lists.mysql.com/myodbc?unsub=gcdmo-myodbc@m.gmane.org

Re: ODBC C API question(s)

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/e n-us/odbc/htm/dasdkodbcoverview.asp
>
> http://msdn.microsoft.com/library/default.asp?url=/library/e n-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
--
Martin J. Evans
Easysoft Limited
http://www.easysoft.com

--
MySQL ODBC Mailing List
For list archives: http://lists.mysql.com/myodbc
To unsubscribe: http://lists.mysql.com/myodbc?unsub=gcdmo-myodbc@m.gmane.org

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/e n-us/odbc/htm/dasdkodbcoverview.asp
>>
>> http://msdn.microsoft.com/library/default.asp?url=/library/e n-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/myodbc?unsub=gcdmo-myodbc@m.gmane.org

Re: ODBC C API question(s)

Patrick Galbraith wrote:
> 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)

Ok, now I know you are on unix (from the error) and mysql let's see how
we can interpret this as it is somewhat vague in the spec.

SQL_DRIVER_COMPLETE/SQL_DRIVER_COMPLETE_REQUIRED
If the connection string contains enough information and it is correct
the driver connects and copies the in connection string to the out
connection string. If any information is missing or incorrect the driver
takes the same action as when SQL_DRIVER_PROMPT is set except that if
SQL_DRIVER_COMPLETE_REQUIRED is used, the driver disables the controls
for any information not required.

SQL_DRIVER_PROMPT
The driver displays a dialogue box using the values from the connection
string and any system information (DSN) as initial values. When the
dialogue is exited it connects. The out connection string is created
from the value of the DSN/DRIVER keywords in the in connection string
and the information returned in the dialogue.

SQL_DRIVER_NO_PROMPT
Connects if it can, never throws a dialogue and errors if it can't
connect with what it has. If it connects in connection string is copied
to out connection string.

What this does not tell us what error is returned but looking at what
SQLDriverConnect can return the only option is "IM008 Dialog Failed"
(WindowHandle was NULL and DriverCompletion was not SQL_DRIVER_NO_PROMPT.

So it looks as though myodbc has almost done what is required except
that if SQLDriverConnect(handle, (void *)1,...) works without throwing a
dialogue and SQLDriverConnect(handle, (void *)0,...) does not work with
the same in connection string something is broken.

What I've seen other drivers do on UNIX which I think is more sensible
is that if the driver was built such that it is not capable of throwing
a dialogue (e.g. if not built with a GUI lib) then when
SQL_DRIVER_COMPLETE and SQL_DRIVER_COMPLETE_REQUIRED is specified and
there is not sufficient information to connect they return an error
stating they are not capable of displaying a dialogue not because you've
set WindowHandle to NULL but because they couldn't anyway. If the driver
IS capable of throwing a dialogue (i.e. built with a GUI lib) and there
is insufficient information to connect and
SQL_DRIVER_COMPLETE/SQL_DRIVER_COMPLETE_REQUIRED is specified and the
WindowHandle is NULL then you get the error myodbc is giving you now.

The basis of this is it is rather stupid to claim I can't do what you
ask because you did not pass me a window handle when even if you had
given a window handle the driver is not capable of displaying a dialogue.

So, I suggest something is amiss with myodbc because:

1. if the connection string is sufficient to connect, specifying a
window handle or not should make no difference when using
SQL_DRIVER_PROMPT or SQL_DRIVER_PROMPT_REQUIRED.

2. saying invalid window handle if you don't have code to display a
dialogue is misleading.

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

yes, that is called surprisingly a "DSN-less" connection string and you
create one by adding a Driver={xxx} to the connection string and then
the other attributes.

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

Depends on the driver but generally speaking anything that can be
specified in the DSN should also be supported as a connection string
attribute - I'd actually argue a bug in the driver if that was not the
case. So for the above I'd expect to be able to use the connection string:

DRIVER={name_of_myodbc_driver};UID=x;PWD=y;Server=z;Database =a;Port=p;Socket=s;Option=o;

where (on UNIX) you'd get the driver name from the odbcinst.ini file
defining that driver. This circumvents the normal process the driver
manager (DM) uses to locate the driver which is:

connection string: DSN=fred
DM looks up fred DSN in odbc.ini file and obtains Driver attribute
Takes Driver name and looks it up in odbcinst.ini to find the path to
the actual driver
Loads the driver
Passes the connection string to the driver's SQLDriverConnect
Now the driver is in control.

If DSN is omitted the DM needs some way to locate the driver; that is
the Driver attribute.

There is FileDSN as well which is like DSN but points to a file
containing a list of attribute value pairs for a single connection e.g.

attr1 = value
attr2 = value

instead of what you'd seen in the odbc.ini which defines multiple DSNs as:

[dsn1]
attr1 = value
attr2 = value

[dsn2]
attr1 = value
attr2 = value

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

It should override the DSN.

Perhaps I did not explain it too well. The driver first pulls all the
attributes out the connection string. If there is a DSN named, it can
use SQLGetPrivateProfileString to read any not already specified
attributes from the DSN. As such, if you specify a UID/PWD in the
connection string they should cause the driver to omit those entries in
the DSN. However, as you've identified, myodbc uses Password in the DSN
so it should logically map this to PWD in ODBC terms so Password in the
DSN would be ignored if PWD was specified in the connection string
(unless Password was not the password to connect to the database but
some other attribute).

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

No problem.

Did you look at:

http://www.easysoft.com/developer/interfaces/odbc/linux.html

it has some useful stuff and

http://www.easysoft.com/products/data_access/odbc_odbc_bridg e/manual/connection.html#850417

contains a description of the connection process in ODBC with a specific
leaning towards the Easysoft ODBC-ODBC Bridge (I'm sure I wrote a better
one somewhere but I can't find it right now).

Good Luck.

Martin
--
Martin J. Evans
Easysoft Limited, UK
http://www.easysoft.com

> 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/e n-us/odbc/htm/dasdkodbcoverview.asp
>>>
>>> http://msdn.microsoft.com/library/default.asp?url=/library/e n-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
>
>
>

--
MySQL ODBC Mailing List
For list archives: http://lists.mysql.com/myodbc
To unsubscribe: http://lists.mysql.com/myodbc?unsub=gcdmo-myodbc@m.gmane.org