How to prevent importing tables

0 views
Skip to first unread message

Connie

unread,
Aug 23, 2005, 12:28:02 PM8/23/05
to
Hello

We have a small database intended for retail sale. We have converted it to
an mde and have locked it down regarding security and startup options etc.
We have also hidden several of the critical tables and queries. The problem
is, if I open a new database in Access and have set my options correctly, I
can import all of the tables and queries.

To protect our investment, does anyone know how we prevent this type of
importing?

Any help appreciated.

Rick Brandt

unread,
Aug 23, 2005, 12:57:53 PM8/23/05
to

You have to deny all permissions to tables and use "Run With Owner's
Permissions" queries instead. Then the tables cannot be imported and if a
user imports a query it is useless without the tables it is based on.

--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com


Connie

unread,
Aug 23, 2005, 3:06:03 PM8/23/05
to
Thanks Rick!

'69 Camaro

unread,
Aug 23, 2005, 3:18:08 PM8/23/05
to
Hi, Rick.

> if a
> user imports a query it is useless without the tables it is based on.

And an experienced SQL writer can easily extract the data from the secured
database into the new database with these RWOP queries. This may not be all
of the data in all of these critical tables, but I'll bet that it's data
which Connie intends to protect.

Connie, if you truly need to secure the data, use a client/server database
to hold the data, not a file-based database, like Access.

HTH.

Gunny

See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips.

(Please remove ZERO_SPAM from my reply E-mail address, so that a message
will be forwarded to me.)
Beware to those who use munged addresses: known newsgroup E-mail harvesters
for spammers are Rip...@CASInternet.Net and sc...@ripleysoftware.com

- - -
When you see correct answers to your question posted in Microsoft's Online
Community, please sign in to the Community and mark these posts as "Answers,"
so that all may benefit by filtering on "Answered questions" and quickly
finding the right answers to similar questions. Remember that questions
answered the quickest are often from those who have a history of rewarding
the contributors who have taken the time to answer questions correctly.

Connie

unread,
Aug 23, 2005, 3:35:06 PM8/23/05
to
Hi Gunny
Thanks for the info. The development of the database is complete. It is a
small program with a single function that we have packaged and want to
distribute across the country and beyond. I might be wrong, but I don't
think client/sever is what we are looking for in the above scenario.

It is suprising to me however, that even though we secured it to the max, I
can still import the tables and queries into a new access database. Can't
touch the forms, reports, macros, and modules. We would really love it if we
could find a way to do the same with the tables and queries. If you have any
ideas, I would appreciate it

Thanks
Connie

Chris Mills

unread,
Aug 23, 2005, 3:51:15 PM8/23/05
to
I suspect Client/Server is not really any more secure than Access in this
situation.

The client and/or the program must have suitable passwords and therefore
accessibility to extract the data.

The problem is the client is allowed to see the data, but hopefully only by
"Connie's approved method" (presumably a form), which must also attempt to
remove all Copy-type methods (ctrl-C, datasheet view, etc).

The only way I can see to prevent a client viewing/copying data by other than
the "approved method", is to encrypt the data. Whether even this is secure,
could be arguable. This would be in addition to RWOP, which assists hiding
table design if not data.

"intended for retail sale" is the worst possible environment, because there
are no other "site control" methods available. But it's also unusual to want
to protect data, as against program, for a "retail sale". It is not really
clear what Connie is selling (program or data).

Chris


Chris Mills

unread,
Aug 23, 2005, 4:00:51 PM8/23/05
to
> We would really love it if we
> could find a way to do the same with the tables and queries

RWOP hides the tables from direct view.

Don't use stored queries. Set the form's Recordsource in VBA code to a SQL
statement. Do not place a SQL statement directly in the Recordsource, since
mde can be largely broken.

Use the inbuilt database encryption to prevent external system dump utilities.

Chris


Connie

unread,
Aug 23, 2005, 4:04:03 PM8/23/05
to
Hi Chris
We are not really as concerned about the data as we are about the table and
query design. Sorry I was not clear in my previous posts. And it's only
when I create a new database and search the packaged software that I can
import the tables and queries. This is what I want to prevent. The forms,
reports, etc are greyed out and we want the tables and queries to be the
same. Any suggestions?

Thanks
Connie

Connie

unread,
Aug 23, 2005, 4:10:03 PM8/23/05
to
Thank you Chris. I will give it a try

Connie

Chris Mills

unread,
Aug 23, 2005, 4:10:31 PM8/23/05
to
You'd be aware that even with RWOP, the tables are still owned by the owner of
the database. And User-Level Security can be easily broken.

Nevertheless, you can only do what you can do.

