Data Access Pages DAPs

[Lyle Fairfield]

In a recent thread there has been discussion about Data Access Pages. It
has been suggested that they are not permitted on many or most secure sites.

Perhaps, that it is so, although I know of no site that has this
prohibition, and I have uploaded DAPs to various sites and used them
from those sites.

I do not understand why any site manager would prohibit DAPs. To the
best of my knowledge DAPs, as HTM files, are merely hosted on the remote
site. They do not run on the remote site, as say, an ASP file, runs on a
remote site. When we open a DAP from a remote site, or any other HTM or
HTML file for that matter, the browser downloads the HTML script to the
client machine and runs any code, script or similar technology from the
client machine. This, of course, connects to the database and displays
the data, and except in the case of report type, read only, DAPs allows
for its editing. This is the reason, (along with the economic reason),
why local machines must have specific software installed, and why DAPs
must run within Microsoft Internet Explorer. Just like an ASP file
requiring an ASP installation on the server to run on the server, so a
DAP (HTM) file requires the installation of requisite parts of MS-Office
to run where it runs, that is, on the client machine.

DAPs do not need to be hosted on a web site. They can be distributed, by
e-mail or through network file transfer or any other way and run
directly on machines meeting the conditions already described.

Are DAPs secure? They show all the information of the Access application
connection string in their HTML source. This includes Sever Name,
Database Name, Source, User Name, and, if it has been saved in the
Access application, the Password. So they may be as secure as your
application, without however, having available all the security
provisions of Access.
My preference is to restrict access to this information. So I do not
save Passwords and I distribute DAPs privately via e-mail, or I store
them on a web site which requires an NT login, user name and password
distinct from the database server user name and password. By doing the
latter, I achieve immediate update to the latest version simply by
replacing the DAP file on the server.

DAPs are simply machine-made HTM files that use Microsoft Technology to
allow for the display and editing of data. Similar, perhaps better, (for
instance, I conceal and encrypt the connection string), HTM files, with
the same capabilities, can be created by humans and distributed in the
same way. The technology Microsoft uses in the DAP can be used, but
Javascript, ActiveX Objects, and DHTML do a fine job. I have written
about twenty of these, and they have performed well for two years.

I find that DAPs are useful for simple tasks; for example, adding a
payment to a loan table, and showing the state of the loan with
calculated daily interest and balance where no sub-forms and no pull
downs are required.

One of the simplest way to design a DAP to one's liking is to design an
Access Form; after it has been perfected, it can be saved as a DAP and
for the most part, the DAP will have the same functionality and, to a
lesser extent, appearance as the Form.

I'm not a great supporter of DAPs. I use them in the way I have
described, to create quickly simple interfaces that can be distributed
easily. In my opinion they present no problem to hosting sites, are not
especially insecure, not especially resource consuming, and not
especially useful. Like most of Microsoft Technology, when they are
studied and mastered, and implemented carefully, they can be used to
accomplish some limited goals with a minimum investment of time and
resources.

[Bob Alston]

Lyle Fairfield wrote:

In a recent thread there has been discussion about Data Access Pages. It
has been suggested that they are not permitted on many or most secure
sites.

Perhaps, that it is so, although I know of no site that has this
prohibition, and I have uploaded DAPs to various sites and used them
from those sites.

I do not understand why any site manager would prohibit DAPs. To the
best of my knowledge DAPs, as HTM files, are merely hosted on the remote
site. They do not run on the remote site, as say, an ASP file, runs on a
remote site. When we open a DAP from a remote site, or any other HTM or
HTML file for that matter, the browser downloads the HTML script to the
client machine and runs any code, script or similar technology from the
client machine. This, of course, connects to the database and displays
the data, and except in the case of report type, read only, DAPs allows
for its editing. This is the reason, (along with the economic reason),
why local machines must have specific software installed, and why DAPs
must run within Microsoft Internet Explorer. Just like an ASP file
requiring an ASP installation on the server to run on the server, so a
DAP (HTM) file requires the installation of requisite parts of MS-Office
to run where it runs, that is, on the client machine.

DAPs do not need to be hosted on a web site. They can be distributed, by
e-mail or through network file transfer or any other way and run
directly on machines meeting the conditions already described.

Are DAPs secure? They show all the information of the Access application
connection string in their HTML source. This includes Sever Name,
Database Name, Source, User Name, and, if it has been saved in the
Access application, the Password. So they may be as secure as your
application, without however, having available all the security
provisions of Access.
My preference is to restrict access to this information. So I do not
save Passwords and I distribute DAPs privately via e-mail, or I store
them on a web site which requires an NT login, user name and password
distinct from the database server user name and password. By doing the
latter, I achieve immediate update to the latest version simply by
replacing the DAP file on the server.

