There are lots of better responders out there than myself, but I'll toss in
my 2 cents worth. Having been there I feel the world of web pages and ADO
(Active Data Objects) are almost as foreign to the MsAccess programmer as
the difference in living in downtown New York is to living in a small town
in the South. You both eat, get to work, participate in entertainment, etc.
but you do it very differently. The New Yorker, grabs a bagel, takes the
subway, and sees a Broadway Play.
The Southern Boy, grabs some grits and gravy, races off to work in his Ford
Truck, and pulls the Bass Boat to the lake for the weekend ("My kinda
guy....") ;>
ADO = Active Data Objects, a set of code calls that allows you access to
database functionality.
An ADO call from the Server, gets you the data in a 'recordset' you then
have to build the code to have the server translate that into hypertext
markup language and send it out to the internet client, this can be done in
any of several ways, all using some type of programming language (Active
server pages, Visual Basic, C++, Java, Java server pages, Perl ....). The
server takes all this a sends out a text stream to the internet that can be
used by the Internet client to display information.
and/or
You can use some programming language to produce XML/XSD pages that can be
used by the html page to display the data.
and/or
-----
and/or
----- (there are many ways to get there depending on any of the many
complications your ISP server, your client base,
Now the 'easy answer' is that everyone interested has copies of MsAccess on
their client machines, then you can use DAP's (Data Access Pages built by
MsAccess), connected to a copy of your database on the ISP server. (As far
as I can see these are of most use in the corporate intranet world where you
have a lot of control of what is where, who has access, etc.)
Looking at how these beasts were built and work was a good start for me.
(Note, I tried all the blind alleyways you mention below first, then I found
several more to spend time poking around before I found enlightenment).
You know you are in programming hell when you have to keep a notepad along
side to remind you which programming language to use and if you are writing
code for the client, Active server page, or the data component. Then at one
point I was trying to keep up with writing Active server page 'text output'
to be used on the client as code --- At that point, I got some grits, fired
up the truck and went fishing. I think the fish detected the beer, but what
the hey.
----now that I have had my fun
Bottom line is you don't really just 'connect' your database to the
internet.
You can put a MsAccess file on the ISP location, then using code built to
read that information present it to users, but not through the same forms
reports etc. available in MsAccess, unless you can use the Data Access Page
utilities to build the pages, then there is a very big difference in what
you can do.
If you want your users to be able to make changes to the pages on the web,
that adds a very large level of complexity.
Tools like Visual Studio have made some of this easier and the acceptance
and use of XML as a data transportation layer has greatly changed the
specifics, but the overall process remains.
DataStore --> DataSet -->Server (process)-->Internet--> Display (process) on
Client --> Capture responses --> Process on Client --> Internet --> Server
(process) --> Dataset --> DataStore.
Hopefully someone else can be of a lot more specific help and assistance.
Ed Warren.