The most secure User-Level Security is where you don't distribute a system.mdw
with the owner in it. See Joan Wild's website or ask Joan about this.

Another method available to you is obfuscation, which it sounds you have
partially done. But I'd be inclined to rename a database to other than mdb.

(And name tables and fields "gobbledegook"!)

Chris

"Connie" <Con...@discussions.microsoft.com> wrote in message
news:8C3E645C-21F8-4479...@microsoft.com...

'69 Camaro

unread,
Aug 23, 2005, 4:36:06 PM8/23/05
to
Hi, Connie.

> I might be wrong, but I don't
> think client/sever is what we are looking for in the above scenario.

Then you are not looking for a way to prevent people from copying your
critical data.

> It is suprising to me however, that even though we secured it to the max, I
> can still import the tables and queries into a new access database.

Are you distributing a secure workgroup file as well and joining that
workgroup file to create a new database and import the tables? Remove the
non-Administrative users' (i.e., the customers') permissions to create a new
database. Remove their permissions to create new tables, too. (Well, this
last one works in the database file you created, but since I just now thought
about it so haven't tested it, one probably can't prevent creation of tables
in another database file.) There's still a workaround, but not everyone has
stumbled upon this.

If you are not distributing a secure workgroup file, then you did not secure
it properly if you can import tables into a new database that have all the
permissions removed for members who are not the database owner.

> Can't
> touch the forms, reports, macros

Yes they can, but not everyone knows how. Tables, queries and macros can be
imported from an MDE database file. Forms and reports can be copied from an
MDE database file.

> We would really love it if we
> could find a way to do the same with the tables and queries.

Hide it all in the VBA code. The source code was removed from the MDE
database file when it was created, so it's not viewable from the VB Editor.
Don't use stored queries. Use SQL statements and execute them from VBA
procedures. Store the critical data in <cough> multi-dimensional arrays.
And scramble these things throughout the modules, so that someone looking at
the file with a hex editor can't read snippets verbatim. These techniques
are sure to bog down the speed of your application, make the file larger than
necessary, and make the code unmaintainable, but you see the alternatives and
find them unacceptable.

And don't think that encrypting/encoding the database with Access is a good
idea, because anyone who can open the database can use the same utility to
decrypt/decode the file. Use another utility to encrypt the file, but beware
that encrypted data is slow.

HTH.

Gunny

See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips.

(Please remove ZERO_SPAM from my reply E-mail address, so that a message
will be forwarded to me.)
Beware to those who use munged addresses: known newsgroup E-mail harvesters
for spammers are Rip...@CASInternet.Net and sc...@ripleysoftware.com

- - -
When you see correct answers to your question posted in Microsoft's Online
Community, please sign in to the Community and mark these posts as "Answers,"
so that all may benefit by filtering on "Answered questions" and quickly
finding the right answers to similar questions. Remember that questions
answered the quickest are often from those who have a history of rewarding
the contributors who have taken the time to answer questions correctly.

Rick Brandt

unread,
Aug 23, 2005, 5:28:55 PM8/23/05
to
'69 Camaro wrote:
> Hi, Rick.
>
>> if a
>> user imports a query it is useless without the tables it is based on.
>
> And an experienced SQL writer can easily extract the data from the
> secured database into the new database with these RWOP queries. This
> may not be all of the data in all of these critical tables, but I'll
> bet that it's data which Connie intends to protect.

How would that work exactly? Any new SQL you would run would not have
Owner's permissions so you would get nothing from the table at all (right?).
At any rate my response was limited to the question asked "how do you
prevent importing of tables from a secured file?"

I have always said that if you need ot protect data from *users* that it
should not be in an MDB file. To protect it from non-users NT security is
at least as good as the security on a server database product.

Chris Mills

unread,
Aug 23, 2005, 5:29:32 PM8/23/05
to
> And don't think that encrypting/encoding the database with Access is a good
> idea, because anyone who can open the database can use the same utility to
> decrypt/decode the file.

In the first place they have to break ULS with exclusive permissions to do
that. (admittedly not difficult)

In the second place, if they can get into the database to decrypt it, then
they hardly need to mess around with dump utilities which encryption prevents.
So it doesn't matter to decrypt it, in that event, because they can get into
the database by "proper methods" anyway.

In-built Encryption is fundamental as a line of defence against simple
dumping.

Chris


Chris Mills

unread,
Aug 23, 2005, 8:34:21 PM8/23/05
to
Actually, I appear to have stuffed-up in advising Connie to use RWOP queries
(for tables) and not use stored queries (for queries or forms).

It appears necessary to have an RWOP query stored...help!
(seems one or other advice, but they are mutually exclusive?)

Chris

