By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,490 Members | 892 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,490 IT Pros & Developers. It's quick & easy.

Access on the Web

P: n/a
I have been using Access 2003 for about a year and I am trying to find
out how to create a web test environment to try and transition some of
my Access applications on to the web. My stumbling block is that I do
not know how to create the web server environment. If anyone knows of a
good starting point on how to learn this it would be most appreciated
because I am unsure of what questions to even ask.

Regards,
Bill Mahoney
The Alcott Group

Nov 13 '05 #1
Share this Question
Share on Google+
21 Replies


P: n/a
Madingo wrote:
I have been using Access 2003 for about a year and I am trying to find
out how to create a web test environment to try and transition some of
my Access applications on to the web. My stumbling block is that I do
not know how to create the web server environment. If anyone knows of a
good starting point on how to learn this it would be most appreciated
because I am unsure of what questions to even ask.

Regards,
Bill Mahoney
The Alcott Group


I came across an advertisement yesterday:

http://www.asp-generator.com/

I would love to hear of anyone's experience using this product to
convert Access to ASP. I found it hard to ignore the garish nature of
the advertising.

James A. Fortune

Nov 13 '05 #2

P: n/a
Jet (sometimes called "Access") databases can be used with various web
development techniques. Access' own Data Access Pages require that the user
have Microsoft Internet Explorer 5.5 or later and have installed the Office
Web Extensions (so are useful primarily in intranets), Front Page with the
Database Interaction Wizard is somewhat limited in database functionality
but not in audience, some third-party products like Cold-Fusion can use
Access databases but require the Cold Fusion Server be installed on your
website, and Active Server Pages (ASP) and ASP.NET require that your web
server be running Windows (as does the Jet database engine itself). You can
use Access on a Windows machine networked to a non-Windows server with some
web development languages.

My suggestion is, if you plan to stick with Microsoft software and want to
develop applications for the web, learn Microsoft's .NET. An easier
starting point for an Access person would be VB.NET and ASP.NET, but there
are other Microsoft .NET languages -- C# (pron. C-Sharp), and C++, plus
other vendors' languages COBOL for example.

If you plan to venture outside the Microsoft fold, then you need to look at
what environments/platforms and languages are common in "the rest of the
computer world". This isn't the best place to get that information.

Larry Linson
Microsoft Access MVP

"Madingo" <bi***@alcottgroup.com> wrote in message
news:11**********************@g14g2000cwa.googlegr oups.com...
I have been using Access 2003 for about a year and I am trying to find
out how to create a web test environment to try and transition some of
my Access applications on to the web. My stumbling block is that I do
not know how to create the web server environment. If anyone knows of a
good starting point on how to learn this it would be most appreciated
because I am unsure of what questions to even ask.

Regards,
Bill Mahoney
The Alcott Group

Nov 13 '05 #3

P: n/a
ji********@compumarc.com wrote:
Madingo wrote:
I have been using Access 2003 for about a year and I am trying to find
out how to create a web test environment to try and transition some of
my Access applications on to the web. My stumbling block is that I do
not know how to create the web server environment. If anyone knows of a
good starting point on how to learn this it would be most appreciated
because I am unsure of what questions to even ask.

Regards,
Bill Mahoney
The Alcott Group

I came across an advertisement yesterday:

http://www.asp-generator.com/

I would love to hear of anyone's experience using this product to
convert Access to ASP. I found it hard to ignore the garish nature of
the advertising.

James A. Fortune

Take a look at the info I collected on this subject:

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

Bob
Nov 13 '05 #4

P: n/a
Bob Alston <tu****************@cox.net> wrote in
news:Sjiwe.5129$4o.4772@fed1read06:
Take a look at the info I collected on this subject:

http://members.cox.net/tulsaalstons/...ft%20Access%20
Developer%20Transition%20to%20Internet.htm


That's a good article that I'll bookmark, but it seems to me to be
handicapped by the failure to clearly distinguish between Access and
Jet. You keep using the term "Access" for cases where the MDB file
is being used only as a data store. That just makes the whole issue
more confusing.

