unixODBC-CPP

[Peter Harvey]

FYI

Both unixODBC-Test and unixODBC-GUI-Qt could use more of my time but I
need to move on (at least for this pass). I have renamed ODBC++ to
unixODBC-CPP and I will replace the contents of this project with
unixODBC-GUI-Qt::Wrappers::CPP. This is a merge of sorts.

Nick could you add the following to unixodbc.org...

unixODBC-CPP
============

This project is a very thin C++ wrapper for ODBC. This is most useful
for those who know something about the ODBC API but want a;

- friendlier interface for C++ (traditional calls or those with
compressed arg list for example)
- friendlier interface for modern IDE's (better code completion for example)
- no features hidden

Download
-------------

The project is hosted at SourceForge as follows;
Project Descriptive Name: unixODBC-CPP
Project Unix Name: odbc-class-lib
CVS Server: odbc-class-lib.cvs.sourceforge.net
Web Server: odbc-class-lib.sourceforge.net

Source and binary distributions will be made available from
time-to-time. Get the latest sources from cvs if you want the 'bleeding
edge'. Those building from source should look at the README file
included in the source for more information.


Support

---------------

Contact the current project leader. At this time it Peter Harvey pharvey
at peterharvey dot org.


License

---------------

This project is governed by the LGPL and GPL. See COPYING in the source
for details.


Authors

---------------


# Peter Harvey
# others - see AUTHORS file in source for details

[Nick Gorham]

Post by Peter Harvey
FYI
Both unixODBC-Test and unixODBC-GUI-Qt could use more of my time but I
need to move on (at least for this pass). I have renamed ODBC++ to
unixODBC-CPP and I will replace the contents of this project with
unixODBC-GUI-Qt::Wrappers::CPP. This is a merge of sorts.
Nick could you add the following to unixodbc.org...

Ok

Post by Peter Harvey
unixODBC-CPP
============
This project is a very thin C++ wrapper for ODBC. This is most useful
for those who know something about the ODBC API but want a;
- friendlier interface for C++ (traditional calls or those with
compressed arg list for example)
- friendlier interface for modern IDE's (better code completion for example)
- no features hidden
Download
-------------
The project is hosted at SourceForge as follows;
Project Descriptive Name: unixODBC-CPP
Project Unix Name: odbc-class-lib
CVS Server: odbc-class-lib.cvs.sourceforge.net
Web Server: odbc-class-lib.sourceforge.net
Source and binary distributions will be made available from
time-to-time. Get the latest sources from cvs if you want the 'bleeding
edge'. Those building from source should look at the README file
included in the source for more information.
Support
---------------
Contact the current project leader. At this time it Peter Harvey pharvey
at peterharvey dot org.
License
---------------
This project is governed by the LGPL and GPL. See COPYING in the source
for details.
Authors
---------------
# Peter Harvey
# others - see AUTHORS file in source for details
_______________________________________________
unixODBC-dev mailing list
http://mailman.unixodbc.org/mailman/listinfo/unixodbc-dev

[Nick Gorham]

Post by Peter Harvey
FYI
Both unixODBC-Test and unixODBC-GUI-Qt could use more of my time but I
need to move on (at least for this pass). I have renamed ODBC++ to
unixODBC-CPP and I will replace the contents of this project with
unixODBC-GUI-Qt::Wrappers::CPP. This is a merge of sorts.
Nick could you add the following to unixodbc.org...

Done,

Also the changes to the DM are done, so it should play with the new
odbcinstQ4. It seems to almost work here, the dialog comes up, but I
can't select any DSN, but that is with QT 4.5 beta. And if I select a
filedsn it seems to return the directory the dsn is contains in, but not
the actual file.

Anyway, the interface is in place now.

[Peter Harvey]

Post by Nick Gorham
Also the changes to the DM are done, so it should play with the new
odbcinstQ4. It seems to almost work here, the dialog comes up, but I
can't select any DSN, but that is with QT 4.5 beta. And if I select a
filedsn it seems to return the directory the dsn is contains in, but not
the actual file.