"Rick Brandt" <rickb...@hotmail.com> wrote in message
news:ryMOe.891$rS4...@newssvr22.news.prodigy.net...

'69 Camaro

unread,
Aug 24, 2005, 12:38:43 AM8/24/05
to
Hi, Rick.

> How would that work exactly?

I sent you an E-mail discussing it. This shouldn't be discussed publicly in
the newsgroups.

> At any rate my response was limited to the question asked "how do you
> prevent importing of tables from a secured file?"

Agreed. But there's no reason to close one door and leave another one wide
open and expect security. Though she didn't spell it out, Connie is also
interested in preventing extraction of the data from these "critical" tables
by other means, which is what I was addressing.

> I have always said that if you need ot protect data from *users* that it
> should not be in an MDB file.

I whole-heartedly agree.

HTH.

Gunny

See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips.

(Please remove ZERO_SPAM from my reply E-mail address, so that a message
will be forwarded to me.)
Beware to those who use munged addresses: known newsgroup E-mail harvesters
for spammers are Rip...@CASInternet.Net and sc...@ripleysoftware.com

"Rick Brandt" <rickb...@hotmail.com> wrote in message
news:ryMOe.891$rS4...@newssvr22.news.prodigy.net...

'69 Camaro

unread,
Aug 24, 2005, 12:41:10 AM8/24/05
to
Hi, Chris.

> In the first place they have to break ULS with exclusive permissions to do
> that. (admittedly not difficult)

In Connie's first post, she explained the following:

"We have also hidden several of the critical tables and queries. The
problem
is, if I open a new database in Access and have set my options correctly, I
can import all of the tables and queries.

"To protect our investment, does anyone know how we prevent this type of
importing?"

I interpret that to mean that Connie's company wants to hide and protect the
critical tables and queries from the people who purchase the database
application who would then copy them and use the data in other applications
without authorization or even sell it themselves. These customers will have
sufficient permission to open the database, so breaking user-level security
isn't an issue. These customers will also be able to use Access to
decrypt/decode the application if Connie's company encrypted/encoded the
file before distribution. It's amazing how many people think that this
built-in encryption will safeguard the data from the people who are allowed
to open the database. I wanted to warn against this common assumption.

HTH.

Gunny

See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips.

(Please remove ZERO_SPAM from my reply E-mail address, so that a message
will be forwarded to me.)
Beware to those who use munged addresses: known newsgroup E-mail harvesters
for spammers are Rip...@CASInternet.Net and sc...@ripleysoftware.com


"Chris Mills" <phad_...@cleardotnet.nz> wrote in message
news:uFng6oC...@TK2MSFTNGP11.phx.gbl...

'69 Camaro

unread,
Aug 24, 2005, 1:17:54 AM8/24/05
to
Hi, Chris.

>I suspect Client/Server is not really any more secure than Access in this
> situation.

If set up correctly, a client/server database is considerably more secure in
this situation. However, no database security is completely fool-proof yet.

> The client and/or the program must have suitable passwords and therefore
> accessibility to extract the data.

An experienced DBA knows how to prevent this extraction.

> But it's also unusual to want
> to protect data, as against program, for a "retail sale". It is not really
> clear what Connie is selling (program or data).

Connie appears to be Canadian, and I don't know if Canadian laws are like
U.S. laws regarding databases, but databases in the U.S. are not
copyrightable. Hiding the data from the customer might be one of the few
options available for safeguarding their investment in the time it took to
collect, clean up, and compile the data into meaningful information useful
for a salable software product.

HTH.

Gunny

See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips.

(Please remove ZERO_SPAM from my reply E-mail address, so that a message
will be forwarded to me.)
Beware to those who use munged addresses: known newsgroup E-mail harvesters
for spammers are Rip...@CASInternet.Net and sc...@ripleysoftware.com

"Chris Mills" <phad_...@cleardotnet.nz> wrote in message

news:OVmQCyB...@TK2MSFTNGP09.phx.gbl...

Chris Mills

unread,
Aug 24, 2005, 1:43:26 AM8/24/05
to
Gunny,

Well, firstly let me say that, so far as I'm concerned, it's great to have a
difference of opinion! Things get learned that way! Also, your statements are,
of themselves, uncannily accurate. I just think they occasionally might not
apply to the issue at hand.

Anyhow:
My post was restricted to the reasons for encrypting, and I stand by that, and
why in-built encryption doesn't even matter if they otherwise have (or obtain)
full access to Access. Encrypting or dump utilities could be slightly
off-topic but is all to do with security and "extraction".

> I interpret that to mean that Connie's company wants to hide and protect the
> critical tables and queries from the people who purchase the database

