RE: Oracle 10g cursor, override CRecordset::Update() problem

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

So, it seems that you tried to fetch a row with negative index (before the
first row). So, what is the value of wRow? (Could you first hard-code the
value of wRow and try some other values)? [wRow is a relative index of the
rowset]

Also, to troubleshoot the problem, could you desscribe the following more
detail, say:
- How do you obtain the resultset? (ExecDirect, Fetch)?
- Are you updating the application buffer after fetching the resultset, and
then calls the overriden Update

btw, i don't know the original design. But this may not be supported,
anyway. Also, you may also try the forum for MFC.

Ming.
MDAC Team, Microsoft.

==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.





"TC" wrote:

More:

I've noticed that If I call CRecordset::GetData(), which in turn calls
::SQLGetData() that the value for a changed column is the old value. Checking
the db the new value is committed.

So, if Update() is overridden, and the data is updated and committed by a
third party toolkit (which uses CLI, not ODBC) how can the current cursor be
made to reflect the change? Is there a call, or sequence of calls that should
be made to the current statement, which causes the cursor to reflect new data?


--
TC


"TC" wrote:

We have a data access layer in which polymorphic objects derived from
CRecordset provide a generic interface to both Sybase Adaptive Server and
Oracle databases. This has allowed us to write generic code at the
application level such that the applications do not need to have knowledge of
which database they are pointing at.

In the Oracle case, data gets written using a 3rd party toolkit. The toolkit
is necessary because it maintains some additional integrity and other
functions that are not handled at the server side.

To make this work, we have overridden CRecordset::Update() and taken care of
edits and inserts by calling the toolkit from inside the method, thereby
circumventing the base implementation.

This has worked fine, until we recently began to work on supporting Orcacle
10g.

What we see is that in the edit case, the edit is made to the data store
correctly, but for some reason, when we move through the recordset
(CRecordset::Move()),
the underlying cursor does not reflect the edit. Rather, it still seems to
contain the original values.

Several of our apps are CRecordView based, and advancing through result set
and seeing old values is obviously a problem. We can execute a Requery() on
the CRecordset object, which does then refresh the edited record, but this is
unacceptable for performance reasons.

The CRecordsets derived classes are being opened as dynasets, but in a way
seem to be behaving more like snapshots.

Has anyone seen similar behavior, or have any suggestions about what might
be wrong and how to go about fixing it?

Thanks,

--
TC
.