How / can I ensure that an .accde format of my front end access 2007 database saves records / edits

regarding msdn citation ("How references work with .accde files
"): (http://office.microsoft.com/en-us/access-help/hide-vba-code-from-users-HA010239557.aspx#BM4)

I made an accde copy of the back end database and updated the links to tables in the front end accdb to point to the accde back end and made an accde copy of the front end but still see the same issue:  changes to the records are not saved when using a front-end accde copy.

<I made an accde copy of the back end database>
?

First create a working split database.
Then convert the "Front End" to an .accde file.
Then test.

(You do not need an accde version of the back end.)

JeffCoachman

Yes, that's what I had done initially, split the database.  The front end accdb worked as expected.  After creating an accde from the front end, only the front end accde did not save.

I got this when trying to use another control / button:

The expression ON Click you entered as the event property setting produced the following error:  YOu can't go the specified record:

This error occurs when an event has failed to run because Microsoft Office Access cannot evaluate the location of the logic for the event. For example, if the OnOpen property of a form is set to =[Field], this error occurs because Access expects a macro or event name to run when the event is fired.

Ok, yes the original split / fe is working... doing compact repair / decompile and will test...

Decompile and front-end / split accdb still works... making accde

That did solve the (additional) issue of the error  <The expression ON Click you entered as the event property setting produced the following error:  YOu can't go the specified record.> but only after I disabled my startup form / login screen.  The issue with the inability to save changes to records remains...

Then I am stumped.

So let's review...

You have a split DB (.accdb files for both the FE and the BE)
1. You Open the Front end DB
2. You open a form
3. You add (or edit) a record.
4. You close the form

5. You open the back end database
6. You open the table that is the source for the form.
7. You can see the New (or updated) record


Now, as soon as you create an accde file from the same Front End, and repeat steps 1-7, you do NOT see the updated record?

When I make the accde file I do not see the updates on the data entry form after closing and reopening them or refreshing them.

If I bypass the startup on the front end accde and go directly to the linked table I can edit a record.  But If I open one of the forms and make the edits changes do not apply.  

I'm thinking It appears to be what I'm doing with the form properties using open arguments.

What I'm doing is using form open argurments when opening a form from a command button.
When the form opens setting different controls to be visible etc and also setting allow edits and allow additions properties of the form??....

Yes, when I edit in the accdb front end the edits show / are written, when I edit in the accde they do not... appears to be what I'm doing with setting form properties with form open arguments...

Ultimately you are doing the same thing in both the accdb and the accde file.
So if it works in the .accdb file, it should work in the .accde file.

Basically all an accde file is, is a version of the .accdb file that the user cannot make design changes to (cannot go into design view ...)

So I'm still stumped...

Perhaps another Expert has seen this before...?

This identified and resolved an additional issue.  The original problem appears to be related to a save command (''DoCmd.RunCommand acCmdSave)  I was using on the before update event of the data entry form also.

DoCmd.RunCommand acCmdSave
This is typically not needed.
Access saves records automatically.

Glad you got i resolved...

;-)

jeff

" I was using on the before update event of the data entry form also. "
You cannot execute a Save in the BU event, because a Save is what ... triggers the BU event.  Thus, you end up with a error situation and/or endless loop.

mx