installing on workstations

[fishqqq]

I wish to put the application i created in access 2010 on
workstatioins that don't have access installed and i was under the
impression if i install MS access 2010 runtime on the workstations
they would be able to use the program.

I tried this and it seems to work well however i'm not sure how to
link the tables (from the back end dbase) which is stored on the
server - to the front end application on the workstations using
runtime.

Also is there anything stopping the users from copying the front end
file (which is .mdb format) and pasting it on a computer with MSAccess
installed - and now having the ability to see all the programming
(tables/macros) etc? How do i prevent users from being able to do
this?

I appreciate any advise you can offer.
Steve

 

[John W. Vinson]

I wish to put the application i created in access 2010 on
workstatioins that don't have access installed and i was under the
impression if i install MS access 2010 runtime on the workstations
they would be able to use the program.

I tried this and it seems to work well however i'm not sure how to
link the tables (from the back end dbase) which is stored on the
server - to the front end application on the workstations using
runtime.

You can. I would suggest linking the frontend to the backend using the
explicit server and path name (\\servername\sharename\path\backend.mdb) rather
than using a mapped drive name; you can do so by using either External Data...
Link or the Linked Table Manager and navigating to the backend via "My Network
Places" or "Network" or whatever they call it on your version of Windows,
rather than via the mapped drives.

Also is there anything stopping the users from copying the front end
file (which is .mdb format) and pasting it on a computer with MSAccess
installed - and now having the ability to see all the programming
(tables/macros) etc? How do i prevent users from being able to do
this?

Create a .MDE file (after relinking) and distribute that, rather than the
..mdb. Note that there are commercial services which claim (with some validity)
to be able to reverse-engineer a .mde file and recover the code, so it's not
fully protected from someone determined to dig out the details; and things
like query SQL and table relationships are exposed even in a .mde; but using a
..mde will protect you from at least casual snoops.
--

John W. Vinson [MVP]
Microsoft's replacements for these newsgroups:
http://social.msdn.microsoft.com/Forums/en-US/accessdev/
http://social.answers.microsoft.com/Forums/en-US/addbuz/
and see also http://www.utteraccess.com

 

[fishqqq]

You can. I would suggest linking the frontend to the backend using the
explicit server and path name (\\servername\sharename\path\backend.mdb) rather
than using a mapped drive name; you can do so by using either External Data...
Link or the Linked Table Manager and navigating to the backend via "My Network
Places" or "Network" or whatever they call it on your version of Windows,
rather than via the mapped drives.


Create a .MDE file (after relinking) and distribute that, rather than the
.mdb. Note that there are commercial services which claim (with some validity)
to be able to reverse-engineer a .mde file and recover the code, so it's not
fully protected from someone determined to dig out the details; and things
like query SQL and table relationships are exposed even in a .mde; but using a
.mde will protect you from at least casual snoops.
--

             John W. Vinson [MVP]
 Microsoft's replacements for these newsgroups:
 http://social.msdn.microsoft.com/Forums/en-US/accessdev/
 http://social.answers.microsoft.com/Forums/en-US/addbuz/
 and see alsohttp://www.utteraccess.com

thank you John, i'll play around with this and see how it works

 

[Access Developer]

thank you John, i'll play around with
this and see how it works

John's is the best advice you can get on protecting your code with the
current versions, and the user/group security of the past is no better.

My comment is that most professional developers of Access databases don't
worry a great deal about protecting their developed applications because
they know from their own observations that an experienced, capable Access
developer can almost always re-create an application in much less time than
it took to create it originally, just from seeing the Forms and the flow of
execution.

It's designing database applications to fill a particular business need that
is the difficult part, and if you turn your database over to users or
clients, you simply can't protect that. Best idea is to deal with customers
you trust, or, as I do, create only "bespoke" applications, that is,
applications for, ordered by, paid for, and used by a specific
customer/firm.

Larry Linson
Microsoft Office Access MVP

 

[John W. Vinson]

John's is the best advice you can get on protecting your code with the
current versions, and the user/group security of the past is no better.

My comment is that most professional developers of Access databases don't
worry a great deal about protecting their developed applications because
they know from their own observations that an experienced, capable Access
developer can almost always re-create an application in much less time than
it took to create it originally, just from seeing the Forms and the flow of
execution.

