Re: Subform trouble for New User
- From: "E.Q." <EQ@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Fri, 3 Feb 2006 03:50:09 -0800
"Dirk Goldgar" wrote:
"E.Q." <EQ@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in messageThat is the exact message of the error. I work on a couple different
news:174C5DA8-9789-4D9D-91BA-2CECAC236D77@xxxxxxxxxxxxx
I'm still struggling with my second problem. I added the txt
control as suggested. Access displays a message saying "You must add
tblLogIn_ID to your record source if you want to use this link." I
added that field to the query used to generate the subform, but the
result was that instead of getting a continuous form with all
operator log entries, it was limited to the log entries corresponding
to the specific shift identified by the tblLog_ID field (even though
I didn't use that field in the Subform Field Linker).
No, the technique I proposed would not have forced you to add anything
to your recordsource. I think you made a mistake in implementing it.
It's also possible I didn't understand what you're trying to accomplish,
but the technique does work.
Was that the exact error message you got? I've never seen one phrased
like that. What version of Access are you using? When did you get the
error message? What exactly did you put as the controlsource for the
linking text box, and what did you set as the Link Master and Child
Fields properties of the subforms?
machines. The old one in the field has Access 2000, the newer one in my
office has Access 2003. I think I initially started working on the project
while out in the field, but the error came up on the newer machine. The
control source for the linking textbox is: =fsubEventDetail.Form!txtPPLogID
I've tried to enter "txtSubformLink" as the master and idsPPLogID as the
child links, but I get a different error message: "The text you entered isn't
an item on the list. Select an item on the list or enter text that matches
on of the listed items."
In general yes one subform is a condensed version of the other. TheI'm not sure if my design is the best structure here. My though is
to have two tabs; one tab will provide the place for data entry as
well as provide a space for detail. The structure of this tab is
three fields that identify the date, shift, and operator name along
with a continuous subform that uses multiple lines to provide detail
for a full log entry. The other tab has a subform set up as a
continuous form.I have limited the fields in the continuous form to
fit on one line. I'd like to be able to switch between the two tabs
smoothly (from the users perspective).
So the other subform is just a condensed version of the first? Or have
I missed something?
"detail" subform contains a timestamp, a boolean (though I may add more
later), but the big thing is a memo field. (Most log entries are short, but
I wanted to add a memo field for the more loquacious notes that some of my
operators make on occassion. I want to accommodate both the occassional need
for a long log entry with the daily need to review all log entries since the
last time the operator worked a particular work area.)
The database consist of six tables, two are to fill in combo boxes, one was
I'm wondering if I might need to give up on the continuous form in the
"details" tab. I'd like to have it since it would be a way to review
all log entries an operator made on one particular shift. (I showed
it to a couple operators who liked that structure as opposed to one
record per form). But they would have the continous form to scan the
last few entries, they would just need to click the mouse a couple
more times to see all the fields on multiple records.
I don't know enough to say whether your concept is a good one or a bad
one. I still don't have a very clear picture of what this is intended
to look like, and of the structure of the underlying data. What are the
tables involved, and what are the recordsources of the main form and
each subform?
generated by Access by the import wizard, though that one isn't used.
Another was imported from another application and is queried to provide the
operator ID. That leaves tblLogIn, which has fields idsID, chrShift,
chrOperator, and dtmDate. And tblEventLog with fields idsPPLogID, dtmTime,
chrArea, chrObject, blnW/O, chrEventHeadline, and memEventDetail.
The main form is called frmShiftDetail. It has a tab control with two tabs.
On the tab labled "Detail" are the controls: txtDate (from
tblLogIn.dtmDate), cboShift(from tblLogIn.chrShift), cboOperator (from
tblLogIn.chrOperator), subform fsubEventDetail, and now txtSubformLink. That
subform has controls dtmTime, cboArea, cboObject, blnW/O, txtEvent Headline,
txtEventDetail all from tblEventLog. This is set up as a continuous form.
Its Master LInk is iidsID, and child link is intLogIn_Id It's a nice set-up
because one screen can usually hold all entries from the shift defined by
Date and shift.
The other tab, labled "Overview" only holds fsubEvent_Overview. This
continuous subform has only six controls txtDate, cboShift, cboOperator, all
from tblLogIn and cboArea, cboArea, cboObject, and txtEvent Headline, all
from tbl_Event Log.
When I created the form, I toggled off the data entry, deleting, and
addition capabilites.
Individually, each tab look OK and seems to function as I would like. The
problem is that the tabs aren't linked. (I did try to link through
tblLogIn.idsID but that ended up filtering the continuous form to only those
events that occurred on the shift specified on the "details" tab.
--.
Dirk Goldgar, MS Access MVP
www.datagnostics.com
(please reply to the newsgroup)
- References:
- Re: Subform trouble for New User
- From: E.Q.
- Re: Subform trouble for New User
- From: Dirk Goldgar
- Re: Subform trouble for New User
- Prev by Date: Re: Control on form not always displaying data
- Next by Date: Re: Form Shifts Position when Opening
- Previous by thread: Re: Subform trouble for New User
- Next by thread: Form Shifts Position when Opening
- Index(es):
Relevant Pages
|
