Pulling data from Access database into Intranet?

28 Aug 2006 3:42 PM

Stewart

Hi there,

I have an Access database, which contains the details of company staff
and services. The plan is to extract data from this database onto our
forthcoming Intranet (no inserting, updating or deleting at this
point). The Intranet itself has been created in ASP.NET, using
Microsoft Visual Web Developer 2005.

My concern is that we will encounter a slow response when pulling data
from this Access database across the network (should also say that this
database has been secured). We have approximately 250 staff members,
although it is hard to gauge how many staff members will be accessing
the data at any one time.

What I would like to know is, what would be the most effective way of
pulling data from the Access database to the Intranet? For example, I
was looking into splitting the database, converting the backend to SQL,
and linking it. As a relative newbie, I'm wondering if any problems
will arise from this? Or, should I just maybe try using the database
in its current form.

Any help would be greatly appreciated!

Best Regards,
Stewart.

28 Aug 2006 4:04 PM

Bob Alston

Stewart wrote:

Show quote

> Hi there,
>
> I have an Access database, which contains the details of company staff
> and services. The plan is to extract data from this database onto our
> forthcoming Intranet (no inserting, updating or deleting at this
> point). The Intranet itself has been created in ASP.NET, using
> Microsoft Visual Web Developer 2005.
>
> My concern is that we will encounter a slow response when pulling data
> from this Access database across the network (should also say that this
> database has been secured). We have approximately 250 staff members,
> although it is hard to gauge how many staff members will be accessing
> the data at any one time.
>
> What I would like to know is, what would be the most effective way of
> pulling data from the Access database to the Intranet? For example, I
> was looking into splitting the database, converting the backend to SQL,
> and linking it. As a relative newbie, I'm wondering if any problems
> will arise from this? Or, should I just maybe try using the database
> in its current form.
>
> Any help would be greatly appreciated!
>
> Best Regards,
> Stewart.
>

Why don't you try using it in its current form and perhaps testing with
2-3 people to see if you can simulate the load of multiple concurrent
users. If you have the ability to have each of 2-3 people run 2
computers at the same time, then you can probably do a pretty good mini
"load" test with 4-6 concurrent users. If that works, then maybe you
can arrange a test with a larger group of people.

Bob

28 Aug 2006 4:12 PM

Jim Underwood

If you plan on putting the data in SQL Server and linking to it from Access,
this will allow your current users to continue to use the Access front end
for all their work. For web access, you would have your .Net app connect
directly to SQL Server, not to access. At this point Access is for display
purposes only, not for data access. If you do not need the users to use the
Access GUI, then you don't need to use access at all.

Never use an Access database for more than 3 or 4 people if you have a
choice.

Show quote

"Stewart" <Stewa***@vodafone.net> wrote in message
news:1156779769.440214.39190@b28g2000cwb.googlegroups.com...
> Hi there,
>
> I have an Access database, which contains the details of company staff
> and services. The plan is to extract data from this database onto our
> forthcoming Intranet (no inserting, updating or deleting at this
> point). The Intranet itself has been created in ASP.NET, using
> Microsoft Visual Web Developer 2005.
>
> My concern is that we will encounter a slow response when pulling data
> from this Access database across the network (should also say that this
> database has been secured). We have approximately 250 staff members,
> although it is hard to gauge how many staff members will be accessing
> the data at any one time.
>
> What I would like to know is, what would be the most effective way of
> pulling data from the Access database to the Intranet? For example, I
> was looking into splitting the database, converting the backend to SQL,
> and linking it. As a relative newbie, I'm wondering if any problems
> will arise from this? Or, should I just maybe try using the database
> in its current form.
>
> Any help would be greatly appreciated!
>
> Best Regards,
> Stewart.
>

28 Aug 2006 6:11 PM

Larry Linson

"Jim Underwood" wrote

> Never use an Access database for more
> than 3 or 4 people if you have a choice.

Factors in how many users can be supported in multiuser include the
requirements, design, and implementation of the database application and the
hardware, software, and network environments. If all factors are near
perfect, we have reliable reports of over 100 concurrent users. Even if not
all are near perfect, we routinely see reports of 30 - 70 users.

But, in cases where we are rather sure that all are about as far from
perfect as can be, people have reported Access "falling over" with as few as
four users. However, unless your database is in the "about as far from
perfect as can be," you can disregard the dire warnings about so few users.

I'd venture to guess that if someone went out of their way to do everything
wrong, it would be possible to create a database that wouldn't even support
one or two users. <GRIN>

A good website with lots of information on multiuser use of Jet is MVP Tony
Toews' http://www.granite.ab.ca/accsmstr.htm.

Larry Linson
Microsoft Access MVP

13 Sep 2006 2:01 PM

Stewart

Thanks for all your replies - very helpful indeed.

I think I will try a few test runs in its current form, just to see how
it performs (more out of curiousity than anything else!).

However, I'll take your advice and convert the back-end to SQL.
Keeping the Access front-end will be of great benefit as it is
user-friendly for our Administration staff who will be modifying the
data.

Rich P, it is an SQL Server Database (SQL Server 2000), so that should,
in theory, work pretty well.

Stewart.