Yes. I think we all answered with that in mind. I don't think our ideas were
too broadly dissimilar. Basically it is difficult!

Personally, for my own "retail software", I give the user-site (but not all
the users) full design perms on the tables. Without being irresponsible, I'm
worried about the program being ripped-off and I don't really care if they
change the table design and mess-up their own data! It has also been said "how
many ways can you design a table and what can be secret about that!" (I
reserve judgement)

She has indicated she wants to protect the design more than the data. This is
consistent with my own attempts at retail software, as indicated above.

> These customers will have
> sufficient permission to open the database, so breaking user-level security
> isn't an issue.

No that is wrong. Unless they obtain hacking software or services, ULS will
severely limit what the user can do. Including that "normal users" will not be
able to open a database exclusive, can't make design changes, can't decrypt a
database which this particular post was about. And if they could then by
definition they wouldn't need to, which you didn't seem to understand.

The whole thing relies on (ULS, MDE, etc), which we know can be broken. But if
we go too far down that track, and have too much knowledge, then there isn't
any point in security at all. Yet there is. Connie is probably selling s/w to,
um thinks, Chicken Farmers! Hopefully Chicken Farmers know more about chicken
farming and less about MS-Access security. If she is selling s/w to the
Gunny's of this world, then Heaven Help Her!

> These customers will also be able to use Access to
> decrypt/decode the application if Connie's company encrypted/encoded the
> file before distribution.

Read my post. If they can do that, then they don't even need to decrypt it!
And they can only do that if they break ULS as a pre-requisite, because they
would not normally have exclusive open or anything else beyond running a menu.

They might well break into ULS. In which case, encryption/decryption
(in-built) becomes irrelevant, sure. THEY DONT HAVE TO DECRYPT IF THEY HAVE
THAT!

> It's amazing how many people think that this
> built-in encryption will safeguard the data from the people who are allowed
> to open the database.

I said no such thing. I said it prevents external dump utilities. I said that
if they can get in with sufficient perms to decrypt, then they don't even need
to decrypt they are into it anyway! A properly secured database does not allow
any user such permissions. Password-cracking excepted. (or possibly, no such
user in the distributed mdw)

Thankyou for the reply. I, as I'm sure you, have some interest in the subject.
What we are both doing is trying to give Connie our best advice. In my case
(another post in this thread) I appear to have given conflicting advice.
However, it wasn't about Encryption.

We "retailers" need every means of defence, whatever their limitations. I
thought that was your philosophy as an old US marine too.

Best Regards
Chris

P.S. One of my best security methods is nothing to do with Access, it's
recording my customers. The way I write software, they will surely have to
contact me sooner or later! What's this? Not on my list? My next best method,
is to employ Gunny as a security guard :-)


"'69 Camaro" <ForwardZERO_SP...@Spameater.orgZERO_SPAM> wrote in
message news:OCfu%23WGqF...@TK2MSFTNGP14.phx.gbl...

Chris Mills

unread,
Aug 24, 2005, 2:40:34 AM8/24/05
to
> >I suspect Client/Server is not really any more secure than Access in this
> > situation.
>
> If set up correctly, a client/server database is considerably more secure in
> this situation. However, no database security is completely fool-proof yet.
>
If they have perms to read data, then they do. Doesn't matter how secure the
password is (you just gave them one!), nor that the file is usually busy all
day (you just gave it to an outside site!)

I think much-too-much is made of "client-server" security. Depends as much as
anything on the situation, I imagine.

See relevant posts/discussion by (David)

Regardless, Client/Server does not seem to me appropriate to a "small
shrink-wrapped retail app".

> Connie appears to be Canadian,

Oh Dear......<GUFFAW!>

I did mean to say, nationality notwithstanding, make sure to write an EULA for
retail software. Hell, it says you mustn't reverse-engineer! (if you don't say
that, then you couldn't sue or threaten to sue). "Programs" are certainly
copyrightable, otherwise none of us would bother paying Microsoft. I'm not
sure if table design is part of the "program". I hope not to find out.

Chris


Chris Mills

unread,
Aug 24, 2005, 2:25:18 AM8/24/05
to
> I sent you an E-mail discussing it. This shouldn't be discussed publicly in
> the newsgroups.
>
Personally, I think that's a great idea for some aspects of security. All
security, sooner or later, relies to some degree on a lack of knowledge.

Otherwise, the Russians would have the bomb by now!


TC

unread,
Aug 24, 2005, 8:48:06 AM8/24/05
to

Chris Mills wrote:

> All security, sooner or later, relies to some degree on a lack of knowledge.


