Part III: More-Advanced Access Techniques
786
Editing data
The last action you need to provide for in your unbound form is editing. You must be able to add,
remove, edit, and save data. The Employees form does all these things (except deletions, but that
can be accomplished using the Delete method and the examples shown here). Although writing
routines really isn’t that involved, these routines are the reason that you created an unbound form
in the first place. Because they don’t take any action on the recordset until update time, your users
shouldn’t have trouble with locks.
When someone clicks on the Add button, a couple things happen:
l The controls on the form are selectively enabled or disabled. By default, this form is
set to browse data, as evidenced by the disabled data-entry fields and disabled Save com-
mand button. When an add takes place, the data-entry fields and Save button are enabled,
but everything else is disabled (to keep users from wandering until the add is successfully
completed). When the user types information into form controls, he’s really just typing
the data into placeholders. No action has occurred in the recordset.
l A value is set to indicate what kind of action is in progress. To do this, the Save but-
ton’s Tag property is set to Add. Later, this value will be retrieved and sent to the update
routine.
When the Save button is clicked, its OnClick event runs the UnboundSave procedure, passing
the procedure the value of the button’s Tag property. Listing 21.8 shows the procedure.
LISTING 21.8
The UnboundSave Procedure
Function UnboundSave( _
frm As Form, _
frmRS As DAO.Recordset, _
lValue As Long, _
sAction As String) As Integer
Dim ws As Workspace
Dim ctlName As String
Dim ctl As Control
Dim x As Integer
On Error GoTo HandleError
frmRS.LockEdits = False ‘ Optimistic Locking
Set ws = DBEngine.Workspaces(0)
Select Case sAction
Case “Add”
ws.BeginTrans
frmRS.AddNew
For x = 0 To frmRS.Fields.Count - 1
ctlName = frmRS.Fields(x).Name
Set ctl = frm.Controls(ctlName)
