Digital certificates

  • Thread starter Thread starter Stephen Haley
  • Start date Start date
S

Stephen Haley

I am running into this for the first time and have a few issues:-

1) I have a development PC with both 2002 & 2003 office BUT Digital
Certificates only appear in 2003

2) Once I have signed the code in 2003 I can no longer edit in 2002

3) Once the code was signed a line of code no longer ran on a client pc
under 2002
If Me.Subform1.Form.Module.Find("Recchange", lngSLine, lngSCol, lngELine,
lngECol) Then
When it came to this line it gave an error 50289 - Can't perform operation
since code is protected.
I got round this by sticking in a sub with err resume next and just trying
to run the sub but I would like to understand why it objected.


4) When I removed the certificate it no longer allowed me to view it in
either 2002 or 2003. I eventually got arround it by removing the cert in
2003 then immediately adding a password for viewing the code but this is
very strange behavior

5) Can anyone point me at some articles re 2003 & vba certs

rgds
stephen
 
There are lots of google groups hits for "50289". A quick glance at the
title lines, suggests that many of them are similar or identical to
your problem. Try reading through those, if you haven't already.

Here's an MSDN article on certificates & Access 2003:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnsmart04/html/sa04d1.asp

In case you don't know, be aware that you can suppress the security
prompts from A2k3, /without/ a certificae and /without/ dropping the
PC's macro security level. Google this group for posts from me (TC)
containing the word AutomationSecurity.

The next version of Access, currently code-named Access 12, makes all
of this much easier. "Using the [new] Office Trust Center, users can
denote certain folders (local or remote) as trusted locations. This is
an easy way to tell the application that the Office file [eg. Access
database] within this folder is trusted and hence is safe to launch
[without the security prompts]" ( http://blogs.msdn.com/access )

HTH,
TC
 
TC,

re your code
dim o
set o=createobject ("Access.Application")
o.automationsecurity=1 ' low.
o.opencurrentdatabase "full path to your database"
o.visible=true
o.usercontrol=true
set o=nothing

Unfortunately
1) It wont handle Runtime instalations as the OpenCurrentDatabase and
NewCurrentDatabase functions are disabled in the ART
2) I dont think you can invoke a full copy of access in runtime mode
using this method and I dont let users run my apps in anything other than
runtime.

Both of these but definately 1) make it a non-starter for a commercial
install as opposed to an in-house rollout.
Lastly if you are going to use this method you really need to point it at
the version of access you want in case a user has both installed ie
set o=createobject ("Access.Application.11")

rgds
stephen
 
for the benefit of others running into this will answer my own ?s
1) I have a development PC with both 2002 & 2003 office BUT Digital
Certificates only appear in 2003
Click to expand...
2002 didnt support digital certs
2) Once I have signed the code in 2003 I can no longer edit in 2002
Click to expand...
Normal - see above
3) Once the code was signed a line of code no longer ran on a client pc
under 2002
Click to expand...
Still trying to understand this as strictly wasnt modifying anything which
is what the error suggests
4) When I removed the certificate it no longer allowed me to view it in
either 2002 or 2003. I eventually got arround it by removing the cert in
2003 then immediately adding a password for viewing the code but this is
very strange behavior
Click to expand...
Known Bug/flaw there is a note about it on technet but lost there solution
wasnt much diff to mine

rgds
Stephen
 
Ah, I take your point about the runtime. Someone told me a while ago,
that the runtime version does not let itself be automated! (so
createobject fails) I can't see why they would make that restricion.
It certainly clobbers my scripting approach!

This has never been an issue for me, because I made the decision years
ago, to have nothing to do with the runtime version. My product says on
its box, you must have a working retail copy of Access on the PC - and
my install program checks for that also.

As for using a version-specific progid, eg. Access.Application.11, you
can argue that one way or the other. A disadvantage of using a
versioned id, is that the app will stop working if the user upgrades
their copy of Access. In my case, if my installer program detects A2k
on the PC, it installs an A2k MDE. But that file also works (unchanged)
in A2k2 and A2k3. So I definitely would not want the progid to be
versioned.

Sorry it didn't pan out for you. Maybe the upcoming Office Trust Center
will be a solution?

HTH,
TC
 
Douglas said:
http://support.microsoft.com/?id=210111 has a section in it about automating
the runtime.
Click to expand...

Hmm, not sure what to make of that ...

The person who told me that you could not automate the runtime version,
was Paul Overway. See the following thread. He seemed quite sure of it.

http://groups.google.com/group/microsoft.public.access.security/msg/32e99074ee304857

Looking at the example you cite, it doesn't make much sense to me.
First, they check to see if the specified database is already running.
If it isn't, they instantly assume that "the full version of Access is
not installed" ! (That's wrong, because they have no reason to assume
that.) Then they try to start the runtime - but not using automation
(they use shell instead). Then they loop until the GetObject succeeds -
but as far as I know, that won't work, due to an obscure bug where
Access does not register itself in the Running Object Table (ROT) until
it has lost the focus once!

So, the whole example looks screwy to me. Of course, it wouldn't be the
first time that MS have posted wrong examples of using their software!

Maybe you just can't /start/ the runtime version using automation - but
you can grab a reference to it, once it has been started by some other
means, such as, the shell command.

Even so, their example is plain wrong, IMHO, since it oes not try to
start the retail version of Access before it tries the runtime one.

Cheers,
TC
 
Back
Top