setting and clearing record dirty (A 2007)

[BBC via AccessMonster.com]

Two realated questions
1) Does setting default values in a forms properties cause it to be dirty
when a new record is created (DoCmd.GoToRecd ... acnewrec) especially without
triggering form_dirty. I have a form that goes dirty before I enter any data
and cannot track the event down that causing it (I know because it is
inserting the new record's primary keyID almost immediately). If sentence 1
is true can that behaviour be stopped (except by setting them programatically
later in the process ie once a real item is entered).

2) Is there any way to stop Access from saving the record automatically when
it moves to another one (or at least trapping it). As per question "1" above
it thinks it's dirty when I don't think it is or want it to be, and saves a
blank record (except for the defaults) with that "new key" when I attempt to
add another new one. I do have a field in the record that if 0 tells me that
no valid record is in place (ie no customer has be selected via a combobox to
create this new record for.

I use my own record navigation and new/save/undo controls in VBA that are
basically enhanced versions of the standard Nav. macros

Any good reading material on this around?

Appreciate the help.

 

[Dirk Goldgar]

Two realated questions
1) Does setting default values in a forms properties cause it to be dirty
when a new record is created (DoCmd.GoToRecd ... acnewrec) especially
without
triggering form_dirty. I have a form that goes dirty before I enter any
data
and cannot track the event down that causing it (I know because it is
inserting the new record's primary keyID almost immediately).

Having various controls' Default Values properties set doesn't dirty the
form. Setting the *value* of a bound control programmatically *will* dirty
the form, and it will do it without triggering the form's Dirty event. Most
likely you have code in the form's Current event that is setting the value
of some control.

2) Is there any way to stop Access from saving the record automatically
when
it moves to another one (or at least trapping it).

There are ways to keep Access from saving a record without user
confirmation, but the best thing to do is figure out what you're doing to
dirty the form unknowingly, and stop it.

 

[BBC via AccessMonster.com]

1) Updating unbound controls on a form programatically doesn't cause dirty,
correct (as it is only the record that dirtrys)
2) If bound controls are updated programatically and cause dirty without
triggering the dirty event can you still detect that with IS myform.dirty ?

Two realated questions
1) Does setting default values in a forms properties cause it to be dirty

[quoted text clipped - 4 lines]

and cannot track the event down that causing it (I know because it is
inserting the new record's primary keyID almost immediately).

Having various controls' Default Values properties set doesn't dirty the
form. Setting the *value* of a bound control programmatically *will* dirty
the form, and it will do it without triggering the form's Dirty event. Most
likely you have code in the form's Current event that is setting the value
of some control.

2) Is there any way to stop Access from saving the record automatically
when
it moves to another one (or at least trapping it).

There are ways to keep Access from saving a record without user
confirmation, but the best thing to do is figure out what you're doing to
dirty the form unknowingly, and stop it.

 

[Dirk Goldgar]

1) Updating unbound controls on a form programatically doesn't cause
dirty,
correct (as it is only the record that dirtrys)

Correct. Changing the value of unbound controls doesn't make the form
Dirty.

2) If bound controls are updated programatically and cause dirty without
triggering the dirty event can you still detect that with IS myform.dirty
?

Yes. The form's Dirty property will become True, even though the Dirty
*event* is not raised. The Dirty event is raised when user action causes
the record to become "dirty", but not when code does it.

 

[BBC via AccessMonster.com]

Is there a way to set the dirty flag off without triggering the record being
saved?

 

[Dirk Goldgar]

Is there a way to set the dirty flag off without triggering the record
being
saved?

You can undo the changes to the record, using the form's Undo method. Aside
from that, no.

 

[BBC via AccessMonster.com]

OK, despiration is setting in.
I now know why the form is dirty from the start, I was setting the clientID
ID (from a combobox selection) too early (not the tables primary key thought)
and have now corrected that. I can now enter the first new transaction
record for this client (this form only accepts transaction for existing
clients). However after entering the first transaction for this client, then
SAVING it(and it does) it I click my "new" button and execute the following
code in my "new recd" SUB.

Private Sub fNewRecd_Click()
Dim Recdsave As Integer
If Not Me.NewRecord Then
Recdsave = Proceed(RecdDirty)
If Recdsave = vbCancel Then Exit Sub
If Recdsave = vbYes Then
fSaveRecd_Click
' Else
' On Error Resume Next
' If Me.Dirty Then DoCmd.RunCommand acCmdUndo
End If

