Access' Future?

D

Duane

I'm not really sure which forum to ask this question in, so point me in the
right direction if there's a better place.

I'm still using Access97. Haven't seen a reason to update, but a better
reason is the user's don't want an added expense for updating. I'm just
wondering for any new projects, if Access is still a good database with a
future, if Microsoft is targeting some other software, if newer versions are
about to be released, or if I should start looking at something else. Most
of the applications are for just a small number of users concurrently.

If Access still has a future, another question is what is the best way for
releasing software and updating the front-end forms side to the users? I
had tried replication, but that never worked out very well. It wasn't very
long ago that one user had problems with replication not being updated and
was too old. Nothing had changed. Converting it to non-replicated fixed
that problem, but with other databases programs that are updated more often,
it's always a pain to copy a several megabyte file on, and then update all
the table links. I've written a utility automate the re-linking, but just
wanted to know what others are doing. It would be nice to just update the
changed form. I could e-mail that to them.

Also, what's the best to protect your code? I've used the user security on
the form and module code, but think there's probably ways to get around
that. Making a MDE solves that, but another step and I like the idea of
users being able to at least make temporary queries. Maybe, a bad idea?

Thanks for any help and comments,

Duane
 
T

Tom Wickerath

Hi Duane,

Access 97 is a very stable version of Access. If it is still serving your
needs, then perhaps you do not need to upgrade. The next version of Access
that is scheduled to release, known as version 12, represents a huge
development effort by Microsoft. The size of the Access Development team was
increased significantly for this release. You might want to read up on the
various changes that are covered in a blog maintained by Erik Rucker:
http://blogs.msdn.com/access/. Microsoft would not be making such a hugh
investment if Access had no future.
If Access still has a future, another question is what is the best way for
releasing software and updating the front-end forms side to the users?

Two methods come to mind. Access MVP Tony Toews has a free utility available
that many people use very successfully. See this link:

http://www.granite.ab.ca/access/autofe/details.htm

I have code available that is much less sophisticated than Tony's utility,
but it does the job for me:

http://www.access.qbuilt.com/html/update_front_end.html

I've used the user security on the form and module code, but think there's
probably ways to get around that.

Yes, there are. It's usually fairly easy too. Access "security" is a bad
joke, but that's all I'll say on the subject.
Making a MDE solves that, but another step and I like the idea of users being
able to at least make temporary queries.

I've never had any problems with users making temporary queries in .MDE
files. You must, however, use a split design. Each user should have their own
local copy of the FE database, in order to prevent conflicts. Here is another
article that you might find useful:

Implementing a Successful Multiuser Access/JET Application
http://www.access.qbuilt.com/html/multiuser_applications.html


Tom

http://www.access.qbuilt.com/html/expert_contributors.html
http://www.access.qbuilt.com/html/search.html
__________________________________________
 
J

John Vinson

I'm not really sure which forum to ask this question in, so point me in the
right direction if there's a better place.

This is probably a good place. Some other folks may join in.
I'm still using Access97. Haven't seen a reason to update, but a better
reason is the user's don't want an added expense for updating. I'm just
wondering for any new projects, if Access is still a good database with a
future, if Microsoft is targeting some other software, if newer versions are
about to be released, or if I should start looking at something else. Most
of the applications are for just a small number of users concurrently.

Access 12 is going to be out in beta this Spring. It's a MAJOR
upgrade, and a big commitment on Microsoft's part. Access is *not*
going away any time soon, despite the past ten or twelve years of
rumors to the contrary.
If Access still has a future, another question is what is the best way for
releasing software and updating the front-end forms side to the users? I
had tried replication, but that never worked out very well. It wasn't very
long ago that one user had problems with replication not being updated and
was too old. Nothing had changed. Converting it to non-replicated fixed
that problem, but with other databases programs that are updated more often,
it's always a pain to copy a several megabyte file on, and then update all
the table links. I've written a utility automate the re-linking, but just
wanted to know what others are doing. It would be nice to just update the
changed form. I could e-mail that to them.

