Opinions on multi-user environment

[Beetle]

I am creating my first multi-user app at work. We have multiple
versions of Access within the company from A2000 to A2007. There is
really only one department/location that will be adding or
manipulating data. All the other departments within the company will
only need to view the data when they choose. There are currently about
twelve departments, and a couple of them reside outside the company
intranet so they will need web access. More departments or groups may
be added later. All the data they need to view comes from the same
table, but I want each dept. to be able to see only the data for their
group.

I'm hoping to get some opinions/advice from some of you experts out
there on the best approach for this.

1) Split the db and give each dept. a FE with a couple of uneditable
forms that display the data based on user groups/passwords? Will I run
into problems because of the different versions of Access?

2) Create Data Access Pages and have them just view the data in their
browser? Not much experience with DAPs, so I don't know what I might
run into.

3) Some other approach?

Apologies as I don't currently have much experience in this area. I
can figure out the how, but I'm interested in your opinions on best
practice.

TIA for any advice

 

[Tom van Stiphout]

On Thu, 24 Jan 2008 20:20:23 -0800 (PST), "Beetle

DAP: it was never more than (in the words of respected authors Ken
Getz et al) "a version 0.9 implementation". It has wisely been
discontinued in A2007.
For the outside departments you either provide a Terminal Server
solution so they can use the same Access app, or you need to write a
web app. If the latter, might as well do the entire thing as a webapp:
why create two user interfaces?
If you use A2000 file format and test in all versions of Access, you
should have no problems.
If you are a rookie at this, you might want to allocate some time and
money for professional help. "Microsoft Solution Provider" in your
yellow pages comes to mind.

-Tom.

 

[Beetle]

DAP: it was never more than (in the words of respected authors Ken

Getz et al) "a version 0.9 implementation". It has wisely been
discontinued in A2007.

Guess that explains why nobody ever talks about/uses them.

Thanks for the advice Tom

 

[Ron]

I wrote my first Access database and linked up with the internet and believe
it or not it wasn't that bad. What kind of a timeline have they given you??
How big is the database?? How active is the activity on the db?? How much
do you really know about Access??

 

[Albert D. Kallal]

message

1) Split the db and give each dept. a FE with a couple of uneditable
forms that display the data based on user groups/passwords? Will I run
into problems because of the different versions of Access?

Considering the incredible benefits of a split database system *EVEN* when
you're running in single user mode, it begs the question why you not split
your databases years ago? This likely one of the first basic fundamental
rules that any seasoned access developer will learn.

So the answer is if you have a split database, then you simply provide a
front end (which should be a mde by the way) to each individual user's
desktop. And, when I say each desktop we're talking about installing this
front end on each computer (If you don't take this approach then you have
lots of corruption occurring).

the additional benefit of a split system is there's never a problem running
access 2000, and 2007 at the same time. (you simply leave the backend data
in access 2000 format). Thus as new machines are purchased, they usually
have the new version of office you standardize on for the next few years.
So, as you upgrade machines one by one you can thus simply deploy the
"newer" version front end to thost machines. Eventually over time you'll
wind up with only one standardize front and for all machines.

So one major benefit of a split system is that you simply provide a correct
version of the front end to those users that are running that particular
version of access. I not only tell you to split, but more importantly I tell
you from up *developers* perspective point of view as to why you split in
the follwing article of mine:

(in other words I want you to start thinking like a developer here, and not
like an end user of MS access).

Why we split:
http://www.members.shaw.ca/AlbertKallal/Articles/split/index.htm

2) Create Data Access Pages and have them just view the data in their
browser? Not much experience with DAPs, so I don't know what I might
run into.

As mentioned if you're looking for technology to convert your existing
application that allows a person on the web from anywhere in the world to
use the appliation without modification, then a terrific solution is what's
called windows terminal services.

I explain your options for remote use of your data in the following article:

http://www.members.shaw.ca/AlbertKallal//Wan/Wans.html

 

[Beetle]

Albert

Thanks very much for your response.

Considering the incredible benefits of a split database system *EVEN* when
you're running in single user mode, it begs the question why you not split
your databases years ago? This likely one of the first basic fundamental
rules that any seasoned access developer will learn.

To answer your question, my apps are split but only in a single user/pc
environment. To clarify a little bit. I've been working with/learning Access
for a few years now but the apps I've created have been for reasons outside
of my work. My company goes to the expense of paying licensing fees for
copies of Office, but for the most part they don't use it to it's potential.
They try to use overblown spreadsheets for everything. So I took it upon
myself to create an Access db for this particular department (I'm willing to
donate my time on this one, if they want more they'll have to compensate me).
My original intent was that only they would be using it, but now that they
have seen it, they really like it and want other departments to be able to
view some of the data. The db itself is not that complex.

So, I was just looking for a little friendly advice on the multi-user/web
access approach before getting into it. Again, I do appreciate you advice you
have provided.

I'm starting a little late in life I suppose (I'm 40 as of this post) but I
have become very interested in Access development over the last few years,
and the help that you and all the other experts in this forum (Dave Hargis,
John Vinson, Doug Steele, too many others to list) take the time to provide
has been an immense help in the learning curve.