On Error GoTo fNewRecd_Click_Err
DoCmd.GoToRecord , "", acNewRec
End If
frmDirty (False)
InitNewRecd
Exit Sub

fNewRecd_Click_Err:
MsgBox Error$
End Sub

(The commented lines and the "If Not Me.NewRecord" and it's "End If" are
recent additions for trying to solve this progblem so the problem pre-existed
them.)

So this code executes but after it does the record on the form has not
changed, it still has all the same data in the fields on the form including
the previous primary key (not the word "NEW"). I do not get why the record
is still showing the previously entered (new) one. Do I need to requery the
form or someting? I use this SUB to initialize the form to a blank record
when it loads (works) but it doesn't work on the next "NEW".

Is there a way to not load any record into a form when the form first loads.
It seems to load the last record in the table unless specified otherwise in
the parent program's DoCmd.OpenForm.

I use this same code on other forms (minus the mentioned recent changes) and
it works for new records there.

 

[Dirk Goldgar]

OK, despiration is setting in.
I now know why the form is dirty from the start, I was setting the
clientID
ID (from a combobox selection) too early (not the tables primary key
thought)
and have now corrected that. I can now enter the first new transaction
record for this client (this form only accepts transaction for existing
clients). However after entering the first transaction for this client,
then
SAVING it(and it does) it I click my "new" button and execute the
following
code in my "new recd" SUB.

Private Sub fNewRecd_Click()
Dim Recdsave As Integer
If Not Me.NewRecord Then
Recdsave = Proceed(RecdDirty)
If Recdsave = vbCancel Then Exit Sub
If Recdsave = vbYes Then
fSaveRecd_Click
' Else
' On Error Resume Next
' If Me.Dirty Then DoCmd.RunCommand acCmdUndo
End If

On Error GoTo fNewRecd_Click_Err
DoCmd.GoToRecord , "", acNewRec
End If
frmDirty (False)
InitNewRecd
Exit Sub

fNewRecd_Click_Err:
MsgBox Error$
End Sub

(The commented lines and the "If Not Me.NewRecord" and it's "End If" are
recent additions for trying to solve this progblem so the problem
pre-existed
them.)

So this code executes but after it does the record on the form has not
changed, it still has all the same data in the fields on the form
including
the previous primary key (not the word "NEW"). I do not get why the
record
is still showing the previously entered (new) one. Do I need to requery
the
form or someting? I use this SUB to initialize the form to a blank record
when it loads (works) but it doesn't work on the next "NEW".

Your code calls a number of external procedures that you didn't post, so I
don't know what they do. In some cases I can guess; however, there could
of course be things happening in those procedures that are relevant to the
issue. For me to figure out what is happening, I'd need the code for at
least the routines "frmDirty" and "InitNewRecord".

Better than that would be for you to set a breakpoint in the code at the top
of this routine, then click the command button and, when the code stops at
the breakpoint, step through the code line by line to see exactly where it
goes. That, combined with your ability to examine the values of variables
and properties in debug mode, should probably enlighten you without my
needing to guess.

By the way, it looks to me as though you are doing a lot of work that you
probably don't need to do -- that you could probably let the form's natural
events handle a lot of the work. But that's a subject for a different
discussion.

Is there a way to not load any record into a form when the form first
loads.

Yes, you can set the form's Data Entry property to Yes in the form's
property sheet in design time, or you can explicitly open the form for data
entry using DataMode:=acFormAdd in the DoCmd.OpenForm statement, or you can
set the form's recordsource to a query that selects all the fields from the
desired tables but has a criterion that returns no records; e.g., "SELECT
.... WHERE 1 = 0".

It seems to load the last record in the table unless specified otherwise
in
the parent program's DoCmd.OpenForm.

Normally a form that is opened to show all records will initially show the
one with the lowest primary key, unless it has an Order By property in
effect or is otherwise explicitly ordered.

I use this same code on other forms (minus the mentioned recent changes)
and
it works for new records there.

Something's different.

 

[BBC via AccessMonster.com]