For all practical purposes, there isn't any way to use an Access
application on the web (this is basically what you say).

But there are plenty of ways to build web applications using a Jet
MDB as your data store.

That said, let me emphasize your point about knowing the hosting
environment: I don't use Jet for any web development because I don't
think Windows is suitable for a web server, except on an Intranet.
The only valid hosting environment, in my opinion, is with Apache as
your web server. That means no real ASP development, and mostly no
Microsoft server technologies.

I'm fine with that.

Other people aren't.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 13 '05 #5

P: n/a
David W. Fenton wrote:
Bob Alston <tu****************@cox.net> wrote in
news:Sjiwe.5129$4o.4772@fed1read06:

Take a look at the info I collected on this subject:

http://members.cox.net/tulsaalstons/...ft%20Access%20
Developer%20Transition%20to%20Internet.htm

That's a good article that I'll bookmark, but it seems to me to be
handicapped by the failure to clearly distinguish between Access and
Jet. You keep using the term "Access" for cases where the MDB file
is being used only as a data store. That just makes the whole issue
more confusing.

For all practical purposes, there isn't any way to use an Access
application on the web (this is basically what you say).

But there are plenty of ways to build web applications using a Jet
MDB as your data store.

That said, let me emphasize your point about knowing the hosting
environment: I don't use Jet for any web development because I don't
think Windows is suitable for a web server, except on an Intranet.
The only valid hosting environment, in my opinion, is with Apache as
your web server. That means no real ASP development, and mostly no
Microsoft server technologies.

I'm fine with that.

Other people aren't.

While I agree that my approach of using Access as a database server
within Windows is primarily only using Jet, I would not know how to
deploy jet directly to accomplish this same thing, except by storing an
MDB file on the server.

Regarding Windows not being an appropriate place to build web apps, I
strongly disagree. My IT team built a large web application using
windows servers (many of them) which did $100 million in business in its
first 100 days. Of course, it did not use an Access database but rather
SQL and interfaces to a mainframe.

Bob
Nov 13 '05 #6

P: n/a
Thanks for the help and that article was interesting. I do have visual
studio.NET. Is there any books you recommend so as to get an
understanding of how to use it? Also am I understanding correctly that I
can't put my Access applications on the web but that I can only use
Access to just store the data? Thanks again for the help.

Regards,
Bill Mahoney

*** Sent via Developersdex http://www.developersdex.com ***
Nov 13 '05 #7

P: n/a
William Mahoney wrote:
Thanks for the help and that article was interesting. I do have visual
studio.NET. Is there any books you recommend so as to get an
understanding of how to use it? Also am I understanding correctly that I
can't put my Access applications on the web but that I can only use
Access to just store the data? Thanks again for the help.

Regards,
Bill Mahoney

*** Sent via Developersdex http://www.developersdex.com ***

Correct. You can only use Access on the web to store the data. I think
queries work as well as tables. Access forms don't work on the web.
And forget about DAP pages unless you plan an internal intranet only.

Suggest you go to your local bookstore and browse through their books.
Also Amazon has a good selection but you can't browse thru them.

Be sure to take a look at Visual Web Developer 2005 Express Edition Beta
2 which is currently free from Microsoft. With it and .NET you can
create straightforward forms for add/edit/delete without any code. Thus
this is getting closer (but still a long way off) from Access native
windows capabilities.

Bob
Nov 13 '05 #8

P: n/a
Bob Alston <tu****************@cox.net> wrote in
news:0GAwe.7198$4o.1167@fed1read06:
William Mahoney wrote:
Thanks for the help and that article was interesting. I do have
visual studio.NET. Is there any books you recommend so as to get
an understanding of how to use it? Also am I understanding
correctly that I can't put my Access applications on the web but
that I can only use Access to just store the data? Thanks again
for the help.
Correct. ou can only use Access on the web to store the data. . .


This is precisely why I would not use the term "Access" to describe
what you are doing. Your website is NOT using Access -- it's using
Jet. Access is not installed on the web server -- it probably has
the MDAC with Jet installed in order to interface with your MDB
file.

