Re: Problems Saving Multiple Unbound Fields to a Table

Per TORQUE:
When I click the SAVE button, an error pops up ( Object Required ).

Im assuming that it is because some fields are blank.

It would help nail it down to know which statement the error was being thrown
on.

But, assuming it's a Null (not blank) field; it sounds like you need a bunch of
"IF" statements.

e.g.
----------------------------------------
With Me.chkWhatever
If Not IsNull(.Value) Then
MyRS.Whatever = .Value
End if
End With
----------------------------------------

alternatively:
----------------------------------------
With Me.chkWhatever
If Len(.Value & "") > 0 Then
MyRS.Whatever = .Value
End if
End With
----------------------------------------



How about expanding your error trapping code so that
it tells what line it's dying on?

e.g.
---------------------------------------------------
Private Sub Command226_Click()
On Error GoTo Command226_Click_err.
..
..
..
..
..

Command226_Click_xit:
Exit Sub

Command226_Click_err:
MsgBox "Line " & Erl & ": Error " & Err & "(" & Error$ & ")."
Resume Command226_Click_Err_xit
---------------------------------------------------

Also, save yourself a lot of grief later on and assign more meaningful control
names.

Command_266 and it's cohorts will drive you nuts three months from now when you
have to figure out what's going on in the code. "cmdSave" works a *lot*
better.



Finally, prefix all of those other object names with something that tells what
kind of control they are:
--------------------------
txt = TextBox
cmd = CommandButton
tgl = Toggle
chk = Checkbox
lst = ListBox
cbo = ComboBox
opt = OptionGroup
rad = RadioButton
frm = Form
qry = Query
tbl = core table
tlkp = lookup table
stbl = table used only by applicatin (no user data)
.... and so-forth
--------------------------

Some benefits from that practice:
-------------------------------------------------------------------------
1) Reading the code, you have an idea what kind of values to expect.
e.g. normally you would only expect True and False in a CheckBox and
code that provides for anything else - except as error trapping -
is suspect.

2) Sometimes MS Access can get confused between the control name and the
name of the .ControlSource. The prefixes remove any doubt as to
what is being referred to.

3) In the case of tables and queries, MS Access sometimes presents both
types of objects in the same list. Prefixes let you know which type
you're looking at.
-------------------------------------------------------------------------
--
PeteCresswell
.