The 2 SUBs are basic, the frmDirty is used to manage the navagation buttons
(enabel/disable) when the form goes dirty (via Form_Dirty, [any
fields/controls]_Dirty and my dirtying/clearing [fields/controls] on the
form. The second InitNewRecd is setting some values into comboboxs, etc.

Private Sub frmDirty(isDirty As Boolean)
If isDirty And RecdDirty Then Exit Sub
fSelectRecd.SetFocus
RecdDirty = isDirty
DirtyFlag.Visible = isDirty
fFirstRecd.Enabled = Not isDirty
fPrevRecd.Enabled = Not isDirty
fNextRecd.Enabled = Not isDirty
fLastRecd.Enabled = Not isDirty
fDeleteRecd.Enabled = Not isDirty
fNewRecd.Enabled = Not isDirty
End Sub

for InitNewRecd below (I am in QuickEntry mode (ie True))
-SelectRecd is a combo used to select the client ID (not transaction's
primary key)
for this transaction
-ClientID is whom this transaction will be assigned to (above)
- the ....LookUps are comboboxes set to display nothing to start (but
are populated)

Private Sub InitNewRecd()
If QuickEntry Then
If fSelectRecd.Value > 0 Then
ClientID = fSelectRecd.Value
frmDirty (True)
End If
Else
ClientID = Forms("client").ClientID
fSelectRecd = ClientID
End If
CCCompany.Locked = Not (AmtMedia = "CreditCard")
CCExpiry.Locked = Not (AmtMedia = "CreditCard")
cSponsorLookUp = -1
cEventLookup = -1
cFollowUpLookup = -1
' Me.Requery
fSelectRecd.SetFocus
End Sub

I have tracked the code line by line (over & over ... again) and see nothing
unusual happening except that after the

Private Sub fNewRecd_Click()
Dim Recdsave As Integer
If Not Me.NewRecord Then
Recdsave = Proceed(RecdDirty)
If Recdsave = vbCancel Then Exit Sub
If Recdsave = vbYes Then
fSaveRecd_Click
' Else
' On Error Resume Next
' If Me.Dirty Then DoCmd.RunCommand acCmdUndo
End If

On Error GoTo fNewRecd_Click_Err
DoCmd.GoToRecord , "", acNewRec
End If
frmDirty (False)
InitNewRecd
Exit Sub

fNewRecd_Click_Err:
MsgBox Error$
End Sub

is executed the form is unchanged with all the data from the previous record
still there including the its primary key (it has been saved though [also
because to get the NEW button active I must have done SAVE or UNDO (as per
frmDirty)]

This form serves double duty, for new clients (or one-off entries) it comes
via the client form with the client number already provided by the OPEN FORM.
In this mode you can edit all existing entries for that selected client or
add new ones to them. it uses a combobox to select treansactions to edit or
NEW.
In QuickEntry mode where you have many transactions for numerous clients (AND
they already exist) it uses the same combobx but now with the client as the
selection and every transaction record is NEW. When I added this capability
(trying to have only one form to maintain for transaction entry) is when all
this trouble started (always having to start on a blank entry before the user
even selects a client to add the transactions to).
I now wish I'd used 2 separate forms even though they would be identical
except for that combobox and the NEW record processing.

I really do appreciate all you help here.

OK, despiration is setting in.
I now know why the form is dirty from the start, I was setting the

[quoted text clipped - 46 lines]

form or someting? I use this SUB to initialize the form to a blank record
when it loads (works) but it doesn't work on the next "NEW".

Your code calls a number of external procedures that you didn't post, so I
don't know what they do. In some cases I can guess; however, there could
of course be things happening in those procedures that are relevant to the
issue. For me to figure out what is happening, I'd need the code for at
least the routines "frmDirty" and "InitNewRecord".

Better than that would be for you to set a breakpoint in the code at the top
of this routine, then click the command button and, when the code stops at
the breakpoint, step through the code line by line to see exactly where it
goes. That, combined with your ability to examine the values of variables
and properties in debug mode, should probably enlighten you without my
needing to guess.

By the way, it looks to me as though you are doing a lot of work that you
probably don't need to do -- that you could probably let the form's natural
events handle a lot of the work. But that's a subject for a different
discussion.

Is there a way to not load any record into a form when the form first
loads.

Yes, you can set the form's Data Entry property to Yes in the form's
property sheet in design time, or you can explicitly open the form for data
entry using DataMode:=acFormAdd in the DoCmd.OpenForm statement, or you can
set the form's recordsource to a query that selects all the fields from the
desired tables but has a criterion that returns no records; e.g., "SELECT
... WHERE 1 = 0".

It seems to load the last record in the table unless specified otherwise
in
the parent program's DoCmd.OpenForm.

Normally a form that is opened to show all records will initially show the
one with the lowest primary key, unless it has an Order By property in
effect or is otherwise explicitly ordered.

I use this same code on other forms (minus the mentioned recent changes)
and
it works for new records there.

Something's different.

 

[Dirk Goldgar]

I have tracked the code line by line (over & over ... again) and see
nothing
unusual happening except that after the

Private Sub fNewRecd_Click()
Dim Recdsave As Integer
If Not Me.NewRecord Then
Recdsave = Proceed(RecdDirty)
If Recdsave = vbCancel Then Exit Sub
If Recdsave = vbYes Then
fSaveRecd_Click
' Else
' On Error Resume Next
' If Me.Dirty Then DoCmd.RunCommand acCmdUndo
End If

On Error GoTo fNewRecd_Click_Err
DoCmd.GoToRecord , "", acNewRec
End If
frmDirty (False)
InitNewRecd
Exit Sub

fNewRecd_Click_Err:
MsgBox Error$
End Sub

is executed the form is unchanged with all the data from the previous
record
still there including the its primary key (it has been saved though [also
because to get the NEW button active I must have done SAVE or UNDO (as per
frmDirty)]

The logic flow isn't completely clear to me, but when you stepped through
the code, was the line,

DoCmd.GoToRecord , "", acNewRec

actually executed? If so, the form should either have moved to a new
record, or else an error message should have been displayed by your
error-handling block. If the line was *not* executed, then there's an error
in your flow logic somewhere.

 

[Tony Toews [MVP]]

I now know why the form is dirty from the start,

You can see when the form becomes dirty by watching the record
selector column on the left hand side of your form. (You may need to
enable this if you've turned it off.) If the symbol is a right
facing triangle it's not dirty. If the symbol is a pencil then it's
dirty.

Tony

 

[BBC via AccessMonster.com]

Well have made some progress but things still happen I can't trace or don't
understand. I'm not even clear on why some of the changes I've made have
made it better (scary). I keep wondering if the Form_BeforeUpdate is a place
I can get control of things but any attempts to set CANCEL=TRUE under
specific circumstance has led to errors message on one or other of my NEW,
SAVE,UNDO DELETE commands
A couple of hurdles that are currently causing some grief are:
A) A new record is entered and ends up in one of 2 known states;
1) it is dirty but not been saved yet
2) dirty and has been saved
The user now decides to abandon this record completely (wants to get rid of
it). How do I eliminate (delete) that record and make the screen blank for
the next/new record for each case above.

For scenario 1 it does
-my own delete warning message
-executes my delete code
( but the record IS actually added to the DB although
never actively saved (by my code) and it ALSO REMAINS visable on
the form)

For scenario 2 it does
-my delete warning message (yes)
-the record then goes NEW (the primary key says NEW)
-then the system delete warning message appears (You are about to delete 1
records) (yes)
-then gives "The command or action DeleteRecord is not available now" (ok)
-then goes back to a normal state with a NEW record
-the record is not in the DB
--So scenario 2 sort of works but I get the system warning and then the
error message, almost like it's doing it twice

Private Sub fDeleteRecd_Click()
Dim Answr As Integer
Answr = DeleteOK(RecdDirty) ' my "is OK to delete" message
If Answr = vbOK Then
On Error GoTo fDeleteRecd_Click_Err
DoCmd.RunCommand acCmdDeleteRecord
End If

' If (Form.NewRecord Or Not Form.Dirty) Then Beep ' testing point
Call frmDirty(False, NoNavigation) 'enable navigation & other controls
(in this case nothing)
Exit Sub

fDeleteRecd_Click_Err:
MsgBox Error$
End Sub

Any suggestions appreciated (some of the automatic things Access does are
very painful)

I have tracked the code line by line (over & over ... again) and see
nothing

[quoted text clipped - 28 lines]

because to get the NEW button active I must have done SAVE or UNDO (as per
frmDirty)]

