I have some controls that are normally not enabled, or not visible, except
when the user selects a specific option. E.g.: user selects "mail-merge"
option, and the mail-merge selection combo appears. Converting this system
to Access 2007, I have been told that the client application file must be
read-only for security reasons - the data file on the server is, of course,
read/write. I would expect that the enabled, visible, or locked properties
would not be changeable in the new read-only environment, but they seem to
be. Have I not set up the read-only properties of the folder correctly, or
am I worrying about nothing? I don't want to deliver the product to the
client with it working on my machine and find it doesn't work on their
machines for some reason.
--
Ed

Ed C wrote:

>I have some controls that are normally not enabled, or not visible, except
>when the user selects a specific option. E.g.: user selects "mail-merge"
>option, and the mail-merge selection combo appears. Converting this system
>to Access 2007, I have been told that the client application file must be
>read-only for security reasons - the data file on the server is, of course,
>read/write. I would expect that the enabled, visible, or locked properties
>would not be changeable in the new read-only environment, but they seem to
>be. Have I not set up the read-only properties of the folder correctly, or
>am I worrying about nothing? I don't want to deliver the product to the
>client with it working on my machine and find it doesn't work on their
>machines for some reason.


Changeing control properties at runtime does not change the
form's design (unless you explicitly use code like
DoCmd.Save ...). So, as long as each user has a copy of the
front end file, there would be no conflicts and no change to
the MDB. You could use an MDE that does not permit design
changes if you are worried about users making their own
design changes.

--
Marsh
MVP [MS Access]

I *believe* that changes made to various properties (such as what you
describe) do not fall under the "read-only" envrionment. Changes made by the
project (your code or conditions within access) that are proccess by the
project during runtime should not be effected.

For example, if you have a code to change the property, then the code should
work fine, because the 'user' is not changing the property of the object,
rather the project itself is. However, if you wanted to change the code
itself, you would probably not be able to.

I'm almost positive thats the way it works... changes made by the
application itself should be ok, but not 'manual' changes.

I don't anything ever actually gets 'saved' by using code like this... the
project remembers the settings, but as soon as the project is closed and the
memory cleared, it will start fresh with the next opening. So even though
the properties of the controls are being changed, technically it's not being
saved.

In the event that you have a preferences table that looks up info like this,
these values would write to your backend, and again are not actually 'saved'
in the front end.


I'm fairly confident you should be good to go as it is...


hth

--
Jack Leach
www.tristatemachine.com

- "Success is the ability to go from one failure to another with no loss of
enthusiasm." - Sir Winston Churchill


"Ed C" wrote:

> I have some controls that are normally not enabled, or not visible, except
> when the user selects a specific option. E.g.: user selects "mail-merge"
> option, and the mail-merge selection combo appears. Converting this system
> to Access 2007, I have been told that the client application file must be
> read-only for security reasons - the data file on the server is, of course,
> read/write. I would expect that the enabled, visible, or locked properties
> would not be changeable in the new read-only environment, but they seem to
> be. Have I not set up the read-only properties of the folder correctly, or
> am I worrying about nothing? I don't want to deliver the product to the
> client with it working on my machine and find it doesn't work on their
> machines for some reason.
> --
> Ed