It's designing database applications to fill a particular business need that
is the difficult part, and if you turn your database over to users or
clients, you simply can't protect that. Best idea is to deal with customers
you trust, or, as I do, create only "bespoke" applications, that is,
applications for, ordered by, paid for, and used by a specific
customer/firm.

I absolutely agree about the balance between working with someone else's code
vs. rebuilding it from scratch. There've been a couple of cases where I was
working with an existing app and saw some feature that made me ask "Hey,
that's neat, how did he do that?" and learn something, but in general it's
easier to just rebuild.
--

John W. Vinson [MVP]
Microsoft's replacements for these newsgroups:
http://social.msdn.microsoft.com/Forums/en-US/accessdev/
http://social.answers.microsoft.com/Forums/en-US/addbuz/
and see also http://www.utteraccess.com

 

[fishqqq]

I absolutely agree about the balance between working with someone else's code
vs. rebuilding it from scratch. There've been a couple of cases where I was
working with an existing app and saw some feature that made me ask "Hey,
that's neat, how did he do that?" and learn something, but in general it's
easier to just rebuild.
--

             John W. Vinson [MVP]
 Microsoft's replacements for these newsgroups:
 http://social.msdn.microsoft.com/Forums/en-US/accessdev/
 http://social.answers.microsoft.com/Forums/en-US/addbuz/
 and see alsohttp://www.utteraccess.com

I tried to create the .mde file and was prompted (informed) that the
version i was starting from was v2000. I converted this to 2002-2003
and played with it. All seemed to convert ok. Then i took the
2002-2003 version and tried to create the mde file from this and
received an error message saying the mde file could not be created.
The help info stated something about having a mdb file with +1000
tables in it or something but this mdb file has no where near that
many.

Can you suggest something to fix this problem?

thanks
Steve

 

[Access Developer]

The help info stated something about
having a mdb file with +1000
tables in it or something but this mdb
file has no where near that many.

Can you suggest something to fix this problem?

Seems as if you missed our suggestions for splitting the front-end user
interface from the back-end tables, data, and relationships, and reading the
advice on that at Tony Toew's site, http://www.granite.ab.ca/accsmstr.htm.

You do not need to convert the back end to .MDE, as it should contain
neither Forms, Reports, or code Modules which are the only objects affected
by conversion to .MDE. It is the front-end, which does contain Forms,
Reports, and/or code Modules, that benefits from conversion to .MDE, and the
only tables that the front-end should contain are lookup tables whose
content will never, or almost-never, change (One example I offer of such a
table would be a table of the postal abbreviations for U.S. states, Canadian
provinces, and territories and possessions of either -- all that data
changes so infrequently as to 'approach never'.).

One thing: you should assure that you have no compilation errors before
trying to convert to .MDE. Go to the module Window (in Access 2003 and
earlier), and on the menu click Debug, then Compile. Having compilation
errors can sometimes result in unexpected (and possibly unrelated error
messages).

Larry Linson
Microsoft Office Access MVP

 

[fishqqq]

 > The help info stated something about
 > having a mdb file with  +1000
 > tables in it or something but this mdb
 > file has no where near that many.

 > Can you suggest something to fix this problem?

Seems as if you missed our suggestions for splitting the front-end user
interface from the back-end tables, data, and relationships, and reading the
advice on that at Tony Toew's site,http://www.granite.ab.ca/accsmstr.htm.

You do not need to convert the back end to .MDE, as it should contain
neither Forms, Reports, or code Modules which are the only objects affected
by conversion to .MDE.  It is the front-end, which does contain Forms,
Reports, and/or code Modules, that benefits from conversion to .MDE, and the
only tables that the front-end should contain are lookup tables whose
content will never, or almost-never, change (One example I offer of such a
table would be a table of the postal abbreviations for U.S. states, Canadian
provinces, and territories and possessions of either -- all that data
changes so infrequently as to 'approach never'.).

One thing: you should assure that you have no compilation errors before
trying to convert to .MDE.  Go to the module Window (in Access 2003 and
earlier), and on the menu click Debug, then Compile.  Having compilation
errors can sometimes result in unexpected (and possibly unrelated error
messages).

 Larry Linson
 Microsoft Office Access MVP

I began creating this on access2003 but an now using access 2010. can
you tell me where to go to debug/compile the dbase in this version of
access?
thanks

 

[Access Developer]

I began creating this on access2003 but
an now using access 2010.

Perhaps someone else can, but I have not begun to use Access 2010 yet.

