> I've been tasked with creating a small internal project (used by a
>  dozen users) that requires a back end database.
>
> I just upgraded to Access 2003, so I am experiencing the security
> limitations for the first time.
>
> I merely create a new database and then attempt to re-open it and I'm
> prompted with the security warning.  This is analagous to getting an
> ActiveX control warning for every web page I open whether there is a
> control on the page or not.
>
> I just want to store some data and create a few reports, I'm not
> embedding any code within; I *should not* see any security warnings. Am I
> correct in concluding that Access is no longer an option unless I:
> - Have our users revert to an older version (not an option)
> - Have our users set their security settings to low (probably not an
> option) - Buy a certificate (not an option)

"Brad Wood" <bradley_.wood_@ndsu_.edu> wrote in message
news:uJ74I9PQFHA.244@TK2MSFTNGP12.phx.gbl...
> TC wrote:
>> No, there is another (better) option. It is trivially simple to try it
>> out. Google this group for posts from me (TC) including the term
>> "automationsecurity", to find the details.
>>
>
> Thanks; that will work fine.  I still think there should be no reason to
> bother with security unless the database I'm opening itself contains code
> (as opposed to mere data).

"Paul Overway" <paul@I.hate.spam.logico-solutions.com> wrote in message
news:e8csHyQQFHA.924@TK2MSFTNGP14.phx.gbl...
> Even if the database only contains "data", there is potential for harm.
For
> example, if someone entered Shell("del *.*") into one of your fields and
the
> Jet sandbox was not being used.  Still, Microsoft's solution is a PITA and
> very poorly implemented.  The sandbox is TOO restrictive (i.e., Eval is a
> very useful function in queries but is sandboxed), but there is some risk
> running without it.
>
> --
> Paul Overway
> Logico Solutions
> http://www.logico-solutions.com
>
>
> "Brad Wood" <bradley_.wood_@ndsu_.edu> wrote in message
> news:uJ74I9PQFHA.244@TK2MSFTNGP12.phx.gbl...
> > TC wrote:
> >> No, there is another (better) option. It is trivially simple to try it
> >> out. Google this group for posts from me (TC) including the term
> >> "automationsecurity", to find the details.
> >>
> >
> > Thanks; that will work fine.  I still think there should be no reason to
> > bother with security unless the database I'm opening itself contains
code
> > (as opposed to mere data).
>
>

"TC" <aatcbbtcc***@yahoo.com> wrote in message
news:1113538353.651487.299550@z14g2000cwz.googlegroups.com...
>I can't see how .NET would affect this. The warnings come from Access &
> Jet. If a .NET component used Jet somehow, I image the warnings would
> still appear, unless .NET dropped the Office macro security level, set
> the relevant registry keys, used the AutomationSecurity property, & so
> on.
>
> But I'm no .NET expert ...
>
> Cheers,
> TC
>

"Brendan Reynolds" <anonymous at discussions dot microsoft dot com> wrote in
message news:%23BMqFgcQFHA.3880@tk2msftngp13.phx.gbl...
> The macro security warning comes from Access, not Jet, and is not relevant
> when not using automation. You won't see that warning when using Jet via
> .NET, though you would if you automated Access via .NET.
>
> This is not to suggest that there are no security issues in .NET, of
course.
> There are security issues in all development environments.
>
> --
> Brendan Reynolds (MVP)
>
> "TC" <aatcbbtcc***@yahoo.com> wrote in message
> news:1113538353.651487.299550@z14g2000cwz.googlegroups.com...
> >I can't see how .NET would affect this. The warnings come from Access &
> > Jet. If a .NET component used Jet somehow, I image the warnings would
> > still appear, unless .NET dropped the Office macro security level, set
> > the relevant registry keys, used the AutomationSecurity property, & so
> > on.
> >
> > But I'm no .NET expert ...
> >
> > Cheers,
> > TC
> >
>
>