Awesome - thanks Nick!

Selecting a DSN works here. Selecting a FILEDSN now returns the abs path and
filename. Unfortunately for me I am using sqlite odbc driver for my testing
and it always returns SQL_INVALID_HANDLE when (!_WIN && hwnd) so I have not
seen it fully operational yet.

--
Peter

[Nick Gorham]

Post by Peter Harvey

Post by Nick Gorham
Also the changes to the DM are done, so it should play with the new
odbcinstQ4. It seems to almost work here, the dialog comes up, but I
can't select any DSN, but that is with QT 4.5 beta. And if I select a
filedsn it seems to return the directory the dsn is contains in, but not
the actual file.

Awesome - thanks Nick!
Selecting a DSN works here. Selecting a FILEDSN now returns the abs path and
filename. Unfortunately for me I am using sqlite odbc driver for my testing
and it always returns SQL_INVALID_HANDLE when (!_WIN && hwnd) so I have not
seen it fully operational yet.
--
Peter

Just hack the code in DriverManager/SQLDriverConnect.c to null the
handle before calling the driver, what we have done here doesn't need
any more (or less) code in the driver to deal with prompts, that bit is
entirly up to the driver.

I don't think we can ever assume that apps are going to pass a valid
handle into the call though. (with reference to your other email to the
sqllite chap).

[Peter Harvey]

Post by Nick Gorham
Just hack the code in DriverManager/SQLDriverConnect.c to null the
handle before calling the driver, what we have done here doesn't need
any more (or less) code in the driver to deal with prompts, that bit
is entirly up to the driver.
I don't think we can ever assume that apps are going to pass a valid
handle into the call though. (with reference to your other email to
the sqllite chap).

Well the driver is going to have to do something platform specific to
fully handle SQLDriverConnect. I suppose one approach would be to always
pass a NULL window handle to the driver but that would either result in
an IM008 at times or the driver would have to do something platform
specific to prompt. My thinking is pass the ODBCINSTWND to the driver
and let the platform specific approach have a bit more information to
work with.

--
Peter

[Nick Gorham]

Post by Peter Harvey

Post by Nick Gorham
Just hack the code in DriverManager/SQLDriverConnect.c to null the
handle before calling the driver, what we have done here doesn't need
any more (or less) code in the driver to deal with prompts, that bit
is entirly up to the driver.
I don't think we can ever assume that apps are going to pass a valid
handle into the call though. (with reference to your other email to
the sqllite chap).

Well the driver is going to have to do something platform specific to
fully handle SQLDriverConnect. I suppose one approach would be to always
pass a NULL window handle to the driver but that would either result in
an IM008 at times or the driver would have to do something platform
specific to prompt. My thinking is pass the ODBCINSTWND to the driver
and let the platform specific approach have a bit more information to
work with.
--
Peter