The logic flow isn't completely clear to me, but when you stepped through
the code, was the line,

DoCmd.GoToRecord , "", acNewRec

actually executed? If so, the form should either have moved to a new
record, or else an error message should have been displayed by your
error-handling block. If the line was *not* executed, then there's an error
in your flow logic somewhere.

 

[Dirk Goldgar]

Well have made some progress but things still happen I can't trace or
don't
understand. I'm not even clear on why some of the changes I've made have
made it better (scary). I keep wondering if the Form_BeforeUpdate is a
place
I can get control of things but any attempts to set CANCEL=TRUE under
specific circumstance has led to errors message on one or other of my NEW,
SAVE,UNDO DELETE commands
A couple of hurdles that are currently causing some grief are:
A) A new record is entered and ends up in one of 2 known states;
1) it is dirty but not been saved yet
2) dirty and has been saved
The user now decides to abandon this record completely (wants to get rid
of
it). How do I eliminate (delete) that record and make the screen blank
for
the next/new record for each case above.

For scenario 1 it does
-my own delete warning message
-executes my delete code
( but the record IS actually added to the DB although
never actively saved (by my code) and it ALSO REMAINS visable on
the form)

For scenario 2 it does
-my delete warning message (yes)
-the record then goes NEW (the primary key says NEW)
-then the system delete warning message appears (You are about to delete 1
records) (yes)
-then gives "The command or action DeleteRecord is not available now" (ok)
-then goes back to a normal state with a NEW record
-the record is not in the DB
--So scenario 2 sort of works but I get the system warning and then the
error message, almost like it's doing it twice

