Save does not work

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I display form with Me.AllowEdits = False. When user presses "Edit" button
then I change Me.AllowEdits = True.

Now, when user finish editing. I have following code that does not work:
<code>

Private Sub SaveCstBtn_Click()
On Error GoTo Err_SaveCstBtn_Click

DoCmd.RunCommand acCmdSaveRecord
Me.AllowEdits = False

Exit_SaveCstBtn_Click:
Exit Sub

Err_SaveCstBtn_Click:
MsgBox Err.Description
Resume Exit_SaveCstBtn_Click

End Sub
</code>

I receive error message:

"The command or action 'SaveRecord' isn't available now."

Please help me fix this error.

Thank you,
AccessTester1
 
try replacing

DoCmd.RunCommand acCmdSaveRecord

with

If Me.Dirty Then
Me.Dirty = False
End If

hth
 
Tina,

Thank you. It works. But, I am puzzled why my original code didn't work.
Based on the documentation acCmdSaveRecord should have worked?

Regards,
AccessTester1
 
OOOPs, It was too eary to say it worked. This is what happens when I
replaced the code you mention:

User is able to edit and save the record. However, if user hits "Undo"
button then the record loses the changes that were just edited and saved.

This is getting interesting, but frustrating too.

Thanks,
AccessTester1
 
Based on the documentation acCmdSaveRecord should have worked?

you'd think so, yes. i have no idea why one works and not the other. i've
simply run across a few situations before when Access balked at a SaveRecord
command but accepted Me.Dirty = False. at some point i just quit beating my
head against the wall of what should work but doesn't, and go with whatever
work-around or substitution that gets the job done. <g>
 
well, don't you want the user to be able to Undo their changes? suggest you
step through your complete code sequence to see what is happening when - you
need a clear picture of events before you can manipulate the outcome.
 
Hi Tina,

The way app should work is during the editing 'UnDO" is available, but once
Save buttons is pressed then data should be saved.

Then is user changes their mind then they can hit 'Edit' again and revert
the changes.

I have temporary fix now based on your work around and it is as follow in my
'Undo' sub code:

Sub Undo()

If Me.Dirty Then
do the undo
EndIf

This way the changes will not revert if save was done because we're setting
Me.Dirty = False in Sub SAVE().

Thanks,
AccessTester1

P.S. I thought thread was getting bigger so I posted the last question in
new thread. so you can go ahead and ingore it.
 
well, you might have to trap the Esc key selection using KeyPress or KeyDown
(i can never remember which until i fiddle with it), and remove the Undo
option from the form's menu, in order to control that action. or it might be
as simple as adding code to the Save button to move to the Next record after
AllowEdits is set to false, as

DoCmd.RunCommand acCmdRecordsGoToNext

hth
 
AccessTester1 said:
OOOPs, It was too eary to say it worked. This is what happens when I
replaced the code you mention:

User is able to edit and save the record. However, if user hits "Undo"
button then the record loses the changes that were just edited and saved.
Click to expand...

Yes, try moving ahead 5 records. Now open the file again (launch a 2nd copy
of ms-access..and then go file->open).

You will indeed see that the record has been written to disk. Note CAREFULLY
when you go edit-> undo last saved record "appears".Note that this is NOT
the same as undoing a field change..

What this means is just like in word, or excel, the last thing you did can
be un-done. Note that is obviously means that the record is stored somewhere
else, and is in fact thrown back on top of the actual record you wrote to
disk when you go un-do. So, you ARE committing the record..but "un do" saved
record takes the copy and throws it back to the record.

I had not noticed that behavior until you pointed this out. And, I did NOT
realize that after you commit the record to disk that the un-do was STILL
available.

More amazing is that you can STILL navigate to other records..and your undo
will
undo that LAST edited record.

As far as I can tell, this feature came to be in a2002.

So, your disk write is working. What we need to learn how to do is disable,
or flush that "last edited" buffer. This buffer is ONLY for one record. It
does go away when you close the form.
 
These feature is well and good in Word, Excel, etc. However, we are dealing
with database. I suppose little things like this are reasons why Access is
not true RDBMS when compare to SqlServer, MySQL, etc.

I am facing this problem because I can't ask user to go 5 record up and down
(not good programming) as well as I can't even ask them to close and re-open
form. I mean will think I am idiot.

So, as Tina has suggested, I'll need to cover all myground, i.e., escape
keys and anything else comes to mind to catch it and stop undo.

Thanks for your pointing out the new (unneeded) feature, :-)
AccessTester1
 
AccessTester1 said:
These feature is well and good in Word, Excel, etc. However, we are
dealing
with database.
Click to expand...

Actually, no, we are not dealing with a database. You are dealing with a
tool that is part of office.
And, this feature was asked for my users.
I suppose little things like this are reasons why Access is
not true RDBMS when compare to SqlServer, MySQL, etc.
Click to expand...

I don't understand the above statement one bit??????? Would you call c++ a
database? Would you call VB a database?

How can you build a form with SqlServer? How can you build a report with
SqlServer? These database systems have NO ability to create a interface. To
create a interface to a database system you need to use tools like
ms-access, or VB.

ms-access is simply a development tool and database manger. IT IS NOT a
databases. If you want to use Sqlserver, or Sybase etc with ms-access you
are free to do so. In fact, for the last THREE versions of office, a free
copy of sql server has been provided on the office cd for use with
ms-access.

You are confused about the difference between a developer tool like c++, VB,
or ms-access, and that of a database. If you want to use a "true" RDBMS with
ms-access you are most free to do so. (and, a copy of the MSDE has been on
the office cd for use with ms-access since a2000). So, I have to agree that
VB, or ms-access is not a true RDBMS...but no self respecting person would
state that VB, c++, or ms-access is a "true RDBMS" anyway. These are just
tools that let you work with a database engine of your choice.

So, you are using a tool that is part of office (and, someone informed me
that the un-do behavior has been there for more ten 10 years!). The reason
why I never noticed the feature is that I RARELY allow navigation in a form
anyway. (it is silly to load up a form attached to a large table..;and
simply let users start working. I always asked the user BEFORE I load the
form what reocord to work on, then let them work, and then they close the
form to save.

It is poor idea to load up a form with so many records anyway from a
performance point of view anyway.

It is a simple matter to remove the un-do menu option anyway. So, a better
solution is to provide your own un-do menu option anyway. Either you let
users who know how to use ms-access work the way ms-acces always worked, or
you provide you own UI (for all of my appliations, I provide my own menus
etc)

So, just put in your own code to check if the record is dirty.

if me.dirty = true then
me.undo
end if

So, if the record is not dirty...then the undo will not occur.

And, here is some great ideas on "why" using menus is a good idea

http://www.members.shaw.ca/AlbertKallal/Articles/UseAbility/UserFriendly.htm
 
Back
Top