Hello all. I'm not sure if this is possible or not, so if anyone
could tell me definitively, that would be great.

I want to create an unsecured Microsoft Access database to access a
secured Microsoft Access database. My thought was that the unsecured
database would do some sort of validation and then create links to the
secured database tables if this validation succeeds.

From what I have read, the only way to "override" Access from using
the defaultt system.mdw workgroup file is to:

A) Specify a different workgroup in a shortcut that launches the
database
B) Create a new DBEngine object and specify the SystemDB property.

I'd like to avoid A just so I can eliminate a small layer of
complexity--maintaining the correct shortcut. So, I have been trying
approach B with no amount of success. Like prior posts I have seen, I
am running into an issue where I create the new DBEngine object and
assign the appropriate workgroup file, but Access seems to ignore what
was done and insists on still using the default system.mdw workgroup.
But, even if I get this part to work, will the idea even work? Is it
possible to create links to tables in a secure database from within a
database that uses the default system.mdw workgroup? My intuition
tells me this is not possible, but it would be cool if it was.

So, if B simply will not work no matter what, then I will fall back to
A and go on with life. But, I can't get far enough to see if B will
work!

Any input is appreciated.

Thanks.

Vincent

On May 24, 10:09*am, Vincent <animedrea... (AT) verizon (DOT) net> wrote:
Hmmm...I found this posting by mitchka (http://www.vb123.com/kb/
199808_jl_mk.htm). I'll need to investigate this....

I'll post back my results.

Vincent

On May 24, 11:02*am, Vincent <animedrea... (AT) verizon (DOT) net> wrote:
Okay, I can create a linked table after I create a new "private"
dbengine, but I cannot access the linked table. I receive the
following error:

Could not read definitions; no read definitions permission for table
or query 'TESTTABLE'.

Is there a way to embed the table credentials (user name and password)
inside the linked table?

Vincent

When it comes to Access Security, I always refer developers to the Security
FAQ at http://support.microsoft.com/kb/207793. It indicates Access 97 and
2000, but applies to later versions as well.

Be aware that Access' security is not supported in the new ACCDB or ACCDE
file format of Access 2007 and Access 2010. It is supported in MDB and MDE
databases created with Access 2007 and 2010, as well as older versions. With
ACCDB and ACCDE, you are expected to use the security features of the
backend datastore... SharePoint, SQL Server, or other ODBC-compliant server
databases.

I do not, personally, use Access' security because it has proven so, so easy
to break. There is a _free_ software package that will break Access security
on any version of Access, without even having an MDW file (as require by
most other cracker programs) -- it does so by changing the owner, so that as
the new owner, you have full rights to everything. I do NOT post the link to
that software package but it is not difficult to find.

That is, because it is fruitless as protection against anyone who's really
serious about breaking in, it's long been my view that it was not worth the
time and effort to implement it and "get it right" (once I found out that
you couldn't "get it right _enough_ to protect your application or your
data"). So, if that's what you rely on, you are counting on no one wanting
your information enough to put in minimal time and effort finding the
utility that will de-securitize your database.

--
Larry Linson, Microsoft Office Access MVP
Co-author: "Microsoft Access Small Business Solutions", published by Wiley
Access newsgroup support is alive and well in USENET
comp.databases.ms-access


"Vincent" <animedreamer (AT) verizon (DOT) net> wrote

On May 24, 2:17*pm, "Access Developer" <accde... (AT) gmail (DOT) com> wrote:
Larry,

I had a feeling that this might be the case. I will proceed with this
in mind.

Thanks.

Vincent

"Vincent" <animedreamer (AT) verizon (DOT) net> wrote


All that said, most of the paying work that I've done with Access since 1993
was Access client apps to an ODBC-compatible server database (for example,
MS SQL Server, Sybase SQL Server or Sybase SQL Anywhere, or Informix) on a
server. Because the Access front-ends were physically secure (on
workstations in the client's shop) and not exposed to "the world" -- all my
work was "bespoke systems", that is, applications created for a specific
client -- the security provided by the server databases was quite
sufficient.

The clients knew and trusted their employees, those employees had little or
no use for the client-side application anyway, so stealing code or the
application was not a concern.

And, as far as I know, because no "bad guys" could get a copy of the server
DB on their own systems with unlimited time and resource to "break it", none
of my clients ever suffered an exposure of confidential data.

If you are creating an application that you are distributing to users (as
Microsoft does with Office and Windows) or were creating a Web App, then
considerations would be different.

In a few instances, after explanation of the situation, I had clients who
indicated they would like the "extra protection" of having the Access client
secured -- in those cases, I dutifully downloaded the Security Whitepaper
again, and followed the directions _to the letter_ to secure it as best it
could be secured.

Larry Linson, Microsoft Office Access MVP
Co-author: "Microsoft Access Small Business Solutions", published by Wiley
Access newsgroup support is alive and well in USENET
comp.databases.ms-access