2003: record writes through form

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

Guest

Hi,
It's been bugging me, OK, a frmTransX, has a mere 354 records to its credit. The table is tblTransX, the pkey and a date and memo fields. TransXDetail is many-to-many also with tblAccts.
It has a DoCmd.Save button even, but still, I'll be filling out a new record, to go to tblTransX, with tblTransXDetails . . .
And later or right away I notice the thing has forgotten what I put in the edit controls.
If this makes no sense, please pardon me. I do not automatically get a new AutoNumberwhen I mash asterisk. Reader, do you know how one might instruct the form to finalize a new record before I fill-out the form, so I don't have to worry about whether it picked up the stuff entered in the form?
 
Jim Shores said:
Hi,
It's been bugging me, OK, a frmTransX, has a mere 354 records to
its credit. The table is tblTransX, the pkey and a date and memo
fields. TransXDetail is many-to-many also with tblAccts. It has a
DoCmd.Save button even, but still, I'll be filling out a new
record, to go to tblTransX, with tblTransXDetails . . . And later or
right away I notice the thing has forgotten what I put in the edit
controls. If this makes no sense, please pardon me. I do not
automatically get a new AutoNumberwhen I mash asterisk. Reader, do
you know how one might instruct the form to finalize a new record
before I fill-out the form, so I don't have to worry about whether it
picked up the stuff entered in the form?
Click to expand...

Your question is a little unclear, but one thing you may not be aware of
is that the statement DoCmd.Save does *not* save the form's current
record. It saves the *design* of the form, not its data. If you need
to use code to save the current record before Access would normally do
so, use

RunCommand acCmdSaveRecord

or

Me.Dirty = False

(I like "Me.Dirty = False", but if the record can't be saved for some
reason, the error message you get is a little misleading -- it talks
about being unable to set a property, rather than being unable to save
the record.)

Normally, Access will save the form's current record automatically (if
it has been modified) whenever you move to a different record, or close
the form, or switch the focus from the main form to a subform. So I'm
not sure why you would be having records that aren't saved eventually,
if not when you click your save button.
 
I just haven't the grasp yet of objects to have imagined the Me.Dirty property/method. D., I do have a stack of tickets backing up and the Access form I built is kind of peculiar. Earlier, if I moved either of the main table feilds' edit control text so much as a space, (and then back --they are just date and memo fields), then, that, and the stuff in the subform(s), many-to-manys', would be definitely remembered.
Now, there is the trigger in the update events. What do you think about putting instructions there to save the record? I should like to be able to demand a new autonumber before I proceed to fill the form out?
 
Jim Shores said:
I just haven't the grasp yet of objects to have imagined the Me.Dirty
property/method. D., I do have a stack of tickets backing up and
the Access form I built is kind of peculiar. Earlier, if I moved
either of the main table feilds' edit control text so much as a
space, (and then back --they are just date and memo fields), then,
that, and the stuff in the subform(s), many-to-manys', would be
definitely remembered. Now, there is the trigger in the update
events. What do you think about putting instructions there to save
the record? I should like to be able to demand a new autonumber
before I proceed to fill the form out?
Click to expand...

I'm afraid you're not giving me enough information to know what's best
for you to do. Perhaps if you described the tables involved, the
relevant fields, the forms and subforms that are representing them and
what fields they're linked on (with the relevant controls), and then
told me what behavior you are getting and how it is different from the
behavior you want, then I could give you worthwhile advice. At the
moment, you're writing way in advance of my ability to imagine your
setup.
 
Thanks man.
In my book you are a hCruiser, working these hours. I appreciate it.
I don't want to paste the block and expect you to debug it. It's embarrassing.
TRY i open access. i open frmTransX. I select the asterisk record selector there on the right. New record; ctl says 'autonumber': Two fields one can edit on this main form --just date and memo. Well, the form has two subforms, both devoted to many-to-many tables. The second subform, tblPurchaseDetail's, is optional with a chkbox and even as I say this I have a unformable suspiscion
subForm One is important. And it, tblTransXDetails, is the one I notice blanking if i perambulate. That's why I figure if I could make that '(autonumber)' that appears in mainform ctl into actual new record number, the thing would conform.
If it doesn't make you mad I'll keep trying to say exactly what I mean, thanks again
Yep, definitely, re-reading your words, I can see your general situation. In the win16 daze, nobody would be pasting chunks into these little boxes. I could cut the fluff out tomorrow, but the picture og the table relations i don't know how to debug.print ala Dobson
 
Jim Shores said:
Thanks man.
In my book you are a hCruiser, working these hours. I appreciate it.
I don't want to paste the block and expect you to debug it. It's
embarrassing.
TRY i open access. i open frmTransX. I select the asterisk record
selector there on the right. New record; ctl says 'autonumber':
Two fields one can edit on this main form --just date and memo.
Well, the form has two subforms, both devoted to many-to-many
tables. The second subform, tblPurchaseDetail's, is optional with a
chkbox and even as I say this I have a unformable suspiscion subForm
One is important. And it, tblTransXDetails, is the one I notice
blanking if i perambulate. That's why I figure if I could make that
'(autonumber)' that appears in mainform ctl into actual new record
number, the thing would conform. If it doesn't make you mad I'll keep
trying to say exactly what I mean, thanks again Yep, definitely,
re-reading your words, I can see your general situation. In the
win16 daze, nobody would be pasting chunks into these little boxes.
I could cut the fluff out tomorrow, but the picture og the table
relations i don't know how to debug.print ala Dobson
Click to expand...

I'm still not sure exactly what's going on, Jim, but it may be that you
are filling out tblTransXDetails (on the subform) before you have filled
out the main form. In that case, you'd be filling out detail records
that are not related to the parent record, and they would thus not show
up when you move away from that main record and then come back to it.

This would only be possible if the foreign-key field in that table --
that is, the field that links it to the main form's table -- is not part
of the table's primary key, or if it has its Default Value property set.
These would be things you can check in the design of tblTransXDetails.

Does this problem occur if you actually enter something in the date or
memo field on the main form before entering any records in the subform?
It's not enough for those fields to have default values -- you have to
actually "touch them" somehow, to mark the record as modified so that
its autonumber key field is actually assigned a value, and so that the
record will be saved when you move the focus to the subform.
 
Still, it's mysterious to me; well, there is no way for me to ever comprehend how the program may order, "a form's recognition of its multiple subforms." I'm just glad to be here and frankly, thanks to this community, not sorry I skipped 1993-2003. Between yourself and Allen Browne, I expect I see enough to go, further

Jimbo
on Project MÅbeel.mdb.etal
 
Back
Top