Subform referencing issue and Access 2003 Security

K

KRice

This is a very strange issue, but I'll try to be clear. I have a main form
with two separate subforms. (The subforms are not nested.) Each subform is
in datasheet view because it should look like spreadsheet data. The main
form is in standard form view.

On each subform, there is a few fields that get totaled. I want to
reference this value on the main form. Each subform is based on a filtered
version of the same table, while the main form has no record source. To
avoid showing mathematical errors, I check each subform to make sure there's
at least one record. If there are no records, the control on the main form
shows "0". Otherwise, it shows the value pulled from the subform. The code
is in the control source on the main form, and it looks like this:

=IIf(Forms("f_Reports_Main")![SubFormName].[Form].[Recordset].[RecordCount]=0,0,SubFormName!FieldName)

In Access 2003, with the Macro Security set to "Low", this works fine.
However, if I up the security setting to "Medium" (which is the default in
Access 2003), then the same code returns "#Error" in the textbox on the main
form.

On the subform, the value is still calculating correctly, so this leads me
to two possible conclusions:

1) This is a bizarre bug in Access 2003 in how it utilizes security, or
2) There is another way to access the value on the Subform that I'm not
aware of. (Remember that I need to make a record count check first.)

Does anyone have any insight on this? I don't know why changing the
security setting from Low to Medium would alter the functionality of the
code, especially since it's utilizing no outside data and really, it's just
pulling a value from a subform to display on a form.

Any input on this would be appreciated. And, for the record, I can't change
the security settings at work, so I can't just "fix" it by setting the
security to "Low".

~Kevin
 
S

Sidney

try this

Forms("f_Reports_Main")![SubFormName].Form.RecordsetClone.RecordCount

"KRice" escreveu:
 
K

KRice

That didn't change the outcome. "Medium" security still breaks it, while
"Low" security is fine.

Thanks for the effort though.

~Kevin


Sidney said:
try this

Forms("f_Reports_Main")![SubFormName].Form.RecordsetClone.RecordCount

"KRice" escreveu:
This is a very strange issue, but I'll try to be clear. I have a main form
with two separate subforms. (The subforms are not nested.) Each subform is
in datasheet view because it should look like spreadsheet data. The main
form is in standard form view.

On each subform, there is a few fields that get totaled. I want to
reference this value on the main form. Each subform is based on a filtered
version of the same table, while the main form has no record source. To
avoid showing mathematical errors, I check each subform to make sure there's
at least one record. If there are no records, the control on the main form
shows "0". Otherwise, it shows the value pulled from the subform. The code
is in the control source on the main form, and it looks like this:

=IIf(Forms("f_Reports_Main")![SubFormName].[Form].[Recordset].[RecordCount]=0,0,SubFormName!FieldName)

In Access 2003, with the Macro Security set to "Low", this works fine.
However, if I up the security setting to "Medium" (which is the default in
Access 2003), then the same code returns "#Error" in the textbox on the main
form.

On the subform, the value is still calculating correctly, so this leads me
to two possible conclusions:

1) This is a bizarre bug in Access 2003 in how it utilizes security, or
2) There is another way to access the value on the Subform that I'm not
aware of. (Remember that I need to make a record count check first.)

Does anyone have any insight on this? I don't know why changing the
security setting from Low to Medium would alter the functionality of the
code, especially since it's utilizing no outside data and really, it's just
pulling a value from a subform to display on a form.

Any input on this would be appreciated. And, for the record, I can't change
the security settings at work, so I can't just "fix" it by setting the
security to "Low".

~Kevin
 
K

KRice

I don't know if this is closure or not, but it seems as though you cannot
access the recordset of a subform from the main form when the security is set
to Medium. I've written a fairly simple solution around this issue (using a
function to pull properties off of a form, be it a subform or not), but this
issue seems more like a bug than a security issue. There's no outside DB
access, and there are no linked tables or any other outside issues. It's as
if Access 2003 doesn't validate an entire database as "safe"; rather, bits
and pieces are "safe" depending on your security level.

If anyone has a clearer answer on this, I'd be happy to hear it.

~Kevin
 
6

'69 Camaro

Hi, Kevin.

To bypass the Fort Knox security of Access 2003, remove the text from the
Control Source Property of the control on the main form. Place the following
in the Form_Current( ) event on the subform's module:

Me.Parent!MainForm_CtrlName.Value = IIf(Me.Recordset.RecordCount = 0, _
0, Me!Subform_CtrlName.Value)

.. . . where MainForm_CtrlName is the name of the control on the main form,
and Subform_CtrlName is the name of the control on the subform. Save and
compile the code.
It's as
if Access 2003 doesn't validate an entire database as "safe"; rather, bits
and pieces are "safe" depending on your security level.

You're on the right track. Access 2003's Macro Security relies on the Jet
Expression Service to validate what is "safe" and what is not. All queries
and properties of controls use the Jet Expression Service, but VBA doesn't.
So if you want to bypass Access 2003 Macro Security, it's a simple matter of
learning and using VBA. But that's just between you and me, so don't tell
anyone this. Continue to complain about what a pain Access 2003's Macro
Security is to work with, and management will continue to believe that
they've done a terrific job ensuring all the Access databases in the world
are "safe." ;-)

HTH.
Gunny

See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips and tutorials.
http://www.Access.QBuilt.com/html/expert_contributors2.html for contact info.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top