It's this mixture of "Access" and "Jet" as terms that I object to
because it confuses what purpose you are using the MDB for.

Since your whole article is built around demonstrating that there is
nothing in your Access application that usefully can be ported to
the web, you are doing yourself a dis-service by not making and
maintaining this distinction.

The fact that someone posts and asks the question again after I just
made it shows how bad the problem is.
. . . I
think queries work as well as tables. . . .


Queries are JET objects, just as tables are, so, yes, the web server
is likely to be able to use them.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 13 '05 #9

P: n/a
Bob Alston <tu****************@cox.net> wrote in
news:wSkwe.5516$4o.3588@fed1read06:
David W. Fenton wrote:
Bob Alston <tu****************@cox.net> wrote in
news:Sjiwe.5129$4o.4772@fed1read06:

Take a look at the info I collected on this subject:

http://members.cox.net/tulsaalstons/...soft%20Access% 20 Developer%20Transition%20to%20Internet.htm

That's a good article that I'll bookmark, but it seems to me to
be handicapped by the failure to clearly distinguish between
Access and Jet. You keep using the term "Access" for cases where
the MDB file is being used only as a data store. That just makes
the whole issue more confusing.

For all practical purposes, there isn't any way to use an Access
application on the web (this is basically what you say).

But there are plenty of ways to build web applications using a
Jet MDB as your data store.

That said, let me emphasize your point about knowing the hosting
environment: I don't use Jet for any web development because I
don't think Windows is suitable for a web server, except on an
Intranet. The only valid hosting environment, in my opinion, is
with Apache as your web server. That means no real ASP
development, and mostly no Microsoft server technologies.

I'm fine with that.

Other people aren't.

While I agree that my approach of using Access as a database
server within Windows is primarily only using Jet, I would not
know how to deploy jet directly to accomplish this same thing,
except by storing an MDB file on the server.