A split database (with the data in the backend and the application on
each user's machine) is the most generally accepted technique. Tony
Toews (http://www.granite.ab.ca/access) has a very slick "Auto FE
Updater" on his Downloads page.
Also, what's the best to protect your code? I've used the user security on
the form and module code, but think there's probably ways to get around
that. Making a MDE solves that, but another step and I like the idea of
users being able to at least make temporary queries. Maybe, a bad idea?

An MDE is the usual technique. You can get around the ad-hoc query
problem by providing a very general parameter query or query-by-form
feature; in my experience you won't find very many users skilled or
confidant enough to write their own SQL or even use the query grid
(maybe you've got a better class of users!) A separate stripped-down
MDB frontend (without your code, just links to the backend) could be
provided to those users whom you trust to create queries (note that
this can be dangerous: a little knowledge...)




John W. Vinson[MVP]
 
T

Tony Toews

Duane said:
I'm still using Access97. Haven't seen a reason to update, but a better
reason is the user's don't want an added expense for updating. I'm just
wondering for any new projects, if Access is still a good database with a
future, if Microsoft is targeting some other software, if newer versions are
about to be released, or if I should start looking at something else. Most
of the applications are for just a small number of users concurrently.

Like Tom and John have stated Access is going to have some major,
major upgrade coming soon. Very nice stuff indeed. They have lots
of folks working on this version of Access.
Also, what's the best to protect your code? I've used the user security on
the form and module code, but think there's probably ways to get around
that. Making a MDE solves that, but another step and I like the idea of
users being able to at least make temporary queries. Maybe, a bad idea?

I would distribute an MDE. But give the power users another MDB
linked to the tables for their temporary queries and such.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
 
D

Duane

Thank you Tom, John, and Tony. I'm very happy to know Access sounds like
it's going to be around awhile more! I was afraid I was outdated.

Although showing the users how to do queries, only one may have used them.
I guess it's more of what I would like if I was using it. Maybe I should
give that idea up and make a separate front-end for any exceptional users.

Am I to understand that one should use Access security mainly for making it
convenient (or inconvenient) for the users but not to assume it absolutely
protects code nor data viewing restrictions?

I will have to check out all the wonderful links provided.

Thanks again for letting me know Access is still in the playing. I'll start
looking into version 12.

Duane
 
T

Tony Toews

Duane said:
Thank you Tom, John, and Tony. I'm very happy to know Access sounds like
it's going to be around awhile more! I was afraid I was outdated.

Although showing the users how to do queries, only one may have used them.
I guess it's more of what I would like if I was using it. Maybe I should
give that idea up and make a separate front-end for any exceptional users.

That would certainly be my suggestion. At one client in particular I
had a few power users who had to analyze data and pull in into Excel.
But most people could care less about that functionality.
Am I to understand that one should use Access security mainly for making it
convenient (or inconvenient) for the users but not to assume it absolutely
protects code nor data viewing restrictions?

Correct. And someone out there offers a service to retrieve the VBA
source code, including variable names and module names but not the
comments, from MDEs.
Thanks again for letting me know Access is still in the playing. I'll start
looking into version 12.

We're already are. <smile>

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
 
T

Tom Wickerath

Hi Duane,

Have you ever used the QBF (Query by Form) technique? I'm not talking about
the rather limp QBF that is built into Access. I'm talking about where you
use VBA code to create the WHERE portion (or more) of a SQL (Structured Query
Language) statement. QBF is a very powerful technique that allows your users
to find data easily. I have a sample that I can send to you if you want to
see it in action.

Access security is useful for implementing data viewing restrictions.
However, you can do the same thing with your own "home grown" security, by
using code to determine the users NT UserID at startup, and comparing this
value to a table of users. Either way, using built-in security or the home
grown variety, neither method is very secure. It will only keep honest people
out. Anyone who is intent on getting into your database will likely be able
to do so. If you'd like to send me just the workgroup information file
(*.mdw) from your secured Access application, I think I can provide pretty
convincing proof of just how weak Access security really is.

My e-mail address is available at the bottom of the contributors page,
indicated in the link in my signature. Let me know if you'd like a copy of my
QBF demo. Whatever you do, please do not post your e-mail address (or mine)
to a newsgroup message.


Tom

http://www.access.qbuilt.com/html/expert_contributors.html
http://www.access.qbuilt.com/html/search.html
__________________________________________
 
D

Duane

Correct. And someone out there offers a service to retrieve the VBA
source code, including variable names and module names but not the
comments, from MDEs.

Oops. So, MDE doesn't protect code. Is there anyway to keep someone from
getting your code?

Duane
 
D

Duane

Tom Wickerath said:
Hi Duane,

Have you ever used the QBF (Query by Form) technique? I'm not talking about
the rather limp QBF that is built into Access. I'm talking about where you
use VBA code to create the WHERE portion (or more) of a SQL (Structured Query
Language) statement. QBF is a very powerful technique that allows your users
to find data easily. I have a sample that I can send to you if you want to
see it in action.
Not sure what you mean, but I've created a "search form" which the users
fill in desired fields and it will create the WHERE portion of a recordset,
if that's what you mean.
Access security is useful for implementing data viewing restrictions.
However, you can do the same thing with your own "home grown" security, by
using code to determine the users NT UserID at startup, and comparing this
value to a table of users. Either way, using built-in security or the home
grown variety, neither method is very secure. It will only keep honest people
out. Anyone who is intent on getting into your database will likely be able
to do so. If you'd like to send me just the workgroup information file
(*.mdw) from your secured Access application, I think I can provide pretty
convincing proof of just how weak Access security really is.
I have followed examples of security without passwords. This is where I
create a workgroup for design, and then do something like remove the admin
user. The user only has the standard workgroup. Would you still be able to
get the code and access data tables with that security?

My e-mail address is available at the bottom of the contributors page,
indicated in the link in my signature. Let me know if you'd like a copy of my
QBF demo.
Whatever you do, please do not post your e-mail address (or mine)
to a newsgroup message.

Umm. Are you saying I did something wrong? I thought it was just a
friendly reminder, but now I see my reply message is gone and when I hit
Reply Group in Outlook Express, it puts the e-mail address in the message.
Is there a way to configure OE or are you just saying, make sure I remove
it?

Duane
 
T

Tom Wickerath

Hi Duane,
...and it will create the WHERE portion of a recordset,
if that's what you mean.

That's exactly what I meant.

The user only has the standard workgroup. Would you still be able to
get the code and access data tables with that security?

I think so, but if you want to know for sure, then send me a zipped copy of
your database and the workgroup information file.

Umm. Are you saying I did something wrong? I thought it was just a
friendly reminder, ...

That's all it was. You did nothing wrong. However, I have had people in the
past who have innocently posted my e-mail address back to a newsgroup post.
...but now I see my reply message is gone and when I hit
Reply Group in Outlook Express, it puts the e-mail address in the message.
Is there a way to configure OE or are you just saying, make sure I remove
it?

Don't attempt to reply to this thread. Create a new e-mail address in OE.
Use the e-mail address that you can find for me, by visiting the contributors
page. You can also just click on it as a clickable link, as long as you have
javascript enabled. If you do not have javascript enabled, then you won't be
able to see an e-mail address for me on the bottom of that page.


Tom

http://www.access.qbuilt.com/html/expert_contributors.html
http://www.access.qbuilt.com/html/search.html
__________________________________________
 
D

Duane

That's all it was. You did nothing wrong. However, I have had people in the
past who have innocently posted my e-mail address back to a newsgroup post.

Don't attempt to reply to this thread. Create a new e-mail address in OE.
Use the e-mail address that you can find for me, by visiting the contributors
page. You can also just click on it as a clickable link, as long as you have
javascript enabled. If you do not have javascript enabled, then you won't be
able to see an e-mail address for me on the bottom of that page.
Sorry Tom, let me try again. For replying to this newsgroup, it puts
"a..AT..com...." in the message. I'm noticing that others don't have the
e-mail address in their replys. I take it you mean some people will type
your site's e-mail address back to this newsgroup and seeing how much
trouble you take to hide it, it would not be nice! And since you are
talking about me sending you something, you wanted to make sure I didn't do
it. But, for this newsgroup, my OE is version 6 and it puts in the e-mail
address when I hit reply group. Is something not correct or am I supposed
to delete the e-mail address. It also puts in a newsgroup ID number.
 
T

Tom Wickerath

No. I was not able to gain access to your protected tables. However, I don't
really consider myself *that* much of a security hack, since I'm an honest
person. I've never been too interested in investing the time required to
learn how to bypass security in all possible cases. So, in your database, by
using different copies of workgroup information files (one for development
and one for distribution), you seem to be doing a pretty good job.

That said, just because I gave up after playing with it for 20 minutes, do
not make the false assumption that your security is as good as Fort Knox,
because it just ain't so. You'd only be kidding yourself.


Tom

http://www.access.qbuilt.com/html/expert_contributors.html
http://www.access.qbuilt.com/html/search.html
__________________________________________
 
D

Duane

Well, thanks for trying. I'm glad to hear it wasn't as easy as I was
starting to fear. But, you're right, I should only think it's secure for
someone casually trying to gain access without being really determined.
But, 20 minutes seems quite a bit of effort so this method does appear
better than nothing. All the "recovery" software I've looked at seems to
deal with passwords. Do you know of any places where maybe there's either
contests or challenges of people trying to break Access security - decent
places, that is?

Duane


"Tom Wickerath" wrote
 
T

Tom Wickerath

I know of no such contests or challanges.

Also, the workgroup information file that you sent to me was not the secure
workgroup file that you would have needed to use, in order to allow a user
read access to your protected table. With the .mdw file that you sent to me,
even you would not have been able to create a form or report that allowed a
user to retrieve any of the protected data. At which point the question
becomes why even have the protected table in the database in the first place?
If you send me the correct .mdw file, that allows you to open the protected
tables, but presumably would not allow me to open it, then I'll take another
look at this for you.


Tom

http://www.access.qbuilt.com/html/expert_contributors.html
http://www.access.qbuilt.com/html/search.html
__________________________________________
 
D

Duane

Good point. However, it was just an example and I'm approaching it from two
viewpoints. One is for a manager verses employees. The manager would have
the full access .mdw enabling them to see sensitive information. The
employees would only be able to maintain general information.

The other viewpoint is from the programmers who would not want the user to
see or change the code. But, as stated previously, I guess .mde would take
care of that issue.

I may still send you the design .mdw just to see how easy it would be.

Duane

"Tom Wickerath" wrote
 
J

John Vinson

Good point. However, it was just an example and I'm approaching it from two
viewpoints. One is for a manager verses employees. The manager would have
the full access .mdw enabling them to see sensitive information. The
employees would only be able to maintain general information.

PMFJI but... you don't need (and I'd suggest you shouldn't have) two
separate .mdw files for this purpose. Instead you would have two
*groups* - a privileged group for managers, and a less-privileged one
for peons - defined within the .mdw. Am I missing something?

I routinely start with four security levels: read-only; updating users
who can update the "main" tables; superusers who can update lookup
tables and make form/report changes; and developers who have full
rights to everything, including security. (jvinson is usually in that
group of course <g>...)

John W. Vinson[MVP]
 
T

Tom Wickerath

I may still send you the design .mdw just to see how easy it would be.

Please do.

Your current strategy of supplying different .mdw files is a good one, but
there is still a weak link in the chain and that is human behavior. If a
manager (or anyone else who is linked to the design .mdw file) leaves their
computer to go to a meeting, or lunch, etc. and does not activate a password
protected screensaver, a knowledgeable person could copy the design .mdw file
in a matter of seconds. Once they had that in their possession, they could
work on gaining access to a copy of your database at their leisure, at home.


Tom

http://www.access.qbuilt.com/html/expert_contributors.html
http://www.access.qbuilt.com/html/search.html
__________________________________________
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top