application deployment for SP2

[Dan Bloomquist]

Hi,

We have a product that uses mdb databases.

Because of the security issue on SP2, my clients can't just install and
run. Is there some way to get my mdb files signed for the computer they
are installing on?

I'm using VS7.1 MFC and can write a custom action for the install if
need be. But I don't know what to write yet. I've been searching for the
solution for a couple of hours to no avail.

Thanks much, Dan.

 

[EarlM]

Dan,

The recommended way is to get your own digital certificate and sign the MDB.
It then can run on any computer. The user can modify data but not the
application (macros, code, etc.).

If the user's computer signs the mdb, then the user can make destructive
changes.

EarlM

 

[Dan Bloomquist]

Dan,

The recommended way is to get your own digital certificate and sign the MDB.
It then can run on any computer. The user can modify data but not the
application (macros, code, etc.).

Hi Earl,
Thanks.

This seems to be the ticket:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnsmart04/html/sa04d1.asp

My wife runs office 2003, sp2 with full updates. But for the life of me
I can't figure out how to crank her security up to create the troubles
one of my clients is having. The databases open fine after she does an
install.

Best, Dan.

<add one for email>

 

[EarlM]

Dan,

Open Access, click Tools, Macro, Security. This is also how you do it in
other office products, e.g. Word.

EarlM

 

[Dan Bloomquist]

Dan,

Open Access, click Tools, Macro, Security. This is also how you do it in
other office products, e.g. Word.

Hi Earl,
Thanks.

I tried it on my wife's computer, (I run office 2000 as I don't use it
much. She does the 'Office' stuff.), and it didn't change anything. I
didn't think it would as I'm pretty sure that is an app level setting
and has no effect on the OS.

But I got new information and it turns out that where I use ODBC the DB
opens! I have one place where I still use DAO and that is where it
'fails to open' the file. I tried sending him my msjet40.dll and
dao360.dll on the off chance but that didn't work. It is something about
what they distributed on their network as the trouble is only on this
one set of networked computers.

I also think I've learned that installed applications are considered
fully trusted so will not be blocked from opening mdbs even without a
signature. It would be up to me to code the security.

Well it looks like I'm going to have to get that last piece of code off
DAO. Something I don't look forward to. Some 4000 lines of code built on
the CDaoRecordView, yuk...

Thanks again, you have helped me think this through. And if that DAO,
ODBC thing rings a bell, please post. I'd like to get them up sooner
than later.

Best, Dan.

 

[EarlM]

Dan,

I use DAO almost exclusively. I find it more efficient in most cases and it
can do things that are difficult to do with ADODB. In some applications I
use both. Your problem is not DAO. Without knowing your application nor the
user requirements, I venture that using ODBC is not the best approach. Your
problem is more likely due to you using Access 2000 and your customer using
2002 or 2003.

It's not a good idea to just send DLLs from one computer to another. That
makes DLL-Hell even worse. Perhaps they need to upgrade Jet. For Win XP
it's windowsxp-kb829558-x86-enu.exe. For Win 2K it's
windows2000-kb829558-x86-enu.exe. (You can use Google to locate them.)

The security setting mentioned in my previous message applies only to Office
2003. It's product-wide. That is, the Access security setting applies to
all databases opened by Access 2003; the Word setting applies to all
documents, etc.

EarlM

 

[Dan Bloomquist]

Dan,

I use DAO almost exclusively. I find it more efficient in most cases and it
can do things that are difficult to do with ADODB. In some applications I
use both. Your problem is not DAO. Without knowing your application nor the
user requirements, I venture that using ODBC is not the best approach. Your
problem is more likely due to you using Access 2000 and your customer using
2002 or 2003.

Hi Earl,
Thanks.

Yea, I'd just as well stick with DAO. I know it is much faster. But MS
started telling us as early as 2002 to depreciate the use of DAO. That
it would be supported only for legacy code. Access is not installed on
the computer I've been primarily working with. I started with the cross
posting to microsoft.public.access.security because the problem looked
like it had something to do with SP2 security and mdbs. I ran into this
early on:

http://www.artima.com/forums/flat.jsp?forum=126&thread=121637

It's not a good idea to just send DLLs from one computer to another. That
makes DLL-Hell even worse.

I had him put them in my program directory so there would be no way I'd
mess his system, just mine.

Perhaps they need to upgrade Jet. For Win XP
it's windowsxp-kb829558-x86-enu.exe. For Win 2K it's
windows2000-kb829558-x86-enu.exe. (You can use Google to locate them.)

http://www.microsoft.com/downloads/...26-5c60-44bc-a2ce-1e40c7fe2b34&displaylang=en

I previously had him try this jet sp8 update but windows told him he was
up to date. I'm suppose to talk to their IP guy this morning. I don't
want to do anything that may roll them back and mess something else up.
I'm not real bright about the nuances of XP. In fact, I thought I broke
something on my wife's computer yesterday and it scared the bajevers out
of me!

The security setting mentioned in my previous message applies only to Office
2003. It's product-wide. That is, the Access security setting applies to
all databases opened by Access 2003; the Word setting applies to all
documents, etc.

Yes, that is what I have seemed to learn. The only thing I have to do
with office is to plug into Word if it is there and use the spell
checker and thesaurus.

http://reserveanalyst.com/news2_2.html

Thanks again.

Best, Dan.