Since you're not installing Access on the server, you're *not*
deploying Jet. If the web host supports MDBs (they will probably say
"we support Access databases" when what they mean is "we support Jet
databases"), they already have JET installed.

Making an MDB with Access does not automagically carry with it the
Jet database engine. A server that has neither Access nor Jet
installed on it won't be able to read the data tables in your
Access-created MDB.
Regarding Windows not being an appropriate place to build web
apps, I strongly disagree. My IT team built a large web
application using windows servers (many of them) which did $100
million in business in its first 100 days. Of course, it did not
use an Access database but rather SQL and interfaces to a
mainframe.


I strongly disagree on Windows as an appropriate web server. The IIS
disasters of the past couple of years show that Microsoft doesn't
know what they are doing in regards to security.

Likewise, I have found Windows hosting to be more expensive than the
corresponding non-Windows hosting.

I started out getting into this by learning Cold Fusion. It was
great -- I was up and running with a useful Web application in 8
hours, including download/install time. But then I couldn't find a
suitable host for it.

I eventually switched to PHP running on Apache. It's not as easy for
me as a VBA programmer, but it runs almost everywhere, and there are
literally hundreds of choices for inexpensive hosting.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 13 '05 #10

P: n/a
David W. Fenton wrote:
Bob Alston <tu****************@cox.net> wrote in
news:wSkwe.5516$4o.3588@fed1read06:

David W. Fenton wrote:
Bob Alston <tu****************@cox.net> wrote in
news:Sjiwe.5129$4o.4772@fed1read06:

Take a look at the info I collected on this subject:

http://members.cox.net/tulsaalstons/...soft%20Access%
2
0 Developer%20Transition%20to%20Internet.htm
That's a good article that I'll bookmark, but it seems to me to
be handicapped by the failure to clearly distinguish between
Access and Jet. You keep using the term "Access" for cases where
the MDB file is being used only as a data store. That just makes
the whole issue more confusing.

For all practical purposes, there isn't any way to use an Access
application on the web (this is basically what you say).

But there are plenty of ways to build web applications using a
Jet MDB as your data store.

That said, let me emphasize your point about knowing the hosting
environment: I don't use Jet for any web development because I
don't think Windows is suitable for a web server, except on an
Intranet. The only valid hosting environment, in my opinion, is
with Apache as your web server. That means no real ASP
development, and mostly no Microsoft server technologies.

I'm fine with that.

Other people aren't.


While I agree that my approach of using Access as a database
server within Windows is primarily only using Jet, I would not
know how to deploy jet directly to accomplish this same thing,
except by storing an MDB file on the server.

Since you're not installing Access on the server, you're *not*
deploying Jet. If the web host supports MDBs (they will probably say
"we support Access databases" when what they mean is "we support Jet
databases"), they already have JET installed.

Making an MDB with Access does not automagically carry with it the
Jet database engine. A server that has neither Access nor Jet
installed on it won't be able to read the data tables in your
Access-created MDB.

Regarding Windows not being an appropriate place to build web
apps, I strongly disagree. My IT team built a large web
application using windows servers (many of them) which did $100
million in business in its first 100 days. Of course, it did not
use an Access database but rather SQL and interfaces to a
mainframe.

I strongly disagree on Windows as an appropriate web server. The IIS
disasters of the past couple of years show that Microsoft doesn't
know what they are doing in regards to security.

Likewise, I have found Windows hosting to be more expensive than the
corresponding non-Windows hosting.

I started out getting into this by learning Cold Fusion. It was
great -- I was up and running with a useful Web application in 8
hours, including download/install time. But then I couldn't find a
suitable host for it.

I eventually switched to PHP running on Apache. It's not as easy for
me as a VBA programmer, but it runs almost everywhere, and there are
literally hundreds of choices for inexpensive hosting.

David -

Thanks for the clarification. I think I get it now.

I was incorrect to say that one would "deploy jet" in a web
application; equally incorrect to state that one would use an Access
database in a web application, even if one were to create tables and
queries using Access and saved into an MDB file and access it via a web
application; I should have more correctly stated that one would "build
web applications using a Jet MDB as your data store".

Bob
Nov 13 '05 #11

P: n/a
rkc
Bob Alston wrote:
Take a look at the info I collected on this subject:


Here's what I have been looking into recently.

1)Server side scripts that take Http requests, access the data store
and return result sets via the response stream.

2)An Access client that posts http requests via MS XmlHttp methods to
the server side scripts and displays results in Access forms.

At the momment I am using ASP/ADO and returning the resultsets as
delimited strings using recordset.getstring. The amount of coding
required is no more than that required to build suitable html
documents to view results. The look and feel is virtual identical
to what it would be using a local .mdb as the data source.
Nov 13 '05 #12

P: n/a
Bob Alston <tu****************@cox.net> wrote in
news:0jJwe.8471$4o.4318@fed1read06:
I was incorrect to say that one would "deploy jet" in a web
application; equally incorrect to state that one would use an
Access database in a web application, even if one were to create
tables and queries using Access and saved into an MDB file and
access it via a web application; I should have more correctly
stated that one would "build web applications using a Jet MDB as
your data store".


Exactly right! If you'd judiciously edit your web page to reflect
that idea, it would become an excellent resource for us here in this
newsgroup to point people to when they ask this question, without
any reservations.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 13 '05 #13

P: n/a
rkc <rk*@rochester.yabba.dabba.do.rr.bomb> wrote in
news:GA******************@twister.nyroc.rr.com:
Bob Alston wrote:
Take a look at the info I collected on this subject:


Here's what I have been looking into recently.

1)Server side scripts that take Http requests, access the data
store and return result sets via the response stream.

2)An Access client that posts http requests via MS XmlHttp methods
to the server side scripts and displays results in Access forms.

At the momment I am using ASP/ADO and returning the resultsets as
delimited strings using recordset.getstring. The amount of coding
required is no more than that required to build suitable html
documents to view results. The look and feel is virtual identical
to what it would be using a local .mdb as the data source.


