Converting A2K to Access 03
Reggie
clients computer which have been upgraded to Access 03. I'm not sure
exactly what they mean but of you know or could point me in a direction
to find info on how to prevent and/or fix the db's so that these
message don't pop up when the app is started. Error messages below:
1. Microsoft Jet 4.0 service pack 8 must be installed to block unsafe
expressions without affecting common functionality.
2. Opening C:\AMRR\AMRR.mdb
This file may not be safe if it contains code intended to harm your
computer.
Do you want to open this file or cancel the operation?
3. Security warning: Unsafe expression are not blocked.
Do you want to block usafe expressions?
Thanks for your time.
'69 Camaro
> 1. Microsoft Jet 4.0 service pack 8 must be installed to block unsafe
> expressions without affecting common functionality.
Since your client has Access 2003 installed, Jet 4.0 SP-8 is also installed,
so this is not really very useful information. It's the message intended
for Access 2002 users, because they _don't_ have SP-8 installed by default,
so they'd need to know that for security purposes, if they want to block
unsafe expressions, then they're going to have to ensure that SP-8 is
installed first.
> 2. Opening C:\AMRR\AMRR.mdb
> This file may not be safe if it contains code intended to harm your
> computer.
> Do you want to open this file or cancel the operation?
This means that the file contains VBA code, or action queries, or an
expression in a query, or form, or report, or a control property that is on
the list of potentially harmful expressions, such as "Quit," which will
close an application. The software isn't sophisticated enough to tell
whether a virus is embedded in the file, or the VBA code, action queries, or
expressions are actually harmful, though. If your client is going to get
any work done, then he'd better open the file and look inside to see whether
there actually _is_ any harmful content. Oh, wait. _You_ built the
application for them. Why not just tell them over the phone or by E-mail
whether or not you put malicious expressions in there, so that they won't
lose any more sleep?
> 3. Security warning: Unsafe expression are not blocked.
> Do you want to block usafe expressions?
If you intentionally put malicious expressions in there, then this is your
client's chance to block those expressions when they open the file. If you
didn't put malicious expressions in the file, then they don't need to block
the potentially harmful expressions -- because there aren't any. If you put
malicious code in there, then they're SOL, because the VBA code can't be
blocked with the security features of Jet 4.0, SP-8.
> you know or could point me in a direction
> to find info on how to prevent and/or fix the db's so that these
> message don't pop up when the app is started.
Access 2003's Macro Security level is set to medium, the default. They need
to change it to low in order to avoid these messages when opening your
application. To do so, open Access and select the Tools -> Macro ->
Security... menu to open the Security dialog window. Select the "Low"
option and select the "OK" button to save the change.
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.
"Reggie" <rsm...@resourceconsultants.com> wrote in message
news:1149829565.2...@j55g2000cwa.googlegroups.com...
Reggie
malicious code because they've been using my apps for years (A2K), but
they are military/government clients and are pretty limited on what
they are able to configure on their machines. I've never used 2003 so
was unaware. I also came across the Sandbox setting which is new to
me. Been doing a lot of .net stuff so been out of the loop for a
little while. You said to change the setting for macros under the
tools menu should stop the popup messages. I also read something about
having to change the registry setting of the Sandbox attribute to 0.
Do I need to do both? Looks like I need to get back aquinted with the
2003 version. Lastly, I have the following Jet version installed
(4.0.8618.0 Windows XP SP2 and Security Bulletin MS04-014) Could you
tell me if this includes SP8? I think it does, but not real sure.
Thanks again for your time Gunny.
'69 Camaro
> I also read something about
> having to change the registry setting of the Sandbox attribute to 0.
The default is 2, which means that Sandbox mode is used for non-Access
applications, but not for Access applications. If they change Sandbox mode
to 0, then Sandbox mode will be disabled for all applications that use Jet
4.0. I'd leave the setting at 2 (or change it back to 2 if it's currently
on another setting).
> Looks like I need to get back aquinted with the
> 2003 version.
If you've waited this long, then probably not. Many folks skipped this
version due to the overly cautious, annoying security messages. Set the
Macro Security level to low, and the security feature works just like all
the previous versions, so this annoyance really isn't a good reason to avoid
this version.
Access 2007 is coming out early next year, and it promises a Macro Security
feature that's a little more manageable.
> Lastly, I have the following Jet version installed
> (4.0.8618.0 Windows XP SP2 and Security Bulletin MS04-014) Could you
> tell me if this includes SP8?
Yes. msjet40.dll version 4.0.8618.0 contains Jet 4.0 SP-8.
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.
"Reggie" <rsm...@resourceconsultants.com> wrote in message
news:1149837425.8...@u72g2000cwu.googlegroups.com...
David W. Fenton
wrote in news:SfydnZ3J9tFtsRTZ...@adelphia.com:
> Yes. msjet40.dll version 4.0.8618.0 contains Jet 4.0 SP-8.
The first digit of the build number is the SP level, in this case
build 8618. All build numbers 8NNN will be SP 8 or higher.
--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Rick Wannall
install things themselves. To get past the prompts you're talking about we
experimented with Certificates, but we could not get them set up properly.
I'm still convinced that certificates are a better answer than this, but to
get around the problem until we can revisit certificates, I use this
vbscript file to open our app:
dim o
set o=createobject ("Access.Application")
o.automationsecurity=1 'set macro security LOW.
o.opencurrentdatabase "\\ourfileserver\files\myappdirectory\myapp.mde"
o.usercontrol=true
set o=nothing
A shortcut on the user's desktop points to the script.
We still have an occasional problem related to some Windows update that does
not accomplish its full mission unless the user can log on to his
workstation as an Admin. The symptom that we get an error message when the
user trys to run the app via the vbscript:
Microsoft Access can't open database because it is missing, or opened
exclusively by another User.
The app is neither missing nor opened exclusively. The cure is to have the
user log out of the workstation, make the user an Admin on his or her own
workstation, have the user log back in. Try once to open the app and get
the same failure again. Try a second time to open the app, this time
successfully. Have the user log out of the workstation. Make the user NOT
an admin on the workstation, and then carry on as usual from then on. If I
remember correctly, the process fixes the problem even for other users,
meaning that if any user goes through the recovery steps I described, then
all users will find that they can open the app from that workstation.
I don't think IT ever found out what part of these updates is not "running
to completion" ( my opinion of the situation) and causing this.
David W. Fenton
news:_vfig.48253$Lm5....@newssvr12.news.prodigy.com:
> In our environment users don't have the abilty to change macro
> settings or install things themselves. To get past the prompts
> you're talking about we experimented with Certificates, but we
> could not get them set up properly. I'm still convinced that
> certificates are a better answer than this, but to get around the
> problem until we can revisit certificates, I use this vbscript
> file to open our app:
Doesn't the self-certification thingie do the job?
Rick Wannall
me, but my little certificate is of no value to other users. It's not
present on their workstations, and it would not be valid if it were.
'69 Camaro
> but my little certificate is of no value to other users. It's not
> present on their workstations, and it would not be valid if it were.
Export your SelfCert's Public Key and install it on the target computer, and
it will be valid -- at least for Medium level Macro Security. High level
requires a certificate issued by a Certificate Authority for authentication.
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.
"Rick Wannall" <wan...@notadomain.de> wrote in message
news:kFkig.145587$F_3....@newssvr29.news.prodigy.net...
Rick Wannall
Thank you!!
We'll give this a shot.
'69 Camaro
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.
"Rick Wannall" <wan...@notadomain.de> wrote in message
news:m8mig.145617$F_3....@newssvr29.news.prodigy.net...
David W. Fenton
Each user can self-certify, no?
No Windows Terminal Server, I've simply altered the appropriate
registry key, which I've now forgotten, of course.
Reggie
are always a few years behind the general population when it comes to
software so I'm forced to learn enough to survive until they decide to
migrate to 2007 which should be around 2010. Take care.
Reggie
Reggie
the settings. This sounds like a handy work-around. I'll give it a
shot. Thanks much for your time.
Rick Wannall
released as an MDE, as far as I know. I see no way for them to gain access
to a module to apply their certificate. Nor would I want them to,
especially since that would require creating a copy of the MDE for each
user, and I would not want to deal with over a hundred users learning (or
knowing) how to self-certify.
David W. Fenton
> Permissions and logic aside, users cannot self-certify an
> application released as an MDE, as far as I know. . . .
I don't have any MDEs running in A2K3, so don't know about that, but
my understanding that a self-certification is per user installation,
*not* per MDB/MDE. The menu choice to do it is *not* in Access, but
on the Programs menu, if I'm remembering correctly.
> . . . I see no way for them to gain access
> to a module to apply their certificate. . . .
I don't know that this is involved.
> . . . Nor would I want them to,
> especially since that would require creating a copy of the MDE for
> each user, . . .
Well, if you're sharing a front end, you're just a complete idiot in
the first place, so there's not much help that can be offered to
you. Refusing to do the most basic things to distribute your apps
correctly makes it a waste of time to offer solutions to less simple
problems.
> . . . and I would not want to deal with over a hundred users
> learning (or knowing) how to self-certify.
Well, that's the problem that Microsoft created. I some
circumstances, with a small number of users, it's not going to be a
problem.
Rick Wannall
installed certificate, what magical process verifies that the certificate
makes it okay to open that MDE?
David W. Fenton
> Stop and think: If you don't make a connection between the MDE
> and installed certificate, what magical process verifies that the
> certificate makes it okay to open that MDE?
It's the Access user's installation that is "self-certified," not
any particular file.
Have you tried it?
I've done it, and it didn't ask me for any particular files.
Rick Wannall
But I will play around with it again first chance I get now that you've
brought up a point.
David W. Fenton
> Stop and think: If you don't make a connection between the MDE
> and installed certificate, what magical process verifies that the
> certificate makes it okay to open that MDE?
OK, I had incompletely misunderstood the process of how this works.
I thought the certificate was Access user installation-specific.
In any event, I had no difficulty creating an MDE and certifying it
with my self-certification certificate.
It's true, this would have to be done on ever machine each time the
database is updated, but it *is* possible to do it.
I agree, it's a terrible setup the way MS has done this, not
providing any simple way to share self-certifications, but it hasn't
been insurmountable in any scenario where I've used A2K3 (we just
set the registry key to turn off the whole bloody macro security for
an entire terminal server).
w_a_n_n_a_l_l_
David W. Fenton
news:eZmjg.44063$fb2....@newssvr27.news.prodigy.net:
> So how did you certify an MDE?
I created the certificate.
I created the MDE.
I opened the VBE in the MDE, went to the Tools menu and chose the
certification option. I chose the certificate I'd created in the
first step.
The fact that there was no code there didn't seem to matter to the
certification process.
Try it yourself and tell me if I'm imagining all of this.
Rick Wannall
you could get to the visual basic editor at all from there. And it probably
wouldn't have occurred to me that you could get into VBE in an MDE, even if
I had remembered the Macro menu items correctly.
I certified the MDE exactly as you described.
I still have no interest whatsoever in having even 1 user self-certify the
company's application, never mind a hundred and some odd.
Still, I'm glad to have seen this detail, which could be very handy some
day.
Thanks.