Private Sub fDeleteRecd_Click()
Dim Answr As Integer
Answr = DeleteOK(RecdDirty) ' my "is OK to delete" message
If Answr = vbOK Then
On Error GoTo fDeleteRecd_Click_Err
DoCmd.RunCommand acCmdDeleteRecord
End If

' If (Form.NewRecord Or Not Form.Dirty) Then Beep ' testing point
Call frmDirty(False, NoNavigation) 'enable navigation & other controls
(in this case nothing)
Exit Sub

fDeleteRecd_Click_Err:
MsgBox Error$
End Sub

Any suggestions appreciated (some of the automatic things Access does are
very painful)

Without seeing all the code in the form's module -- and no, I don't want to
<g> -- I can't say for sure exactly what's happening with your form.
However, I can make a suggestion for how to handle the situation you
describe with your delete button. Specifically, you want the current record
to "go away", regardless of whether it's a new record or an existing record,
and whether it's dirty or not -- and you don't want to generate an error if
you're already on the new record and it hasn't been modified yet.

For this purpose, the general logic to follow is this:

If you're on a new record and it's not dirty, do nothing
Else
If (user confirms the delete) Then
Undo and changes to the current record.
If you're on a new record, you're done
Else
Delete the current record
Go to the new record (or whatever record you want)
End If
End If
End If

Here's an attempt to adapt your code for fDeleteRecd_Click to this logic:

'------ start of revised code ------
Private Sub fDeleteRecd_Click()

On Error GoTo Error_Handler

If Me.NewRecord And Not Me.Dirty Then
' Do nothing; there's nothing to delete.
Else
If DeleteOK(RecdDirty) = vbOK Then

' Undo any pending changes to this record.
Me.Undo

' If we're on the new record, we're done.
' If we're on an existing record, delete it.
If Not Me.NewRecord Then
' Turn off warnings so the user doesn't get a second prompt.
DoCmd.SetWarnings False
RunCommand acCmdDeleteRecord
' Turn warnings back on.
DoCmd.SetWarnings True
' Go to a new record. Ignore error if we're there already.
On Error Resume Next
RunCommand acCmdRecordsGoToNew
End If

'enable navigation & other controls (in this case nothing)
Call frmDirty(False, NoNavigation)

End If
End If

Exit_Point:
Exit Sub

Error_Handler:
' Don't let the routine exit without turning warnings back on.
DoCmd.SetWarnings True
' Display error message.
MsgBox Error$
Resume at the routine's cleanup point.
Resume Exit_Point

End Sub
'------ end of revised code ------

Now, I can make no promises about this code, because there could easily be
things I don't understand about your form and the rest of your code. But
you should at least see how this version implements the necessary logic.

 

[BBC via AccessMonster.com]

Thanks, I'll work on this and I may ask for a little input on my other
controls (fUndo, fSave, fNew, form_exit) sometime later as I'll likley want
to re-address them as well. In some other samples I've seen (as per your
code just below)

Exit_Point:
Exit Sub

Error_Handler:
' Don't let the routine exit without turning warnings back on.
DoCmd.SetWarnings True
' Display error message.
MsgBox Error$
Resume at the routine's cleanup point.
Resume Exit_Point

End Sub