That sounds pretty damned interesting. You're using HTTP as your
networking protocol.

Are there authentication issues involved there? Is that done via
..htaccess on the server, or via the db engine's authentication, or
via http submits?

What kind of recordset do you end up with behind your forms? A
disconnected ADO recordset?

Or is it basically a matter of shipping SQL update/insert statements
back and forth across the HTTP connection?

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 13 '05 #14

P: n/a
David W. Fenton wrote:
rkc <rk*@rochester.yabba.dabba.do.rr.bomb> wrote in
news:GA******************@twister.nyroc.rr.com:

Bob Alston wrote:

Take a look at the info I collected on this subject:


Here's what I have been looking into recently.

1)Server side scripts that take Http requests, access the data
store and return result sets via the response stream.

2)An Access client that posts http requests via MS XmlHttp methods
to the server side scripts and displays results in Access forms.

At the momment I am using ASP/ADO and returning the resultsets as
delimited strings using recordset.getstring. The amount of coding
required is no more than that required to build suitable html
documents to view results. The look and feel is virtual identical
to what it would be using a local .mdb as the data source.

That sounds pretty damned interesting. You're using HTTP as your
networking protocol.

Are there authentication issues involved there? Is that done via
..htaccess on the server, or via the db engine's authentication, or
via http submits?

What kind of recordset do you end up with behind your forms? A
disconnected ADO recordset?

Or is it basically a matter of shipping SQL update/insert statements
back and forth across the HTTP connection?

Sounds like what Data Access Pages do. They work from the HTML end.

Bob
Nov 13 '05 #15

P: n/a
David W. Fenton wrote:
Bob Alston <tu****************@cox.net> wrote in
news:0jJwe.8471$4o.4318@fed1read06:

I was incorrect to say that one would "deploy jet" in a web
application; equally incorrect to state that one would use an
Access database in a web application, even if one were to create
tables and queries using Access and saved into an MDB file and
access it via a web application; I should have more correctly
stated that one would "build web applications using a Jet MDB as
your data store".

Exactly right! If you'd judiciously edit your web page to reflect
that idea, it would become an excellent resource for us here in this
newsgroup to point people to when they ask this question, without
any reservations.

Nah. I think I will continue to use my terminology. I think it is more
easily understood. You build a web app, probably using asp or aspx
technology, place an MDB file you created using Access under windows as
the data store. I still think people using Access will understand
without getting into nusances of whether it is jet database or an Access
database that you are using.

Bob
Nov 13 '05 #16

P: n/a

"Bob Alston" <tu****************@cox.net> wrote
I was incorrect to say that one would
"deploy jet" in a web application; equally
incorrect to state that one would use an Access
database in a web application, even if one
were to create tables and queries using
Access and saved into an MDB file and
access it via a web application; I should
have more correctly stated that one would
"build web applications using a Jet MDB
as your data store".


It would be a "sin" of much greater magnitude if Microsoft had not set us
the example of often using "Access" and "Jet" more or less interchangeably
when they refer to MDB database files. I'm sure the Computer Gods have
forgiven you, Bob. <GRIN>

There have even been times(rare I should hope) that _I_ have used the two
interchangeably, and I'll bet there aren't many Access folk, no matter how
experienced, who don't do so now and then.

Larry Linson
Nov 13 '05 #17

P: n/a
rkc
David W. Fenton wrote:
At the momment I am using ASP/ADO and returning the resultsets as
delimited strings using recordset.getstring. The amount of coding
required is no more than that required to build suitable html
documents to view results. The look and feel is virtual identical
to what it would be using a local .mdb as the data source.

That sounds pretty damned interesting. You're using HTTP as your
networking protocol.

Are there authentication issues involved there? Is that done via
.htaccess on the server, or via the db engine's authentication, or
via http submits?
I'm not sure what you're asking. I've never had any request I've
posted via MS XmlHttp denied by any site.

