RE: Oracle 10g cursor, override CRecordset::Update() problem
- From: TC <TC@xxxxxxxxxxxxxxxxxxxxx>
- Date: Tue, 10 Jun 2008 07:52:01 -0700
Well, not specifically because we're not implementing Bulk Row fetching.
But, the code for RefreshRowset() is :
ASSERT(IsOpen());
ASSERT(m_dwOptions & useMultiRowFetch);
RETCODE nRetCode;
AFX_ODBC_CALL(::SQLSetPos(m_hstmt, wRow, SQL_REFRESH, wLockType));
// Need to fixup bound fields in some cases
if (m_nFields > 0 && !IsEOF() && !IsBOF() &&
!(m_dwOptions & useMultiRowFetch))
{
Fixups();
}
I think the important call here is the SQLSetPos(). If I copy this code and
call it after my Update() call, I get the following output:
Attempt to fetch before the result set returned the first rowset
which I think is interesting. I'm not sure what this is telling me. The
symptoms are the same in that the recordset is still not refreshed.
Any ideas?
Thanks,
--
TC
"Pak-Ming Cheung [MSFT]" wrote:
So, I assumed you are using MFC CRecordset, right?.
If so, have you tried CRecordset::RefreshRowset, which can specify which
rows to refresh. This may be less costly than Requery.
Ming.
MDAC Team, Microsoft.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
"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
- References:
- RE: Oracle 10g cursor, override CRecordset::Update() problem
- From: Pak-Ming Cheung [MSFT]
- RE: Oracle 10g cursor, override CRecordset::Update() problem
- Prev by Date: RE: Oracle 10g cursor, override CRecordset::Update() problem
- Next by Date: Re: SQL_DESC_TYPE sql type or c type?
- Previous by thread: RE: Oracle 10g cursor, override CRecordset::Update() problem
- Next by thread: RE: Oracle 10g cursor, override CRecordset::Update() problem
- Index(es):
Relevant Pages
|
Loading