I see that they almost always go back to the normally "successful"
"Exit_Point" to exit rather than just letting it exit the SUB via the END SUB.
Is this just good coding practice or are there consequences to letting it
fall out.
Should I also set ON ERROR GO TO 0 on exiting (until I have a global error
handler). I did have an error reported "as if" it was in one of these
routines but on tracing it, it occured elsewhere after one of these was
executed.

On my fSaveRecd I'd like to get back to the selected control that had focus
jut before the SAVE was clicked. I tried using DoCmd.GoToControl Screen.
PreviousControl.Name but it said the control didn't exist on the form.
But it does and on "hover" it shows the correct name exactly as it appears on
the form (it is a combobox bound to the table).

Well have made some progress but things still happen I can't trace or
don't

[quoted text clipped - 51 lines]

Any suggestions appreciated (some of the automatic things Access does are
very painful)

Without seeing all the code in the form's module -- and no, I don't want to
<g> -- I can't say for sure exactly what's happening with your form.
However, I can make a suggestion for how to handle the situation you
describe with your delete button. Specifically, you want the current record
to "go away", regardless of whether it's a new record or an existing record,
and whether it's dirty or not -- and you don't want to generate an error if
you're already on the new record and it hasn't been modified yet.

For this purpose, the general logic to follow is this:

If you're on a new record and it's not dirty, do nothing
Else
If (user confirms the delete) Then
Undo and changes to the current record.
If you're on a new record, you're done
Else
Delete the current record
Go to the new record (or whatever record you want)
End If
End If
End If

Here's an attempt to adapt your code for fDeleteRecd_Click to this logic:

'------ start of revised code ------
Private Sub fDeleteRecd_Click()

On Error GoTo Error_Handler

If Me.NewRecord And Not Me.Dirty Then
' Do nothing; there's nothing to delete.
Else
If DeleteOK(RecdDirty) = vbOK Then

' Undo any pending changes to this record.
Me.Undo

' If we're on the new record, we're done.
' If we're on an existing record, delete it.
If Not Me.NewRecord Then
' Turn off warnings so the user doesn't get a second prompt.
DoCmd.SetWarnings False
RunCommand acCmdDeleteRecord
' Turn warnings back on.
DoCmd.SetWarnings True
' Go to a new record. Ignore error if we're there already.
On Error Resume Next
RunCommand acCmdRecordsGoToNew
End If

'enable navigation & other controls (in this case nothing)
Call frmDirty(False, NoNavigation)

End If
End If

Exit_Point:
Exit Sub

Error_Handler:
' Don't let the routine exit without turning warnings back on.
DoCmd.SetWarnings True
' Display error message.
MsgBox Error$
Resume at the routine's cleanup point.
Resume Exit_Point

End Sub
'------ end of revised code ------

Now, I can make no promises about this code, because there could easily be
things I don't understand about your form and the rest of your code. But
you should at least see how this version implements the necessary logic.

 

[Dirk Goldgar]

In some other samples I've seen (as per your
code just below)


I see that they almost always go back to the normally "successful"
"Exit_Point" to exit rather than just letting it exit the SUB via the END
SUB.
Is this just good coding practice or are there consequences to letting it
fall out.

It's good coding practice, because the Resume statement cleans up the stack
and the internal error-handling structures. I don't *think* it should be
strictly required if all you're going to do is exit the procedure, because I
would expect that cleanup to also be a part of the procedure exit logic.
However, I'm not completely sure of that, and I consider the effort of
coding a Resume statement to be small price to pay for the security of
knowing I've terminated the error properly.

Should I also set ON ERROR GO TO 0 on exiting (until I have a global
error
handler).

No, that's not necessary. The scope of an On Error statement never exceeds
the scope of the procedure in which it is executed.

I did have an error reported "as if" it was in one of these
routines but on tracing it, it occured elsewhere after one of these was
executed.

I'm not sure what happened there, and would have to have seen the code and
the trace to explain it.

On my fSaveRecd I'd like to get back to the selected control that had
focus
jut before the SAVE was clicked. I tried using DoCmd.GoToControl
Screen.
PreviousControl.Name but it said the control didn't exist on the form.
But it does and on "hover" it shows the correct name exactly as it appears
on
the form (it is a combobox bound to the table).

You really should start new discussion threads for new questions. However,
you may find that

Screen.PreviousControl.SetFocus

works better than DoCmd.GoToControl. I never use GoToControl; it's prone
to not understanding which form or subform the control is on. Using
<controlreference>.SetFocus lets me specify exactly which control should get
the focus.

 