No way. Modern security systems should not depend in any way, shape or
form on any lack of knowledge. They should depend on the key, the whole
key, & nothing but the key. For example, if I encrypt a password, I
should be able to publish the encrypted password, and every detail of
the method that I used to encrypt it, and this should not reduce the
security of the plaintext password at all.

HTH,
TC

Joan Wild

unread,
Aug 24, 2005, 11:48:28 AM8/24/05
to
Rick Brandt wrote:
>
> How would that work exactly? Any new SQL you would run would not have
> Owner's permissions so you would get nothing from the table at all
> (right?).

No they'd base the query on the RWOP query which does give them permission.

> At any rate my response was limited to the question asked
> "how do you prevent importing of tables from a secured file?"

As I suggested elsethread, remove their ability to create a new database
while using the secured mdw.


--
Joan Wild
Microsoft Access MVP


Joan Wild

unread,
Aug 24, 2005, 11:44:12 AM8/24/05
to
Remove their ability to create a new database. Details in the Security FAQ.

If they can't create a new database while joined to your secure mdw then how
will they be able to import anything?


--
Joan Wild
Microsoft Access MVP

Chris Mills

unread,
Aug 24, 2005, 2:49:15 PM8/24/05
to
In fact an RWOP SQL statement can be placed directly in a recordsource. But it
can't be placed there by code, because then it's not the owner! That's not
bad, except for mde hacking.


'69 Camaro

unread,
Aug 24, 2005, 4:58:52 PM8/24/05
to
Hi, Joan.

> If they can't create a new database while joined to your secure mdw then
> how will they be able to import anything?

I sent you an E-mail discussing how this is done. I don't believe this
should be discussed in public newsgroups.

HTH.

Gunny

See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips.

(Please remove ZERO_SPAM from my reply E-mail address so that a message will
be forwarded to me.)


"Joan Wild" <jw...@nospamtyenet.com> wrote in message
news:u6YSMZMq...@tk2msftngp13.phx.gbl...

Chris Mills

unread,
Aug 24, 2005, 10:07:03 PM8/24/05
to
Nor via respectable websites ;-)


Chris Mills

unread,
Aug 24, 2005, 11:07:40 PM8/24/05
to
> form on any lack of knowledge. They should depend on the key, the whole
> key, & nothing but the key.

Precisely. A lack of knowledge. It's still winter in Aus, so you can't blame
the sun TC :-)


TC

