Re: Update using CADORecordBinding, Provider error: -858993460
- From: "Stephen Howe" <stephenPOINThoweATtns-globalPOINTcom>
- Date: Tue, 28 Feb 2006 13:55:35 -0000
Hi
You should try solving a simpler problem first.
In your case, leave out RecordBinding and just work with Recordsets.
If you can get the RecordSet to work, then you can add RecordBinding
afterwards.
RecordBinding just complicates the picture at this point.
However, the update fails with the provider error: "Multiple-step OLE DBNo
operation generated errors. Check each OLE DB status value, if available.
work was done." with error code: -858993460. When I examine the statusfields
for each of the columns, I see that they are all set toIRowsetChange
"adFldPermissionDenied" although the record set properties do indicate the
recordset is updatable. (Dynamic properties of the Recordset,
and IRowsetUpdate are both set to true and Supports(adUpdate) returnstrue).
And after you have a successful Recordset Open(), you do have a non-ReadOnly
cursor?
Might be interesting to check the values of LockType, CursorType _AFTER_ a
successful Open(), ADO can coerce these to something else. CursorLocation
will always be what you set.
For some experimentation, I tried changing the query to access theretreival
underlying table directly. Update still fails, but the status values are
slightly different. This time, for all but the last column in the
order, status values are set to "adFldUnavailable", and the last columnhas a
status: "adFldCantConvertValue".is?
Any ideas / pointers as to what could be the reason and what the solution
I have never done updates via joins, never needed to.
I have never done so as I code all updates myself.
I don't ever use Recordsets for updating.
Recordsets have a lot of overhead and I tend to use them for read-only
purposes.
If the result is a single-row I will use Record objects.
My advice for JOINs is not to update them but manage with code and issue the
updates yourself.
ADO can go wrong on this quite easily .
But if I had to get this working, there are several things of ADO that I
would experiment with. I have read up on this.
Unfortunately it is is necessary to experiment because the documentation on
ADO seems incomplete.
On ADO, I cull information from MSDN, books on ADO, the #import include
files that VC writes, any notes issued with MDAC, Bill Vaughn's
articles/books. It is also wise to periodically check Microsoft's online
documentation on MSDN as they occasionally update it (I don't think they
will do so now - all efforts go into ADO.NET). Several points:
1) In your case, for the table you wish to update in your join, are you
selecting all parts of its Primary Key as part of your SELECT? If not, how
is the Recordset join supposed to update as any change is not unique to a
particular record on that table that it has to update? I am always amazed by
programmers not realising this. ADO has to uniquely identify the original
row.
2) If this is client-sided cursor, other things come into play. You would be
best reading
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnvbdev00/html/vb00e1.asp
and look at the dynamic property "Update Criteria" and also
See also dynamic property "Unique table"
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ado270/htm/mdprodynuniquetable.asp
3) For a server-sided cursor, the database has the responsibility for
updating.
But you would be wise to specify all parts of the PK's for each table in the
JOIN.
Stephen Howe
.
- Prev by Date: Re: MDAC 2.8 SP1 Install problem
- Next by Date: Re: Automatically running an application every day
- Previous by thread: MDAC 2.8 SP1 Install problem
- Next by thread: Re: ADO installed on 64 bit 2003 server
- Index(es):
Relevant Pages
|
|
