Full Access Versus /Runtime

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

Guest

The following code returns valid values with full Access 2000 BUT "" when
run with the Access 2000 /Runtime set.

' Different Response with RUNTIME
'MsgBox "Full Access Versus RUNTIME." & vbCrLf & vbCrLf & _
"Anticipated Payment Method is " & is_Actual_Payment_Method & vbCrLf
& _
"Greater to be used is " & ib_Greater_To_Be_Used & vbCrLf & _
"No of Guarantee Rows is " & Str$(Val(Nz
(Me.txt_Guarantee_Rows.value, "0"))) & vbCrLf & _
"No of Greater Rows is " & Str$(Val(Nz(Me.txt_Greater_Rows.value,
"0"))) & vbCrLf & _
"FSUB Greater Remuneration is " & Format$(Nz(Me!fsub_Greater.Form!
txt_Total_Remuneration.value, 0#), Decimal_Format) & vbCrLf & _
"FSUB Guarantee PayGTEE is " & Format$(Nz(Me!fsub_Hours.Form!
txt_paygtee.value, 0#), Decimal_Format), _
vbInformation + vbOKOnly, _
gs_Application_Name

The main form has a number of tabpages, each with a subform and appropriate
controls.

All performs correctly under Access 2000 but can not get any values with
/runtime

Any ideas?
 
You say this change occurs just by setting the /runtime switch, so
presumably this is on the same computer and there cannot be any difference
with the service packs, references, or timing.

What are is_Actual_Payment_Method and the other references?
The name of a control on the form?
The name of a field in the form's RecordSource?
Both a field and a control?
Does using Me.is_Actual_Payment_Method make a difference?
Is it a variable declared in the procedure? Declared at the module level? A
public variable declared in another module? An undeclared variable? Are you
using Option Explicit so Access cannot just create it on the fly?

In what event is this code executing?

What error handling is in use? Is it a resume with no notication, so you
would not know if an error were occuring the in runtime?
 
Allen Browne said:
You say this change occurs just by setting the /runtime switch, so
presumably this is on the same computer and there cannot be any difference
with the service packs, references, or timing.
Click to expand...

Yes, the same machine
What are is_Actual_Payment_Method and the other references?
Click to expand...

private is_Actual_Payment_Method as string (In ME) - Module Level
The name of a control on the form? No.
Click to expand...
The name of a field in the form's RecordSource?
Both a field and a control?
Does using Me.is_Actual_Payment_Method make a difference?
Is it a variable declared in the procedure? Declared at the module level? A
public variable declared in another module? An undeclared variable? Are you
using Option Explicit so Access cannot just create it on the fly?

In what event is this code executing?

What error handling is in use? Is it a resume with no notication, so you
would not know if an error were occuring the in runtime?
Click to expand...

My concern is getting the values from the subforms.
Format$(Nz(Me!fsub_Greater.Form!txt_Total_Remuneration.value, 0#), Decimal_Format)
Click to expand...
AND
Format$(Nz(Me!fsub_Hours.Form!txt_paygtee.value, 0#), Decimal_Format)which return values in full access but "Nothing" with /runtime

The subforms also set controls on the main form satisfactorily in both
executions.
 
Bill, I don't know what's happening here.

Could be a timing issue. If these are calculated controls, is it possible
that they have not updated at the moment that the runtime tries to read the
value?

Any chance it could be a security-related issue? If you are using security
(mdw file), is it the same user? For example, if the user did not have write
permissions, the subforms would be read-only, so they cannot show the new
record, so the references work differently.
 
Allen Browne
Thank you for continuing the interest.
I don't think so.
As I say, the code performs fully with Full Access with the Sub Forms Open
events assigning values to the Main Form indicating that they actually have
records and may therefore be referred to. Empty sub forms have no values and
actually cause an error if referred to so this is tested for.

"No of Guarantee Rows is " & Str$(Val(Nz(Me.txt_Guarantee_Rows.value, "0")))
returns a value of 2 indicating that the FSUB_GUARANTEE has 2 records and a
Total that may be referred to.

"FSUB Guarantee PayGTEE is " &
Format$(Nz(Me!fsub_Hours.Form!txt_paygtee.value, 0#), Decimal_Format)

I am the author of all the code and the sole user of it. I need to make it
available using the /Runtime switch but it does not perform the same.

The fact that txt_Guarantee_Rows.value = 2 on both runs indicates that the
Sub Form is actually open and should be able to be referred to.
 
Okay, so the reference is correct.

What is the ControlSource of the control that gives the problem?
Is in an expression? Could this be a timing issue, where the expression has
not been calculated yet?
 
ControlSource is "=nz(sum(DrGuar_Amt_Paid]),0)"

How much time does it need and how do I give it more?
It only has two rows to Sum.
 
Try a Recalc on the form that contains the DrGrar_Amt_Paid field before you
read the value, or a DSum() directly on the table.

If either solves the problem, it is a timing issue, and you can keep that
approach as the solution.

--
Allen Browne - Microsoft MVP. Perth, Western Australia.

Reply to group, rather than allenbrowne at mvps dot org.

Bill said:
ControlSource is "=nz(sum(DrGuar_Amt_Paid]),0)"

How much time does it need and how do I give it more?
It only has two rows to Sum.

Allen Browne said:
Okay, so the reference is correct.

What is the ControlSource of the control that gives the problem?
Is in an expression? Could this be a timing issue, where the expression
has
not been calculated yet?
Click to expand...
Click to expand...
 
Allen,

Sorry I haven't got back sooner but this was only occurring at tyhe client's
PC and not on mine.

They have since upgraded the PC to a Win XP and I believe you were right on
timing being the problem.

I have inserted a Me.Recalc in each of the Load events of the Fsub_ forms
and they appear to be responding correctly, now.

Many thanks for your help.


Allen Browne said:
Try a Recalc on the form that contains the DrGrar_Amt_Paid field before you
read the value, or a DSum() directly on the table.

If either solves the problem, it is a timing issue, and you can keep that
approach as the solution.

--
Allen Browne - Microsoft MVP. Perth, Western Australia.

Reply to group, rather than allenbrowne at mvps dot org.

Bill said:
ControlSource is "=nz(sum(DrGuar_Amt_Paid]),0)"

How much time does it need and how do I give it more?
It only has two rows to Sum.

Allen Browne said:
Okay, so the reference is correct.

What is the ControlSource of the control that gives the problem?
Is in an expression? Could this be a timing issue, where the expression
has
not been calculated yet?

--
Allen Browne
Thank you for continuing the interest.
I don't think so.
As I say, the code performs fully with Full Access with the Sub Forms
Open
events assigning values to the Main Form indicating that they actually
have
records and may therefore be referred to. Empty sub forms have no
values
and
actually cause an error if referred to so this is tested for.

"No of Guarantee Rows is " & Str$(Val(Nz(Me.txt_Guarantee_Rows.value,
"0")))
returns a value of 2 indicating that the FSUB_GUARANTEE has 2 records
and
a
Total that may be referred to.

"FSUB Guarantee PayGTEE is " &
Format$(Nz(Me!fsub_Hours.Form!txt_paygtee.value, 0#), Decimal_Format)

I am the author of all the code and the sole user of it. I need to make
it
available using the /Runtime switch but it does not perform the same.

The fact that txt_Guarantee_Rows.value = 2 on both runs indicates that
the
Sub Form is actually open and should be able to be referred to.


:

Bill, I don't know what's happening here.

Could be a timing issue. If these are calculated controls, is it
possible
that they have not updated at the moment that the runtime tries to
read
the
value?

Any chance it could be a security-related issue? If you are using
security
(mdw file), is it the same user? For example, if the user did not have
write
permissions, the subforms would be read-only, so they cannot show the
new
record, so the references work differently.




:

You say this change occurs just by setting the /runtime switch, so
presumably this is on the same computer and there cannot be any
difference
with the service packs, references, or timing.

Yes, the same machine


What are is_Actual_Payment_Method and the other references?

private is_Actual_Payment_Method as string (In ME) - Module Level

The name of a control on the form? No.

The name of a field in the form's RecordSource?
Both a field and a control?
Does using Me.is_Actual_Payment_Method make a difference?
Is it a variable declared in the procedure? Declared at the module
level?
A
public variable declared in another module? An undeclared variable?
Are
you
using Option Explicit so Access cannot just create it on the fly?

In what event is this code executing?

What error handling is in use? Is it a resume with no notication,
so
you
would not know if an error were occuring the in runtime?

--
Allen Browne - Microsoft MVP. Perth, Western Australia.

Reply to group, rather than allenbrowne at mvps dot org.

The following code returns valid values with full Access 2000 BUT
""
when
run with the Access 2000 /Runtime set.

' Different Response with RUNTIME
'MsgBox "Full Access Versus RUNTIME." & vbCrLf & vbCrLf & _
"Anticipated Payment Method is " & is_Actual_Payment_Method
&
vbCrLf
& _
"Greater to be used is " & ib_Greater_To_Be_Used & vbCrLf &
_
"No of Guarantee Rows is " & Str$(Val(Nz
(Me.txt_Guarantee_Rows.value, "0"))) & vbCrLf & _
"No of Greater Rows is " &
Str$(Val(Nz(Me.txt_Greater_Rows.value,
"0"))) & vbCrLf & _
"FSUB Greater Remuneration is " &
Format$(Nz(Me!fsub_Greater.Form!
txt_Total_Remuneration.value, 0#), Decimal_Format) & vbCrLf & _
"FSUB Guarantee PayGTEE is " &
Format$(Nz(Me!fsub_Hours.Form!
txt_paygtee.value, 0#), Decimal_Format), _
vbInformation + vbOKOnly, _
gs_Application_Name

The main form has a number of tabpages, each with a subform and
appropriate
controls.

All performs correctly under Access 2000 but can not get any
values
with
/runtime

Any ideas?

My concern is getting the values from the subforms.

Format$(Nz(Me!fsub_Greater.Form!txt_Total_Remuneration.value, 0#),
Decimal_Format)
AND
Format$(Nz(Me!fsub_Hours.Form!txt_paygtee.value, 0#),
Decimal_Format)

which return values in full access but "Nothing" with /runtime

The subforms also set controls on the main form satisfactorily in
both
executions.
Click to expand...
Click to expand...
Click to expand...
 
Back
Top