Error 2759 saving record Access 2010
Bob Darlington
Access 2002 backend.
I have the following code in the AfterUpdate event on a control to force the
record to be saved before proceeding.
DoCmd.RunCommand acCmdSaveRecord
When it encounters this line, I get the following error:
'The method you tried to invoke on an object failed.' (Error 2759).
The same thing happens if I use Me.Dirty = False
But the record gets saved anyway.
All references are in tact.
If I test the same frontend mdb on another PC using Access 2002 and linked
via the LAN to the same data file, I don't get the message.
Any ideas out there.
--
Bob Darlington
Brisbane
Tony Toews
If I recall correctly A2003 and newer requre that the record be dirty
before you can execute the code to save it. So check to see if the
record is dirty before saving it.
If me.dirty = true then _
DoCmd.RunCommand acCmdSaveRecord
Tony
--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
For a convenient utility to keep your users FEs and other files
updated see http://www.autofeupdater.com/
Bob Darlington
--
Bob Darlington
Brisbane
"Tony Toews" <tto...@telusplanet.net> wrote in message
news:70u9p6h146h652306...@4ax.com...
Bob Darlington
Tony
Further to my earlier reply, I've tried the following as a workaround in the
error code and it seems to work OK:
'ErrorShopNum_AfterUpdate:
If Err = 2759 And Me.Dirty Then 'Error occurring on acCmdSaverecord in
Access 2010 - this appears to solve problem
vCount = vCount + 1
If vCount = 0 Then DoCmd.RunCommand acCmdSaveRecord 'Only retry once
Resume Next
End If'
Also, the problem didn't occur under Access 2003 or 2002 testing.
BUT. I'm still concerned that things which worked under previous versions
are not working in 2010.
My application contains 227 forms and testing every function on every form
for every possible scenario would seriously affect my golfing schedule.
--
Bob Darlington
Brisbane
David-W-Fenton
> If I recall correctly A2003 and newer requre that the record be
> dirty before you can execute the code to save it
No, that is not true.
--
David W. Fenton http://www.dfenton.com/
contact via website only http://www.dfenton.com/DFA/
Tony Toews
<NoE...@SeeSignature.invalid> wrote:
>> If I recall correctly A2003 and newer requre that the record be
>> dirty before you can execute the code to save it
>
>No, that is not true.
I'll be darned. You're right.
I am positive, and obviously wrong, that I came across this somewhere,
somewhen.
David-W-Fenton
> On 1 Apr 2011 19:56:54 GMT, "David-W-Fenton"
><NoE...@SeeSignature.invalid> wrote:
>
>>> If I recall correctly A2003 and newer requre that the record be
>>> dirty before you can execute the code to save it
>>
>>No, that is not true.
>
> I'll be darned. You're right.
>
> I am positive, and obviously wrong, that I came across this
> somewhere, somewhen.
I am well aware that it's not the case, because two of my main
ongoing (and long-lived) projects use replicated back ends. Before
Jet 4, a save would increment the generation field for the record,
even if the record had not been saved, and this could cause an
unchanged record to produce a conflict with the same record in a
different replica that had a real change. If the "fake" change
record were saved more times than the real change, with Jet 3.5, the
fake change would win and the real change would lose (because
conflict resolution in Jet 3.5 was based on the full record and the
winner of a conflict was the record with the most changes; Jet 4
changed to field-by-field conflict resolution, so that problem went
away).
Anyway, my point is that unnecessary saves could cause problems
(i.e., DATA LOSS) in replicated apps with Jet 3.5, so I was always
careful to never save a record unless the record was actually dirty.
I knew perfectly well that doing so without the check would save the
record, anyway, which was why I always checked first.