[BBC via AccessMonster.com]

Thanks for all your help Dirk
Hopefully working through this "delete" process will fix the immediate
problems and help me resolve the others for the related controls.

In some other samples I've seen (as per your
code just below)

[quoted text clipped - 17 lines]

Is this just good coding practice or are there consequences to letting it
fall out.

It's good coding practice, because the Resume statement cleans up the stack
and the internal error-handling structures. I don't *think* it should be
strictly required if all you're going to do is exit the procedure, because I
would expect that cleanup to also be a part of the procedure exit logic.
However, I'm not completely sure of that, and I consider the effort of
coding a Resume statement to be small price to pay for the security of
knowing I've terminated the error properly.

Should I also set ON ERROR GO TO 0 on exiting (until I have a global
error
handler).

No, that's not necessary. The scope of an On Error statement never exceeds
the scope of the procedure in which it is executed.

I did have an error reported "as if" it was in one of these
routines but on tracing it, it occured elsewhere after one of these was
executed.

I'm not sure what happened there, and would have to have seen the code and
the trace to explain it.

On my fSaveRecd I'd like to get back to the selected control that had
focus

[quoted text clipped - 4 lines]

on
the form (it is a combobox bound to the table).

You really should start new discussion threads for new questions. However,
you may find that

Screen.PreviousControl.SetFocus

works better than DoCmd.GoToControl. I never use GoToControl; it's prone
to not understanding which form or subform the control is on. Using
<controlreference>.SetFocus lets me specify exactly which control should get
the focus.

 

[BBC via AccessMonster.com]

Delete now seems to work perfectly
thanks very much

In some other samples I've seen (as per your
code just below)

[quoted text clipped - 17 lines]

Is this just good coding practice or are there consequences to letting it
fall out.

It's good coding practice, because the Resume statement cleans up the stack
and the internal error-handling structures. I don't *think* it should be
strictly required if all you're going to do is exit the procedure, because I
would expect that cleanup to also be a part of the procedure exit logic.
However, I'm not completely sure of that, and I consider the effort of
coding a Resume statement to be small price to pay for the security of
knowing I've terminated the error properly.

Should I also set ON ERROR GO TO 0 on exiting (until I have a global
error
handler).

No, that's not necessary. The scope of an On Error statement never exceeds
the scope of the procedure in which it is executed.

I did have an error reported "as if" it was in one of these
routines but on tracing it, it occured elsewhere after one of these was
executed.

I'm not sure what happened there, and would have to have seen the code and
the trace to explain it.

On my fSaveRecd I'd like to get back to the selected control that had
focus

[quoted text clipped - 4 lines]

on
the form (it is a combobox bound to the table).

You really should start new discussion threads for new questions. However,
you may find that

Screen.PreviousControl.SetFocus

works better than DoCmd.GoToControl. I never use GoToControl; it's prone
to not understanding which form or subform the control is on. Using
<controlreference>.SetFocus lets me specify exactly which control should get
the focus.

 

[BBC via AccessMonster.com]

Dirk, one more question related to this, to clarify what "Me.NewRecord" fully
means. I gather it means that the record is newely created and has not (ever)
been saved but may or may not be "dirty"
Am I correct?

Delete now seems to work perfectly
thanks very much
[quoted text clipped - 39 lines]

<controlreference>.SetFocus lets me specify exactly which control should get
the focus.

 

[Dirk Goldgar]

Dirk, one more question related to this, to clarify what "Me.NewRecord"
fully
means. I gather it means that the record is newely created and has not
(ever)
been saved but may or may not be "dirty"
Am I correct?

Yes, exactly. If you look it up in the Access help file (and can find it),
you'll see the "You can use the NewRecord property to determine whether the
current record is a new record," that it has these possible values:

Setting Description
---------- ----------------------------------------
True The current record is new.
False The current record isn't new.

And also, "When a user has moved to a new record, the NewRecord property
setting will be True whether the user has started to edit the record or
not."

 

[BBC via AccessMonster.com]

As I suspected, thanks again

Yes, exactly. If you look it up in the Access help file (and can find it),
you'll see the "You can use the NewRecord property to determine whether the
current record is a new record," that it has these possible values:

Setting Description
---------- ----------------------------------------
True The current record is new.
False The current record isn't new.

And also, "When a user has moved to a new record, the NewRecord property
setting will be True whether the user has started to edit the record or
not."