If you're asking about security for an application, I haven't
thought about that yet. I'm developing and testing the Asp scripts
locally using IIS and uploading to a Brinkster account to
observe remote response time. I would leave web server security
in the hands of someone who knows what the are doing.
What kind of recordset do you end up with behind your forms? A
disconnected ADO recordset?
A fabricated ADODB.Recordset. The GetString method returns a string
in the form of a .csv file. Fields delimited by a semi-colon, records
seperated by a crlf.
Or is it basically a matter of shipping SQL update/insert statements
back and forth across the HTTP connection?


It's a matter of sending parameters to the ASP pages which then execute
either saved queries defined in the .mdb file or execute sql statements
defined in the script.





Nov 13 '05 #18

P: n/a
rkc <rk*@rochester.yabba.dabba.do.rr.bomb> wrote in
news:db*****************@twister.nyroc.rr.com:
David W. Fenton wrote:
At the momment I am using ASP/ADO and returning the resultsets as
delimited strings using recordset.getstring. The amount of coding
required is no more than that required to build suitable html
documents to view results. The look and feel is virtual identical
to what it would be using a local .mdb as the data source.

That sounds pretty damned interesting. You're using HTTP as your
networking protocol.

Are there authentication issues involved there? Is that done via
.htaccess on the server, or via the db engine's authentication,
or via http submits?


I'm not sure what you're asking. I've never had any request I've
posted via MS XmlHttp denied by any site.

If you're asking about security for an application, I haven't
thought about that yet. I'm developing and testing the Asp scripts
locally using IIS and uploading to a Brinkster account to
observe remote response time. I would leave web server security
in the hands of someone who knows what the are doing.


Well, you surely don't want just anyone opening an HTTP connection
to your application's, since that would allow anyone to edit the
data who could find the script URLs.

I don't see any point in it for a LAN, so security *must* be an
integral part of the whole plan, since to be useful, the db server
has to be somewhere out there on the Internet.
What kind of recordset do you end up with behind your forms? A
disconnected ADO recordset?


A fabricated ADODB.Recordset. The GetString method returns a
string in the form of a .csv file. Fields delimited by a
semi-colon, records seperated by a crlf.


How does the updating happen? If you're editing the recordset in an
Access form, when and how does the update get sent? Is it like with
an unbound form?

As you can see, I'm quite ignorant of ADO's fabricated recordsets,
since I don't have any use for them. This kind of thing makes it
interesting to me.
Or is it basically a matter of shipping SQL update/insert
statements back and forth across the HTTP connection?


It's a matter of sending parameters to the ASP pages which then
execute either saved queries defined in the .mdb file or execute
sql statements defined in the script.


And you're passing arguments to ths scripts? Sort of like setting
parameters for and executing a stored procedure on the server?

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 13 '05 #19

P: n/a
rkc
David W. Fenton wrote:
Well, you surely don't want just anyone opening an HTTP connection
to your application's, since that would allow anyone to edit the
data who could find the script URLs.

I don't see any point in it for a LAN, so security *must* be an
integral part of the whole plan, since to be useful, the db server
has to be somewhere out there on the Internet.
There would be no point to any of this for a LAN. It would be for
remote access to a backend via a Web Server using Access as a client
instead of a web browser. Security is an issue. I just don't know
enough about all the options to address it yet. I will have to
learn.
What kind of recordset do you end up with behind your forms? A
disconnected ADO recordset?


A fabricated ADODB.Recordset. The GetString method returns a
string in the form of a .csv file. Fields delimited by a
semi-colon, records seperated by a crlf.

How does the updating happen? If you're editing the recordset in an
Access form, when and how does the update get sent? Is it like with
an unbound form?

As you can see, I'm quite ignorant of ADO's fabricated recordsets,
since I don't have any use for them. This kind of thing makes it
interesting to me.


The fabricated recordset is just a means of displaying the information
in a form. There is no connection to the data source so yes, updates
are handled as they would be in an unbound form. The form's beforeupdate
event is fired if a change has been made. Looking at the field's value
and .oldvalue properties tell you which have been changed. When to
post the changes back to the web server is a choice. It can be done as
the changes happen or they can be tracked and sent later.
Or is it basically a matter of shipping SQL update/insert
statements back and forth across the HTTP connection?