unread,
Aug 25, 2005, 4:14:05 AM8/25/05
to
Still winter, /and/, a second fatal shark attack in my home state; and
I am presenting software to a national scuba diving conference :-(((
- and it is not installing correctly on some pc's!
:-((((((((((((((((((((

TC

AT @comcastdotnet Tom Wickerath

unread,
Aug 25, 2005, 4:51:02 AM8/25/05
to
Chris,

> P.S. One of my best security methods is nothing to do with Access, it's
> recording my customers. The way I write software, they will surely have to
> contact me sooner or later! What's this? Not on my list? My next best method,
> is to employ Gunny as a security guard :-)

Let's be perfectly clear on one point. It would be Gunny who might hire you
as the security guard, not the other way around. Gunny would stay busy
continuing to creat the great software that that he does.

Tom
_____________________________________

AT @comcastdotnet Tom Wickerath

unread,
Aug 25, 2005, 5:00:04 AM8/25/05
to
> But it's also unusual to want to protect data, as against program, for
> a "retail sale".

It's not unusual at all. The company that I work for (a major Fortune 500
Company that builds the best damn commercial jet transport aircraft
available) has purchased several licenses to use FTIR spectral search
software with data that is stored in a proprietary format. FTIR is a form of
Infrared Spectroscopy, a technique used for the identification of unknown
compounds. The databases that we have licenced have over 150,000 spectra that
are available for conducting searches against. Basically, the vendor's entire
product is the data. The search software is a much smaller part of the
equation.

There are all kinds of commercial databases (medicine, law, pharmacology,
etc.) where the data is of paramount value.

Tom
_________________________________________

Chris Mills

unread,
Aug 25, 2005, 2:44:10 PM8/25/05
to
Perhaps, but in Connie's case I guessed right, as she confirmed.

"Tom Wickerath" <AOS168 AT @comcast DOT net> wrote in message

Chris Mills

unread,
Aug 25, 2005, 2:48:26 PM8/25/05
to
Well, for security you should wear a wet-suit that looks like a salt-water
croc :-))

Anyone could have told you MS-Access doesn't work under-water, TC ;-))))

What installer?

"TC" <aatcbb...@yahoo.com> wrote in message
news:1124957645.7...@o13g2000cwo.googlegroups.com...

Chris Mills

unread,
Aug 25, 2005, 2:58:55 PM8/25/05
to
Then why does your company (QBuilt) piss around with such pathetic things as
Database Password cracking?

"Tom Wickerath" <AOS168 AT @comcast DOT net> wrote in message

news:1BC93586-34C8-41BC...@microsoft.com...

Joan Wild

unread,
Aug 25, 2005, 3:04:46 PM8/25/05
to
Funny, that was my first reaction too (and didn't get an email Gunny)

--
Joan Wild
Microsoft Access MVP

Chris Mills

unread,
Aug 25, 2005, 3:22:45 PM8/25/05
to
His public message can't have been addressed to Joan, since he says he
informed her by e-mail.

So who was it for? Us? Outright skiting that he knows what we don't?

1) He may well do. The purpose of this thread is to secure a database "as best
as possible" (whatever that means). OF COURSE some people can break it. If
Joan's suggestion can be broken by only a select few "shouldn't be discussed
in public newsgroups", then I would venture that suggestion is adequate.

2) Anyone with a while of experience (and not necessarily even technical
expertese) can indeed do what Gunny thinks only he can. I am not saying I know
more than anyone else on this. And I agree that, generally, some things should
not be posted.

Chris


Joan Wild

unread,
Aug 25, 2005, 3:56:40 PM8/25/05
to
Chris Mills wrote:
> His public message can't have been addressed to Joan, since he says he
> informed her by e-mail.

I never got her email (probably an over eager filter at play); whatever.

> So who was it for? Us? Outright skiting that he knows what we don't?
>
> 1) He may well do. The purpose of this thread is to secure a database
> "as best as possible" (whatever that means). OF COURSE some people
> can break it. If Joan's suggestion can be broken by only a select few
> "shouldn't be discussed in public newsgroups", then I would venture
> that suggestion is adequate.

Unfortunately, by replying with 'let's not discuss it in public' has only
served to pique people's interest. Something I was trying to avoid - oh
well.

Access Security has always been, and will continue to be security by
obfuscation. Fact is that people do not need to learn the tricks, as $50
will get you in anyway.

I personally don't use ULS for 'securing' anything; I find it a useful tool
to present things to users that they need to *do their job* (most of my
clients consider their databases as tools for their job, and just want it
"to work"). I use it as an application guidance tool.

AT @comcastdotnet Tom Wickerath

unread,
Aug 25, 2005, 4:30:04 PM8/25/05
to
Chris,

First, it is not my company. I am neither an officer nor employee of QBuilt.
This company is owned by a friend of mine and, yes, I do have several tips
and articles that I've wrote that are posted at QBuilt.

Second, the password cracking tools that you so despise (yes, I read your
earlier rant where you jumped all over Jeff Conrad's butt) are made available
only to legitimate owners of database applications, after a password has
either been forgotten, or maliciously changed by a disgruntled employee.

Tom
________________________________________

Joan Wild

unread,
Aug 25, 2005, 4:43:35 PM8/25/05
to
> Second, the password cracking tools that you so despise (yes, I read
> your earlier rant where you jumped all over Jeff Conrad's butt) are
> made available only to legitimate owners of database applications,
> after a password has either been forgotten, or maliciously changed by
> a disgruntled employee.

That's great, but just how is that proven to you?

AT @comcastdotnet Tom Wickerath

unread,
Aug 25, 2005, 5:02:02 PM8/25/05
to
Joan,

I don't have a need for my friend to prove anything. I gladly accept this
person's statement at face value. I have known the owner/operator of QBuilt
for several years. Do you require that your friends prove every statement
that they make to you? I certainly hope not.

Nevertheless, there are plenty of commercial sites available
(www.lostpassword.com for one) that will sell the password cracking tools, no
questions asked. And, it seems to me that there is a Russian web site (which
I will not post for now) that offers the same tools free. So what is the big
deal?

Your question is akin to asking Lance Armstrong to prove that he never took
performance enhancing drugs! Perhaps there is a future career for you as a
writer at the French sports daily L'Equipe.

Tom
_________________________________________

Joan Wild

unread,
Aug 25, 2005, 5:44:30 PM8/25/05
to

You misunderstood. I didn't ask how your friend proves it to you. I asked
how you get proof from potential users of the password cracking tools that
they are the legitimate owners of the database?

--
Joan Wild
Microsoft Access MVP

Connie

unread,
Aug 25, 2005, 5:49:32 PM8/25/05
to
Hello all. Thanks for all of the input. At some point, I think someone was
looking for an email. My msn account is conni...@msn.com. I am going to
read all of the responses to see if there is something that will work. For a
refresher, yes I want to protect the table and query design and don't really
care to protect the data. So again, thanks for the information.

Connie

AT @comcastdotnet Tom Wickerath

unread,
Aug 25, 2005, 7:42:02 PM8/25/05
to
> I asked how you get proof from potential users of the password
> cracking tools that they are the legitimate owners of the database?

Answered in a private e-mail message that has been sent to you.

Tom
_______________________________________

"Joan Wild" wrote:

You misunderstood. I didn't ask how your friend proves it to you. I asked
how you get proof from potential users of the password cracking tools that
they are the legitimate owners of the database?

--
Joan Wild
Microsoft Access MVP

_______________________________________

TC

unread,
Aug 25, 2005, 10:02:43 PM8/25/05
to
I use Setup Factory as the installer.

The problem seems to be this. I do all my development in A97. When I
converted my final A97 mdb to A2k, 2k2, and 2k3, and produced an mde of
each, the conversions added a reference to OWC10.DLL, the office web
components library. The mde's worked fine on the pc where I did the
conversions, but they failed on about 30% of other pc's, with a missing
reference to that library. The failures were unpredictable and involved
most forms working but some forms not; inconsistently, from pc to pc.

I didn't know that a conversion from one version of access, to another,
could automatically add *unnecessary* new references. My A97 mdb does
not use anything from office web components.

Now I know better. And I have 100 expensively labelled coasters to
prove it!

TC

Rick Brandt

unread,
Aug 26, 2005, 7:40:30 AM8/26/05
to

Does that only happen when converting to 2K2 and 2K3? I convert from 97 to 2K
all the time and have never noticed any references like that being added.

Aside...since the 2K mde will run in 2K2 and 2K3, why do you bother to produce
those versions at all?

--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com


TC

unread,
Aug 27, 2005, 10:12:46 AM8/27/05
to

Rick Brandt wrote:


> Does that only happen when converting to 2K2 and 2K3? I convert from 97 to 2K
> all the time and have never noticed any references like that being added.

I've only done two previous builds of this product. The problem did not
occur on either of those. But this time, I did not have access to the
necessary different versions of Access. So I hired a training room from
a local software training company. They set up one pc with A97, one
with a2k, one with a2k2, and one with a2k3. I took the A97 mdb to each
pc, in turn, and converted to that pc's version of Access (2k, 2k2,
2k3). I then created the corresponding mdes. I did not think to check
the references in the converted mdb's. I knew that the references were
fine in the a97 mdb, and it didn't occur to me to check them in the
converted mdb's.

When the corresponding mde's did not work, later, on other pc's running
a2k2 & a2k3, I copied the a2k2 & a2k3 mdb's (which I had saved on CD)
to those pc's, to look at them. When I tried to compile them, they
failed. When I looked to see why, I found the missing reference
described before. That reference is absolutely /not/ in the a97 mdb,
but it absolutely /is/ in the a2k, a2k2 & a2k3 mdb's that were created
from the a97 mdb, and which luckily, I had the foresight to save.

Since this has never hapenned to me before, but it defintely did happen
here, I can only assume that the problem was pc-related. There must
have been something about those pc's, which caused the problem.
Unfortunately they wiped them at the end of that day, so it is too late
to go back & look at them now.


> Aside...since the 2K mde will run in 2K2 and 2K3, why do you bother to produce
> those versions at all?

Um, good question! I knew that the 2k2 one would run in 2k3, but I did
not know that the 2k one will run in both those higher versions. Are
you absolutely certain of that? (I'd test it myself, but I'm back in
the situation of not having easy access to all of the versions.)

In particular, will an a2k mde recognize the automationsecurity
property? I use that prop on pc's with a2k3, to suppress the security
warnings.

Cheers,
TC

TC

unread,
Aug 27, 2005, 10:31:15 AM8/27/05
to
Hm, I guess the question about whether an a2k mde will recognize the
automationsecurity property, is irrelevant. I imagine it won't - since
the prop did not exist then (?), and, a2k does not issue the warnings
that this prop is designed to suppress!

TC

Joan Wild

unread,
Aug 27, 2005, 11:01:02 AM8/27/05
to
That's correct, and a 2000 mde will run in higher versions.

--
Joan Wild
Microsoft Access MVP

TC

unread,
Aug 28, 2005, 2:12:15 AM8/28/05
to
Hmm, I've changed my mind about the automationsecurity question! I
think that it does need to be asked.

The automationsecurity property was unknown in 2000. But it is known in
2003. If I ran a 2000 mde in 2003, would that property still work
correctly?

Anyone care to do a quick test?

Cheers,
TC

Jeff Conrad

unread,
Aug 28, 2005, 2:45:49 AM8/28/05
to
Hi TC,

Well I did a few quick tests and here were the results.

1. I created a 2000 MDE file and made the appropriate VBS
script to launch the file. I made sure the macro security setting
was on Medium in 2003. Using the VBS script file to launch the
database in 2003 did indeed open the file *without* any prompts.
However, the startup form seemed to be "lost"??? It was like
the form was invisible, but I pretty sure it was open. Hard to
explain. Also, the application window was smaller.

2. I did the exact same test with a 2003 MDE file and exactly
the same results. No prompts, but still the same weird behavior
with the form not showing and a smaller application window.

This was the script I was using:

dim o
set o=createobject ("Access.Application")
o.automationsecurity=1
o.opencurrentdatabase "Path to database file here"
o.visible=true
o.usercontrol=true
set o=nothing

Out of time for now and off to bed.
--
Jeff Conrad
Access Junkie - MVP
http://home.bendbroadband.com/conradsystems/accessjunkie.html
http://www.access.qbuilt.com/html/articles.html

"TC" wrote in message:
news:1125209535.6...@f14g2000cwb.googlegroups.com...

TC

unread,
Aug 28, 2005, 3:54:03 AM8/28/05
to
Ok, thanks for that Jeff. It seems that the 2000 mde does recognize the
2003 property. I may well change my setup program, to only inclding the
2000 mde.

You say that the application window was smaller. This is due to
starting the app from a script. You often get different sizing
behaviour, starting from a script, compared to starting from a
shortcut.

My app is designed to run full-screen, so I'm in the process of adding
this code: if screen is 800x600 then maximize the app, else use APIs to
size the app to 800x600. I may even go the whole hog: if the user then
resizes the app bigger or smaller himself, make it dynamically resize
its controls accordingly, then save the new size in the registry for
next time.

You say the startup form did not appear. Not sure why that would be.
Maybe add a msgbox, to see if it is starting or not.

Thanks again!
TC

Jeff Conrad

unread,
Aug 28, 2005, 2:23:56 PM8/28/05
to
"TC" wrote in message:
news:1125215643....@z14g2000cwz.googlegroups.com...

Hi TC,

> Ok, thanks for that Jeff. It seems that the 2000 mde does recognize the

> 2003 property. I may well change my setup program, to only including the
> 2000 mde.

No problem.
Seems to work just fine on bypassing the security prompts.

> You say that the application window was smaller. This is due to
> starting the app from a script. You often get different sizing
> behaviour, starting from a script, compared to starting from a
> shortcut.

Ok, I did not realize that would happen.
However, adding a AppMaximize did not seem to help.

> My app is designed to run full-screen, so I'm in the process of adding
> this code: if screen is 800x600 then maximize the app, else use APIs to
> size the app to 800x600. I may even go the whole hog: if the user then
> resizes the app bigger or smaller himself, make it dynamically resize
> its controls accordingly, then save the new size in the registry for
> next time.

Sounds cool.

> You say the startup form did not appear. Not sure why that would be.
> Maybe add a msgbox, to see if it is starting or not.

Did that.
A picture is worth a thousand words so how about some screenshots
to show you the results of my tests?
:-)

http://home.bendbroadband.com/conradsystems/accessjunkie/tcpage.html

TC

unread,
Aug 29, 2005, 2:07:29 AM8/29/05
to
Hi Jeff

That is certainly strange.

Do you feel this is a problem in running the 2k mde in higher versions,
or, is it more like a side effect of starting the application via
automation?

Try adding o.visible=true before the o.opendatabase. That should fix
it.

PS. Like your website! I'll trawl around in there & see what I can
find!

Cheers,
TC

Jeff Conrad

unread,
Aug 29, 2005, 2:20:36 AM8/29/05
to
"TC" wrote in message:
news:1125295649.6...@g47g2000cwa.googlegroups.com...

Hi TC,

> That is certainly strange.

I thought it was myself as well.

> Do you feel this is a problem in running the 2k mde in higher versions,
> or, is it more like a side effect of starting the application via
> automation?

I got the same results when opening a 2000 MDE and a 2003 MDE
so I believe it was from the automation.

> Try adding o.visible=true before the o.opendatabase. That should fix
> it.

Ahh ha!! yep, that was it!
Everything works fine now.
No security prompts at all launching the 2000 MDE file in 2003.
The application window appears smaller for a brief second and
then is maximized because of the code I added.

> PS. Like your website! I'll trawl around in there & see what I can
> find!

Thanks.
:-)

TC

unread,
Aug 29, 2005, 2:26:12 AM8/29/05
to
Excellent, thanks for your help.

Off to bed; Now!

Cheers,
TC

Reply all
Reply to author
Forward
0 new messages