Saving a form discards the digital certificate

  • Thread starter Thread starter CP
  • Start date Start date
C

CP

Hi, all. I am working with Access 2003 and a VBA application written
by another person which is distributed to multiple users in different
states. In order to bypass the Security Warning gotten with Access
2003, we purchased a digital certificate from Verisign which appeared
to work great. However, when the application is installed on
computers other than mine (the one that actually signed the project)
and the users perform a certain function (attempting to import queries
from other users), they get an error message saying "You have
modified
a signed project. You do not have the correct key to sign this
project. The signature will be discarded". The function continues
correctly BUT the digital signature is removed from the project so the
security warning starts popping up.

I have figured out that this happens when one of the forms in the
project is opened (but isn't visible), a number of properties of the
form and it's objects are set using values from an internal table and
then the form is closed and saved. (DoCmd.Close acForm, <formname>,
acSaveYes). I'm pretty sure this is done so that the basic form can
be reused for other related processes.

My question is: Once the properties have been changed, is there a way
to save the form and its new defaults with a new name and then use
that "new" form during the rest of the process? (It doesn't appear to
stay open very long; it's mainly a way to show the queries that could
be imported and let the users specify which ones they want. )

Alternatively, could I programmatically copy the form before the
properties are changed, apply the same properties to the "new" form,
and then use that one throughout the rest of the process. (The form
is referred to by a string variable so I should be able to assign that
variable to the "new" form).

And my last possibility, and my least favorite, is to create a
separate form for each of the instances that use the generic form, set
all the properties on the form itself, and just call each form when
needed.

(There has been an MS Hotfix for this problem in Excel but I haven't
seen anything about a similar fix for Access. And I'm using a
computer that is MS says is totally updated...)

Sorry for the length of this message but I'm hoping that it gave
someone enough information so he/she can give me some ideas of where
to go from here. Thanks in advance. Carol.
 
CP said:
and the users perform a certain function (attempting to import queries
from other users), they get an error message

Not sure this is exactly your solution but in some cases I will give
power users their own MDB with linked tables to the backend. Then
they create their own queries in that MDB. This is not the same MDE
that the users run the app from.
I have figured out that this happens when one of the forms in the
project is opened (but isn't visible), a number of properties of the
form and it's objects are set using values from an internal table and
then the form is closed and saved. (DoCmd.Close acForm, <formname>,
acSaveYes). I'm pretty sure this is done so that the basic form can
be reused for other related processes.
My question is: Once the properties have been changed, is there a way
to save the form and its new defaults with a new name and then use
that "new" form during the rest of the process? (It doesn't appear to
stay open very long; it's mainly a way to show the queries that could
be imported and let the users specify which ones they want. )

Alternatively, could I programmatically copy the form before the
properties are changed, apply the same properties to the "new" form,
and then use that one throughout the rest of the process. (The form
is referred to by a string variable so I should be able to assign that
variable to the "new" form).

I'm not a digital certificate expert but I doubt that either approach
would work.
And my last possibility, and my least favorite, is to create a
separate form for each of the instances that use the generic form, set
all the properties on the form itself, and just call each form when
needed.

Another approach would be to save those preferences in a table in the
backend by user. Then every time that form is loaded reload those
preferences.
Sorry for the length of this message but I'm hoping that it gave
someone enough information so he/she can give me some ideas of where
to go from here.

We much prefer lengthy well written postings to short postings without
sufficient detail. Your posting also proves that you've spent a
significant amount of time researching some alternatives and actually
thinking about the problem. Which we appreciate.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
 
Thanks, Tony. The form isn't user specific. Instead, it's action
specific (i.e. import or export & do that to either queries or
reports). The code does load properties for the form according to
where the menu it's called from.. And then the form needs to be saved
with the new properties so that it can display correctly on the screen
for the specific situation. It's the saving that does me in.

Sounds like I might have to go to separate form. Ugh but at least
there's a possibility to try.

Thanks for the QUICK reply. Carol.
 
CP said:
Thanks, Tony. The form isn't user specific. Instead, it's action
specific (i.e. import or export & do that to either queries or
reports). The code does load properties for the form according to
where the menu it's called from.. And then the form needs to be saved
with the new properties so that it can display correctly on the screen
for the specific situation. It's the saving that does me in.

But why does the form need to be saved? You can change a lot of
properties in the Open or Load event..
Thanks for the QUICK reply. Carol.

Sheer luck on your part.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
 
I was getting the feeling that was the case. Thanks for confirming
that (I guess), Chris.

Once I figure out how best to solve this, I'll have to look through
the rest of the app to see if there are any more of these types of
operations. sigh...

Thanks again. Carol.
 
Back
Top