DAPs are simply machine-made HTM files that use Microsoft Technology to
allow for the display and editing of data. Similar, perhaps better, (for
instance, I conceal and encrypt the connection string), HTM files, with
the same capabilities, can be created by humans and distributed in the
same way. The technology Microsoft uses in the DAP can be used, but
Javascript, ActiveX Objects, and DHTML do a fine job. I have written
about twenty of these, and they have performed well for two years.

I find that DAPs are useful for simple tasks; for example, adding a
payment to a loan table, and showing the state of the loan with
calculated daily interest and balance where no sub-forms and no pull
downs are required.

One of the simplest way to design a DAP to one's liking is to design an
Access Form; after it has been perfected, it can be saved as a DAP and
for the most part, the DAP will have the same functionality and, to a
lesser extent, appearance as the Form.

I'm not a great supporter of DAPs. I use them in the way I have
described, to create quickly simple interfaces that can be distributed
easily. In my opinion they present no problem to hosting sites, are not
especially insecure, not especially resource consuming, and not
especially useful. Like most of Microsoft Technology, when they are
studied and mastered, and implemented carefully, they can be used to
accomplish some limited goals with a minimum investment of time and
resources.

Here is some info from my web site, summarizing what I found about DAPs:

*************** *************** *************** *************** *************** ****

***** IMPORTANT UPDATE *****

UPDATE: When implementing my first app using Data Access Pages, I had
an epiphany and finally realized that my DAPs were still actually using
my local PC database.

I learned more about UseRemoteProvid er and the need to specify a UNC
reference to the database

\\myPCName\DBdi rectory\DBName. mdb

Note that the DBDirectory must be a directory name available for Web
sharing (right click on the directory in Windows Explorer).

Also I just figured out that since the pages are all HTML, there is no
server side processing. All DB processing is client-side via Active
X/ADO. To access the database on a server, in addition to setting the
proper DB location reference and setting useremoteprovid er in the Access
page definition, the server must also be setup properly to support RDS
or Remote Data Services. This is the link between the ActiveX in the
page displayed to the database back on the server.

In my case, I could not get this to work using my own PC as a IIS
server. My PC works just fine for ASP and ASPX pages but not RDS. I
did some reading and found you must also configure a control file called
mdfsmap.ini - but read “Setting up the configuration file (mdfsmap.ini)
for the remote service provider is a bit tricky and needs a bit of
trial and error.” I tried and still can’t get it to work.

Then when doing research on the RDS problems, I find out that Microsoft
has “deprecated” RDS – made it obsolete. Also, it is not widely used if
at all by ISPs due to security concerns. So, even if I could get it to
work, I could not use any public server.

So if you are considering Access data access pages for Internet – forget it.

http://members.cox.net/tulsaalstons/...20Internet.htm


2/9/2005 7:31:48 PM Re: Data Access Page Provider Initialization Failure
The RemoteProvider cannot work without a RDS layer properly configured on

the server side and, bad news, the RDS has been declared deprecated many

years ago by Microsoft for security concerns.

For all practicality, you cannot use DAP to access an MDB datafile over
the

Internet, unless you use RDS or a VPN.

S. L.
http://64.233.167.104/search?q=cache...precated&hl=en
http://www.dbforums.com/archive/index.php/t-891292.html
http://www.highdots.com/forums/acces...e-1919716.html
http://64.233.167.104/search?q=cache...precated&hl=en
Hope some of this info helps.

Bob

[lylefair]

I think you are saying DAPs cannot connect to MDBs resident on a
web-server. I suspect that, like Access, they were not intended to be
connected to MDBs resident on a web-server.
If someone has done this, I would love to hear about it.

[Bob Alston]

lylefair wrote:

I think you are saying DAPs cannot connect to MDBs resident on a
web-server. I suspect that, like Access, they were not intended to be
connected to MDBs resident on a web-server.
If someone has done this, I would love to hear about it.

Yes, you are correct as to what I was saying. but don't you like the
big words I used, like "deprecated ". Sure sounds like you would need a
consultant. <grin>

Also, I erred when I thought it was working when I uploaded to a web
server, tried it and it worked. Of course that was because the database
was also on my PC. So for anyone who thinks they really have it working
on a server, try your web page from another PC, not the one you
developed it on and not one connected via a LAN.

Bob