Tech Support > Microsoft Windows > Development Resources > Re: Repeaded read of resultset problem
Re: Repeaded read of resultset problem
Posted by Lothar Behrens on June 25th, 2003


johnbrown105@hotmail.com (John Brown) wrote in message news:<ee1f9e62.0306241732.a8a8bb4@posting.google.c om>...
I have adopted the parts to my code, but it has no effect. It would be, that
my SQL Server ODBC driver has all the capabilities and default settings.
For this, my previous code worked.

I have made some comments, that would be an incompatibility in the API
definition or my compiler does not convert types to void* automatically.

It is difficult for me to implement a class wrapper, that handles all
issues of ODBC programming. So I will develop it step by step.

My next step would be handling the issue, if the driver needs to load
the cursor library. Is it neccesary to handle this issue in a special
way ?

My second step is to implement database canges. I have implemented
database changes in java in that way:

Creating update statements out of the columns, that are present in a
select statement with out using 'CURRENT OF <CURSOR NAME>'

I had read the documentation about this and I will ask - did I really
need 'WHERE CURRENT OF ...'

I have used different database classes and no one of these (C++/java)
has any hint of such 'CURRENT OF ...'.

It would be hidden inside the class implementation.

My java implementation of creating statements dynamically is mostly
the same as modifying the orginal query
(removing any where clause and append the 'CURRENT OF ...' clause.

What is better ?

Thaks in advance

Lothar

rc = SQLSetEnvAttr(henv, SQL_ATTR_ODBC_VERSION, (void*) SQL_OV_ODBC3, 0);

rc = SQLSetStmtAttr(hstmt, SQL_ATTR_CURSOR_SCROLLABLE, (void*) SQL_SCROLLABLE,
0);

Posted by John Brown on June 26th, 2003


Neither does mine. I did not fix it because they were only warnings,
the program worked, and I am lazy.

I don't think so. You could include the single line:
SQLSetConnectAttr(hdbc, SQL_ATTR_ODBC_CURSORS, SQL_CUR_USE_IF_NEEDED,
0);
in your constructor. I suppose that you could query the driver to find
out if it supported scrollable cursors and then take the appropriate
action, but why do that when SQL_CUR_USE_IF_NEEDED does the work for
you? Read the documentation on SQLFetchScroll where it says "Drivers
are not required to support all fetch orientations; an application
calls SQLGetInfo with an information type of
SQL_DYNAMIC_CURSOR_ATTRIBUTES1, ..."

Remember that class wrappers exist to simply programming. In the same
way that other class libraries hide tiresome details such as "FOR
UPDATE OF ..." and "WHERE CURRENT OF ...", you should hide them too.
So you will have to modify the SQL statements that are passed to your
objects as you did for your Java classes.


Similar Posts