Well, what I have done in the past with Easysoft drivers (though we
don't bother now as no app ever makes use of it) is to ignore the window
handle and just try and bring a Qt session up, no need for any special
information from anywhere, My point is how would a application create a
ODBCINSTWND even if it wanted to?

Given that Qt is going to be released under the LGPL now there is even
less reason why a driver writer could not do the same as we did. It
needs no platform specific code at all, just creating a QApplicaion and
passing control to it. In just the same way as the odbcinstQ code does.

[Peter Harvey]

-----Original Message-----
Sent: Saturday, January 17, 2009 9:42 AM
To: Development issues and topics for unixODBC
Subject: Re: [unixODBC-dev] unixODBC-CPP

Post by Peter Harvey

Post by Nick Gorham
Just hack the code in DriverManager/SQLDriverConnect.c to null the
handle before calling the driver, what we have done here doesn't need
any more (or less) code in the driver to deal with prompts, that bit
is entirly up to the driver.
I don't think we can ever assume that apps are going to pass a valid
handle into the call though. (with reference to your other email to
the sqllite chap).

Well the driver is going to have to do something platform specific to
fully handle SQLDriverConnect. I suppose one approach would be to

always

Post by Peter Harvey
pass a NULL window handle to the driver but that would either result

in

Post by Peter Harvey
an IM008 at times or the driver would have to do something platform
specific to prompt. My thinking is pass the ODBCINSTWND to the driver
and let the platform specific approach have a bit more information to
work with.
--
Peter

Well, what I have done in the past with Easysoft drivers (though we
don't bother now as no app ever makes use of it) is to ignore the window
handle and just try and bring a Qt session up, no need for any special
information from anywhere, My point is how would a application create a
ODBCINSTWND even if it wanted to?
Given that Qt is going to be released under the LGPL now there is even
less reason why a driver writer could not do the same as we did. It
needs no platform specific code at all, just creating a QApplicaion and
passing control to it. In just the same way as the odbcinstQ code does.

Yes; I agree that your solution does work but would it be slightly better
(with no real down-side) to pass in an ODBCINSTWND? Advantages (however
slight) are;

- greater chance of the dialog being properly parented
- greater chance that the dialog will look & feel the same as the parent

The driver can then decide to use the approach the developer feels is best;

IF ( WIN )
- ignore hwnd OR
- assume HWND is MS window handle
ELSE
- ignore hwnd OR
- assume HWND is ref to an ODBCINSTWND

--
Peter

[Nick Gorham]

Post by Peter Harvey
Yes; I agree that your solution does work but would it be slightly better
(with no real down-side) to pass in an ODBCINSTWND? Advantages (however
slight) are;
- greater chance of the dialog being properly parented
- greater chance that the dialog will look & feel the same as the parent
The driver can then decide to use the approach the developer feels is best;
IF ( WIN )
- ignore hwnd OR
- assume HWND is MS window handle
ELSE
- ignore hwnd OR
- assume HWND is ref to an ODBCINSTWND
--
Peter

But where is the parent handle going to come from, normally its directly
from the app, we just added a specific case where the app doesn't select
a DSN, but thats going to (IMHO) be very rare.

Whatever we may like to think about unixODBC, there are three non
windows driver managers, and a driver writer will write what works for
at least two of them, probably all three.

I dont see app writers changing anything, most already have their own
dialog or menu to select a DSN. And I dont know of any drivers that do
what you suggest. The last thing a driver writer wants to do is tie the
driver to a lib that will make it hard to build one binary lib that
works on many platforms.

Again IMHO.

[Peter Harvey]

Post by Nick Gorham

Post by Peter Harvey
Yes; I agree that your solution does work but would it be slightly better
(with no real down-side) to pass in an ODBCINSTWND? Advantages (however
slight) are;
- greater chance of the dialog being properly parented
- greater chance that the dialog will look & feel the same as the parent
The driver can then decide to use the approach the developer feels is best;
IF ( WIN )
- ignore hwnd OR
- assume HWND is MS window handle
ELSE
- ignore hwnd OR
- assume HWND is ref to an ODBCINSTWND
--
Peter

But where is the parent handle going to come from, normally its
directly from the app, we just added a specific case where the app
doesn't select a DSN, but thats going to (IMHO) be very rare.
Whatever we may like to think about unixODBC, there are three non
windows driver managers, and a driver writer will write what works for
at least two of them, probably all three.
I dont see app writers changing anything, most already have their own
dialog or menu to select a DSN. And I dont know of any drivers that do
what you suggest. The last thing a driver writer wants to do is tie
the driver to a lib that will make it hard to build one binary lib
that works on many platforms.
Again IMHO.

I agree that this is all about edge cases but we are not talking about
any significant (coding) work to pass the window handle down to the driver.

1. Where does the window handle come from?

An application can, if the developer wants, choose to pass a window
handle as follows;

#ifdef WIN
hWnd = (SQLHWND)(this->winId());
#else
ODBCINSTWND Wnd;

strcpy( Wnd.szUI, "odbcinstQ4" );
Wnd.hWnd = this;
hWnd = (SQLHWND)(&Wnd);
#endif

This uses Qt as an example. I realize that the cases may be rare but in
some ways its simply because app developers have not had a solution to this.

2. Driver developer writing to least common denominator?

Perhaps. In anycase I am just thinking that it is best to let the driver
developer decide since its so little effort to just provide the window
handle.

3. " tie the driver to a lib that will make it hard to build one binary
lib that works on many platforms"

A driver developer could carry on ignoring the window handle (no
effort), or use it knowing the type (on UNIX'sm) is ODBCINSTWND.

I think this is a pretty good case for passing the window handle to the
driver - but perhaps there is existing usage that you are concerned
about... that passing in the window handle will cause existing drivers
to fail? I doubt I can add much more in the way to make my case so I
will step back and let you decided. In the end "its all good to me"... I
have other things I can focus on :)

--
Peter

[Nick Gorham]

Post by Peter Harvey

Post by Nick Gorham

Post by Peter Harvey
Yes; I agree that your solution does work but would it be slightly better
(with no real down-side) to pass in an ODBCINSTWND? Advantages (however
slight) are;
- greater chance of the dialog being properly parented
- greater chance that the dialog will look & feel the same as the parent
The driver can then decide to use the approach the developer feels is best;
IF ( WIN )
- ignore hwnd OR
- assume HWND is MS window handle
ELSE
- ignore hwnd OR
- assume HWND is ref to an ODBCINSTWND
--
Peter

But where is the parent handle going to come from, normally its
directly from the app, we just added a specific case where the app
doesn't select a DSN, but thats going to (IMHO) be very rare.
Whatever we may like to think about unixODBC, there are three non
windows driver managers, and a driver writer will write what works for
at least two of them, probably all three.
I dont see app writers changing anything, most already have their own
dialog or menu to select a DSN. And I dont know of any drivers that do
what you suggest. The last thing a driver writer wants to do is tie
the driver to a lib that will make it hard to build one binary lib
that works on many platforms.
Again IMHO.

I agree that this is all about edge cases but we are not talking about
any significant (coding) work to pass the window handle down to the driver.

I just had to go and check, but as I thought, the driver manager already
passes the handle down to the driver. The hwnd that is passed into
SQLDriverConnect, is passed into SQLDriverConnect in the driver (unless
I have missed somthing, which is entirly possible given its a Sunday
morning)

Post by Peter Harvey
1. Where does the window handle come from?
An application can, if the developer wants, choose to pass a window
handle as follows;
#ifdef WIN
hWnd = (SQLHWND)(this->winId());
#else
ODBCINSTWND Wnd;
strcpy( Wnd.szUI, "odbcinstQ4" );
Wnd.hWnd = this;
hWnd = (SQLHWND)(&Wnd);
#endif
This uses Qt as an example. I realize that the cases may be rare but in
some ways its simply because app developers have not had a solution to this.
2. Driver developer writing to least common denominator?
Perhaps. In anycase I am just thinking that it is best to let the driver
developer decide since its so little effort to just provide the window
handle.
3. " tie the driver to a lib that will make it hard to build one binary
lib that works on many platforms"
A driver developer could carry on ignoring the window handle (no
effort), or use it knowing the type (on UNIX'sm) is ODBCINSTWND.
I think this is a pretty good case for passing the window handle to the
driver - but perhaps there is existing usage that you are concerned
about... that passing in the window handle will cause existing drivers
to fail? I doubt I can add much more in the way to make my case so I
will step back and let you decided. In the end "its all good to me"... I
have other things I can focus on :)

Well, as I said, we already are passing the handle, where I was unsure
as to the prtacticality of the thing, was attempting to assign any
meaning to the hwnd on non windows platforms. Its a catch 22 AFAIKS, the
app writers won't do it because there are no drivers that take notice
(so they have their own solution), the driver writers won't take notice
as no apps make use of it.

I guess as always I fall back on a rather lazy stance where open source
is at its best where the problem drives the solution, We added the extra
behaviour with no connection info being passed, as someone wanted it.

Of course if any app or driver writers out there are thinking "this is
just what I want" then please say so, and I will change my mind :-)