I think I now remember your saying you were using 2010... so, sorry, I
usually do not even try to answer Access 2007 or 2010 questions.

Larry Linson
Microsoft Office Access MVP

 

[fishqqq]

 > I began creating this on access2003 but
 > an now using access 2010.

Perhaps someone else can,  but I have not begun to use Access 2010 yet.

I think I now remember your saying you were using 2010... so, sorry, I
usually do not even try to answer Access 2007 or 2010 questions.

 Larry Linson
 Microsoft Office Access MVP

Looks like I got everything in a mde file and I put this on a wkstn w/
o Access but with the runtime installed and it works perfectly -
thanks again for your help. I also put the .mde file on another
computer that DOES have access installed and the program opens and
allows the user to see (and copy/paste data from) all the tables,
macros, forms etc.

how can i protect myself from someone creative enough to copy the mde
file and later reinstall on a computer with Access. I know the backend
will not be exposed but i still don't like the front end tables/forms/
macros etc from being viewed.

Is this possible?
thanks,
Steve

 

[Access Developer]

With an .MDE file, even with full Access, you should NOT be able to examine
a Form in Design View -- if you can, then my guess is that there is
something wrong/incomplete about your conversion to .MDE format. But, in
regard to Tables, Queries, and Macros, as Maxwell Smart was wont to say,
"Sorry 'bout that!" -- "compiling" to .MDE only blocks viewing of VBA code
and those objects that can have a VBA class module.

User/group level security in past versions was supposed to provide security
for all objects, but it was easily breakable.

And, though I haven't done any detailed examination, there are sites that
say they have products that can expose even the "compiled" objects of an
MDE. Access, in any version, is just not the product to use for general
distribution of an application. There is no 'foolproof' security, but there
are many development tools that make it more difficult to get at the
internals of an application than Access does.

Larry Linson
Microsoft Office Access MVP

Perhaps someone else can, but I have not begun to use Access 2010 yet.

I think I now remember your saying you were using 2010... so, sorry, I
usually do not even try to answer Access 2007 or 2010 questions.

Larry Linson
Microsoft Office Access MVP

Looks like I got everything in a mde file and I put this on a wkstn w/
o Access but with the runtime installed and it works perfectly -
thanks again for your help. I also put the .mde file on another
computer that DOES have access installed and the program opens and
allows the user to see (and copy/paste data from) all the tables,
macros, forms etc.

how can i protect myself from someone creative enough to copy the mde
file and later reinstall on a computer with Access. I know the backend
will not be exposed but i still don't like the front end tables/forms/
macros etc from being viewed.

Is this possible?
thanks,
Steve

 

[David-W-Fenton]

:

I began creating this on access2003 but an now using access 2010.
can you tell me where to go to debug/compile the dbase in this
version of access?

There is virtually no difference in the VBE IDE between A2003 and
A2010. It's on the Debug menu in both.

But you DO have to understand that you have to be in the VBE to do
this. The fact that you seem not to know about the VBE makes me
wonder if you have any VBA code at all.

 

[David-W-Fenton]

User/group level security in past versions was supposed to provide
security for all objects, but it was easily breakable.

I would dispute the use of "easily" here. Yes, you can Google and
find tools that will break security (not free). But you have to know
to do that. Also, anybody who is Googling for that probably knows
they are doing something completely unethical and WRONG.

So, I really wouldn't say it's easy at all. But it does require a
lack of morals/ethics.

 

[Access Developer]

I would dispute the use of "easily" here.
Yes, you can Google and find tools that
will break security (not free). But you
have to know to do that.

In fact, you can find tools by Googling, and the best one is, indeed, free.
With that one, you don't need the MDW file, only the MDB (I don't remember
if it unlocks an MDE; I'm reasonably certain it doesn't "uncompile" one).

Also, anybody
who is Googling for that probably knows
they are doing something completely
unethical and WRONG.

Ah, David, if you had as much difficulty as I have in either remembering or
finding where you recorded a "password from the past", you wouldn't be so
strong in your statement. I have, in fact, perfectly legally, and perfectly
ethically, used the software I mentioned earlier to break security on one of
my own databases; and, I have had clients who had a database done by a
long-departed employee (and I knew this to be the case) who wanted access to
the Access application.

And, isn't it the "unethical and WRONG" hackers against whom the OP would
like to defend?

Larry