It's a matter of sending parameters to the ASP pages which then
execute either saved queries defined in the .mdb file or execute
sql statements defined in the script.

And you're passing arguments to ths scripts? Sort of like setting
parameters for and executing a stored procedure on the server?


Yes. The parameters are sent to the asp pages in urlencoded name=value
pairs. The same as they would be if a HTML form was submitted.

The script retrieves them from the ASP request.form object and feeds
them to saved queries or plugs them into sql strings and executes the sql.

Everything on the web server works exactly the same as it would if
the requests were coming from web pages. Everything is sent back
to the client exactly as it would be to a web page. The difference
is there is no HTML/CSS/Javascript markup because the presentation
is being done with Access forms and the request/post to the web
server are done from Access via VBA.




Nov 13 '05 #20

P: n/a
rkc wrote:
David W. Fenton wrote:
Well, you surely don't want just anyone opening an HTTP connection
to your application's, since that would allow anyone to edit the
data who could find the script URLs.
I don't see any point in it for a LAN, so security *must* be an
integral part of the whole plan, since to be useful, the db server
has to be somewhere out there on the Internet.

There would be no point to any of this for a LAN. It would be for
remote access to a backend via a Web Server using Access as a client
instead of a web browser. Security is an issue. I just don't know
enough about all the options to address it yet. I will have to
learn.
What kind of recordset do you end up with behind your forms? A
disconnected ADO recordset?
A fabricated ADODB.Recordset. The GetString method returns a
string in the form of a .csv file. Fields delimited by a
semi-colon, records seperated by a crlf.


How does the updating happen? If you're editing the recordset in an
Access form, when and how does the update get sent? Is it like with
an unbound form?


As you can see, I'm quite ignorant of ADO's fabricated recordsets,
since I don't have any use for them. This kind of thing makes it
interesting to me.

The fabricated recordset is just a means of displaying the information
in a form. There is no connection to the data source so yes, updates
are handled as they would be in an unbound form. The form's beforeupdate
event is fired if a change has been made. Looking at the field's value
and .oldvalue properties tell you which have been changed. When to
post the changes back to the web server is a choice. It can be done as
the changes happen or they can be tracked and sent later.
Or is it basically a matter of shipping SQL update/insert
statements back and forth across the HTTP connection?
It's a matter of sending parameters to the ASP pages which then
execute either saved queries defined in the .mdb file or execute
sql statements defined in the script.


And you're passing arguments to ths scripts? Sort of like setting
parameters for and executing a stored procedure on the server?

Yes. The parameters are sent to the asp pages in urlencoded name=value
pairs. The same as they would be if a HTML form was submitted.

The script retrieves them from the ASP request.form object and feeds
them to saved queries or plugs them into sql strings and executes the sql.

Everything on the web server works exactly the same as it would if
the requests were coming from web pages. Everything is sent back
to the client exactly as it would be to a web page. The difference
is there is no HTML/CSS/Javascript markup because the presentation
is being done with Access forms and the request/post to the web
server are done from Access via VBA.




And, instead of all this, you could use Microsoft's new Visual Web
Developer Express 2005 Beta 2 which can create forms for
add/change/delete using an Access/Het DB - without your needing to do
any coding!

More info on various Access web generators can be found:
http://members.cox.net/tulsaalstons/...20Internet.htm

Bob
Nov 13 '05 #21

P: n/a
rkc
Bob Alston wrote:
rkc wrote: And, instead of all this, you could use Microsoft's new Visual Web
Developer Express 2005 Beta 2 which can create forms for
add/change/delete using an Access/Het DB - without your needing to do
any coding!

More info on various Access web generators can be found:
http://members.cox.net/tulsaalstons/...20Internet.htm


I read your article the first time you mentioned it.
All of those solutions take the user from the Access gui environment
to a web browser environment. I'm looking for a way to avoid that.
Nov 13 '05 #22

This discussion thread is closed

Replies have been disabled for this discussion.