When do we use Data Access Page ?

  • Thread starter Thread starter Mark
  • Start date Start date
M

Mark

I am new to Data Access Page.

I would like to know in what circumstance do we use DAP ?
Just like - Allow users to retrieve / modify data via
their Internet Browsers ? Is it commonly used ? Is it
used mainly in Intranet OR is it used in Internet for
public access ? What is the disadvantage of DAP ?

Thank you.
 
I am new to Data Access Page.
I would like to know in what circumstance do we use DAP ?
Just like - Allow users to retrieve / modify data via
their Internet Browsers ? Is it commonly used ? Is it
used mainly in Intranet OR is it used in Internet for
public access ? What is the disadvantage of DAP ?
Click to expand...

DAP is totally new to me. Correct me if I am wrong.

I believe DAP uses a browser as a front end running in the client
computer to get access to data stored in the server. This is one-step
closer to the "server-central" universe than the regular
"client-server" approach that we normally use when we use MS-Access.

In the normal "client-server" approach, the client software (such as
MS-Access forms) handles all the user-interface. It only needs to go
to the server for data. Here, a lot of work are being done in the
client computer.

In the "browser-front-end" approach, a server (may be a web server)
retrieves data from a database server, and dynamically generates a web
page and sends it to the client PC. The client PC uses a browser as a
front end to open that web page. In other words, most of the jobs are
being done in the server. The client computer only needs to display
the web page, getting input from the user, and running some minimum
number of scripts that act on the web page.

I believe DAP is one of the "browser-front-end" approach.

Some of my programs uses the regular "client server" approach, and
some of mine use the "browser-front-end" approach (using Apache and
Perl).

My experience tells me that the "browser-front-end" approach is great
for system-installation and system-maintenance. When I need to change
a "browser-front-end" program, I can easily change it in the server
and be done with it. On the other hand, after I have changed a
"client-server" program, I will need to go around manually updating
the program (SMS may help in this regard), or I will need all the
programs to be centrally stored in the server. When I need to install
a "client-server" program, I probably need to map a network drive,
install an ODBC connection, making sure the PC can run
ISQL/OSQL...etc, and multiply by the number of computers. There is a
lot of work involved. Consequently, my "browser front end" programs
cause the least headache to me. Therefore, if I have a choice, I will
almost always choose the "browser front end" approach just for this
reason alone.

After saying this, I should warn you that this ease of maintenance is
only true if the "browser front end" program doesn't require a lot of
add-ons. From the experience with seeing another "browser front end"
program that uses a number of add-ons, that program is not
trouble-free whenever it or its-add-ons need to be updated.

The down side of using the "browser front-end" approach is that the
"interactivity" tends to be less than the "client server" approach.
The reason is that the program needs to go back to the server to get
the next page generated. Users will complain if we use the "browser
front end" approach to write a program that demands a lot of
user-interactivity.

Good luck with whatever that you will choose.

Jay Chan
 
The reason that I personally don't use them is that they are so unlike
anything else in Access that creating them means learning a whole new set of
development skills. That's fine, I enjoy learning new skills, but if I need
to develop a new set of skills to develop web-based applications, why would
I learn a technology that restricts access (no pun intended) to users with a
Microsoft Office licence and a recent version of Internet Explorer, when I
could do the same thing using other technologies, such as ASP.NET, that
produce pages that will work with almost any browser, on almost any
computer?

A second, but not insignificant, reason to prefer an alternative technology
is that you're more likely to find help. If you have a problem with ASP or
ASP.NET, there are countless web sites and newsgroups where you can find
help, while the majority of DAP questions I see in the newsgroups go largely
unanswered.
 
Back
Top