I'm using Access 2010 to open an Access 2002 mdb front end linked to an
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

On Thu, 31 Mar 2011 16:40:19 +1000, "Bob Darlington"
<bob (AT) notheredpcman (DOT) com.au> wrote:

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/

Thanks Tony. I tried your suggestion but still the same message.


--
Bob Darlington
Brisbane
"Tony Toews" <ttoews (AT) telusplanet (DOT) net> wrote

"Tony Toews" <ttoews (AT) telusplanet (DOT) net> wrote

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

Tony Toews <ttoews (AT) telusplanet (DOT) net> wrote in
news:70u9p6h146h652306in803nfdfgfqq2p1g (AT) 4ax (DOT) com:

No, that is not true.

--
David W. Fenton http://www.dfenton.com/
contact via website only http://www.dfenton.com/DFA/

On 1 Apr 2011 19:56:54 GMT, "David-W-Fenton"
<NoEmail (AT) SeeSignature (DOT) invalid> wrote:

I'll be darned. You're right.

I am positive, and obviously wrong, that I came across this somewhere,
somewhen.

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/

Tony Toews <ttoews (AT) telusplanet (DOT) net> wrote in
news:8biip6dupsu6p1rft0d18dsvd80qe17d8r (AT) 4ax (DOT) com:

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.

--
David W. Fenton http://www.dfenton.com/
contact via website only http://www.dfenton.com/DFA/