Hi,

I have written an ODBC wrapper class to be used in my database forms.

If I move to next and occosionally have no more data, how do I detect
this before ?

I can detect this if the user has pressed the next button and I run into
'no rows fetched' and then I can disable the next button.

Any ideas ?

Thanks

Lothar

On 10 Aug 2004 12:34:48 -0700, lothar.behrens@lollisoft.de (Lothar
Behrens) wrote:

SQLFetch and SQLFetchScroll should both return SQL_NO_DATA. Check the
return value.

Huh?? Doesn't sound like ODBC to me...

--
Bob Hairgrove
NoSpamPlease@Home.com

Bob Hairgrove <invalid@bigfoot.com> wrote in message news:<81kih0ln1hugg9bdqdvdtkltqk9ic346h1@4ax.com>. ..
I really *do* checking for SQL_ERROR or SQL_SUCCESS_WITH_INFO. I do not
check for SQL_NO_DATA yet, but I check for the RowsFetched parameter.

retcode = SQLExtendedFetch(hstmt, SQL_FETCH_NEXT, 0, &RowsFetched, RowStat);

So, I detect this condition. The ODBC version 3.x says to use SQLFetchScroll.
I still use ver. 2.x and for using 3.x I have to also check for SQL_NO_DATA.

But this is no really bug in my code :-)

In the affect, that I use my ODBC class wrapper in my GUI application, to
let the wrapper do the database stuff for me, I see a problem to detect this
condition too late.

To prevent the ability to press the GUI button 'Next' I must let him/her press
the button to later on disable it. In the application this is a little unhappy
behaviour, but it works.

I would issue a
retcode = SQLExtendedFetch(hstmt, SQL_FETCH_PREV, 0, &RowsFetched, RowStat);
or call my previous member.

This should bring the cursor state back to a proper one and my GUI could reload
the yust viewed data or some foreign changed data (refresh).

And also a next push 'back' from the user would show some expected data 'change'.

With a proper handling in all cursor handling functions, I could disable the
buttons as an initial state, but I can't detect the state, if there is some
more data in one cursor 'move' direction.

My solution for this would only a move twice to expected direction and one back
if there was the ability to move twice. Then return no error.

On the other hand do a cursor state cleanup, move back and return an error
code to the GUI programmer to let him/her disable the affected button and then
displaying new data.

This would lead into a little bit more client server traffic or for the cursor
library little more overhead, but it seems, there is no such error code
defined in the ODBC API.

Would this be an interresting aspect for the API designers ?

Thanks

Lothar

On 11 Aug 2004 12:13:23 -0700, lothar.behrens@lollisoft.de (Lothar
Behrens) wrote:

It is a fundamental problem because, in a multi-user environment,
there is very little one can do to predict when a result set is
"finished" ... after all, a great deal of time can pass between
clicks, and another user can insert more rows in the meantime.
Depending on your cursor sensitivity, you might have a problem.

[snip]

ODBC is basically dead as far as Windows is concerned ... M$ is
letting it go the way they let Java go.

Official information from M$ is, don't use ODBC anymore, use OLEDB and
COM. Fortunately, since ODBC was based on XOpen protocols from the
beginning, ODBC has caught on in the *nix environment, and there are
at least two open source implementations of the ODBC standard
(unixODBC and iODBC) which are widely used.

--
Bob Hairgrove
NoSpamPlease@Home.com

Bob Hairgrove <invalid@bigfoot.com> wrote in message news:<odvkh09uhkjkvibbeaf0um3rqm5ce757ka@4ax.com>. ..
Firstly for me it would be no problem. To make it bullet proov, I like to
have some help :-)

Shit of Java :-)

These would be another project. My framework is designed like COM, but a little
smaller and also works under Linux.

To use other techniques, I would to adopt it as wrappers to don't depent on it
too much.

I use unixODBC on Linux :-)

It works with the same code from Windows. My framework is targeted to be
multiplatform.

Lothar