This line of code:
DoCmd.OpenForm "Risk_Tracker", , , "[Assoc_AC_Num_txt] =" & Me.SPR_Number
means essentially "Open the Risk_Tracker form, loading only the record in
which the field Assoc_AC_Num_txt is the same as SPR_Number from the calling
form (the form containing RiskBtn).
The assumptions behind the code as written are that Assoc_AC_Num_txt is a
field in the record source for Risk_Tracker, and that SPR_Number is a Number
field. If it is a text field you need to change the quotes:
DoCmd.OpenForm "Risk_Tracker", , , "[Assoc_AC_Num_txt] = " " " &
Me.SPR_Number & " " " "
or
DoCmd.OpenForm "Risk_Tracker", , , "[Assoc_AC_Num_txt] = ' " & Me.SPR_Number
& " ' "
(spaces between the quotes added for clarity)
Remember that Assoc_AC_Num_txt is a *field* in the called form's record
source, not a control on the called form. It could be the control and the
field have the same name (I prefer to avoid this), but it has to be a field,
whatever else it may be.
This is the correct order in the Where argument: First the field in the
called form's record source, then a field in the calling form's record
source or a control on the calling form.
Regarding this expression:
"[Me.ID] = 'ID'"
it should be:
"[ID] = 'ID'"
with this caveat: the syntax will work only if you are seeking the literal
value "ID". I described above the different approach to a number field and
a text field when you use the field's value rather than a literal value.
Regarding OpenArgs, I don't think this syntax will work:
stLinkCriteria = Form_IIRProblemReport1.[SPR Number]
The Me prefix identifies the current form (or report). If [SPR Number] is a
field in the form's record source or a control on the form you could have:
stLinkCriteria = Me.[SPR Number]
(or Me![SPR Number])
or you could do:
stLinkCriteria = Forms!Form_IIRProblemReport1![SPR Number]
There is no need I can see for the longer syntax in this case, since the
shorter version will work.
In any case, you need to be clear about whether you are using text or number
values. If you are using a number (long integer) value you should probably
declare it that way:
Dim stDocName As String
Dim lngLinkCriteria As Long
stDocName = "Risk_Tracker"
lngLinkCriteria = Me.[SPR Number]
DoCmd.OpenForm stDocName, OpenArgs:=lngLinkCriteria
Using the string may work, but it is best to be clear what type of value is
being used.
In any case, add a break point to be sure the OpenArgs value is what you
expect. To do this, open the code window, and click in the vertical bar
just to the left of the code, next to the line lngLinkCriteria = Me.[SPR
Number]. You should see a red dot in the bar, and the line of code should
be highlighted. Go to the form and run the code by clicking the command
button. The code will break at the break point you set. Press the F8 key
to step through the code one line at a time (use F5 to run through the code
either to the end or to the next break point). When you are past the
lngLinkCriteria = Me.[SPR Number] line, go back and hover the mouse over
lngLinkCriteria. You will see the value. That is the value being passed to
the called form.
Linda said:
Thank you all for the continued discussion. I have been trying the
various
suggestions but still can't quite get it right. I will include my code
for
my attempts below:
Bruce M: DoCmd.OpenForm "FormName", , ,"[SomeField] = " & Me.[SomeField]
My Code:
Private Sub RiskBtn_Click()
DoCmd.OpenForm "Risk_Tracker", , , "[Assoc_AC_Num_txt] =" & Me.SPR_Number
Assoc_AC_Num_txt is the name of the field on the 2nd form (called form)
SPR_Number is the name of the field on the main form
Result: A dialogue box pops up requesting Assoc_AC_Num_txt
Maverick: DoCmd.OpenForm "YourFormName", , , ,"[Me.ID] = 'ID'"
(note: the two suggestions seem opposite to me in what equals what)
My code:
Private Sub RiskBtn_Click()
DoCmd.OpenForm "Risk_Tracker", , , "[Me.SPR Number] = 'Assoc_AC_Num_txt'"
Result: Error "Invalid braceting of name '[Me.Spr Number]'.
Tried removing square brackets and got an error of missing operator.
Linq Adams: OpenArgs
My code: In Form IIRProblemReport1
Private Sub RiskBtn_Click()
On Error GoTo Err_RiskBtn_Click
Dim stDocName As String
Dim stLinkCriteria As String
stDocName = "Risk_Tracker"
stLinkCriteria = Form_IIRProblemReport1.[SPR Number]
DoCmd.OpenForm stDocName, OpenArgs:=stLinkCriteria
My Code: in Form Risk_Tracker
Private Sub Form_Open(Cancel As Integer)
If Len(Me.OpenArgs) > 0 Then
Me.Assoc_AC_Num_txt = Me.OpenArgs
End If
Result:
Opens the Risk_Tracker form but returns all of the records in the risk
table
with an Assoc_AC_Num equal to the number passed in from OpenArgs.
Desired result:
Risk_Tracker form would open displaying only those records that have the
same AC_Num as the record its called from in the main form. If none
exists,
a blank form would open. The risk tracker form needs to be able to open
from
the switchboard with no associated AC Number.
I've tried many "tweaks" to these but I just can't quite get it right.
Thanks so much for your help!
Linda
--
Linda
Maverick said:
I agree with everyone. OpenArgs would work, if done correctly. I did say
that
if Linda wanted to use an OpenArgs approach that she would need to have
an If
statement on the target form to check if there is a value for OpenArgs so
that the form could be opened as a stand alone.
Because everyone beat me to the question of seeing her code, I saw no
reason
to reiterate it.... only to offer another suggestion while waiting for
her
response.
:
I did say it would be best to see the code. Using the Where condition
involves one step, while OpenArgs involves passing the argument, then
acting
on it. IMHO, doing this in one step makes the most sense.
That being said, I agree that both will work if used properly, but
trying to
manipulate the recordset in the Open event will not, as it has not been
loaded. I should have mentioned that in my initial reply. Maybe they
should have been called LoadArgs to discourage the temptation to use
them in
the Open event. Oh well.
Either method is perfectly acceptable in this circumstance,
gentlemen.
Offering an alternative solution such as using the Where clause in
opening
the form is fine, but there occasions when OpenArgs is needed, so we
should
also try to figure out ***why*** it's not working for the OP by
examing
her
code.