Using Access/Jet on Web site

[Serious_Practitioner]

Good day all, and thank you in advance for your help. No - MANY thanks in
advance for your help - I know nothing about using databases on Web servers.

I am about to discuss a project with a client who is in the apartment rental
business. He solicits "For Rent" listings from property owners and managers,
advertises the apartments, shows them, takes applications and like that. His
inventory, as it were, is a list of vacant apartments that his clients have
asked him to rent.

My client wants to have an inventory control database for use in the office
so that if someone comes in looking for two bedrooms in a place that takes
dogs, for instance, he and/or his agents can run a query to see what's
available. Or, any of them can run a different or less restrictive query for
someone who has fewer requirements...you all get the basic idea here.
Information and ways to get it out...that's what he wants to do.

I can create the database - I have, in fact, created a very similar one, for
my own use with my own properties, that I am going to "spiff up" to use as a
simple demo. The potential rub is that my client may - MAY - want to make
the inventory, or a subset of it, available to Web surfers to search (and
he'd be a fool not to, since all of his competitors do so now). So, I have a
couple of questions -

1. If I understand what I've read correctly, a Web host that says that it
supports "Access" is really
supporting Jet, and that the customer of the host loads just the tables
to the host. Yes?
2. The forms, reports, queries and so forth that we see in the desktop
product aren't supported on
Web servers; they have to be created either as part of Data Access Pages
or with scripts. Yes?
3. If he just loads the tables, as in #1, do the tables need to be created
with particular properties to
use them on the Web, and if they have to have those properties, can they
be used with those
properties in the local office with the desktop machines? In other words,
if we plan to use the
tables on the Web, can we use the same tables and properties in the
office?

For what it's worth, the use in the office will be light. It's not that big
a place. The use on the Web probably won't be as heavy as I have read is
necessary to strain an "Access" database on a Web server.

Any and all info will be appreciated, as well as suggestions on where to get
info.

Happy Memorial Day!
Steve E.

[Bob Alston]

Serious_Practitioner wrote:

Good day all, and thank you in advance for your help. No - MANY thanks in
advance for your help - I know nothing about using databases on Web servers.

I am about to discuss a project with a client who is in the apartment rental
business. He solicits "For Rent" listings from property owners and managers,
advertises the apartments, shows them, takes applications and like that. His
inventory, as it were, is a list of vacant apartments that his clients have
asked him to rent.

My client wants to have an inventory control database for use in the office
so that if someone comes in looking for two bedrooms in a place that takes
dogs, for instance, he and/or his agents can run a query to see what's
available. Or, any of them can run a different or less restrictive query for
someone who has fewer requirements...you all get the basic idea here.
Information and ways to get it out...that's what he wants to do.

I can create the database - I have, in fact, created a very similar one, for
my own use with my own properties, that I am going to "spiff up" to use as a
simple demo. The potential rub is that my client may - MAY - want to make
the inventory, or a subset of it, available to Web surfers to search (and
he'd be a fool not to, since all of his competitors do so now). So, I have a
couple of questions -

1. If I understand what I've read correctly, a Web host that says that it
supports "Access" is really
supporting Jet, and that the customer of the host loads just the tables
to the host. Yes?
2. The forms, reports, queries and so forth that we see in the desktop
product aren't supported on
Web servers; they have to be created either as part of Data Access Pages
or with scripts. Yes?
3. If he just loads the tables, as in #1, do the tables need to be created
with particular properties to
use them on the Web, and if they have to have those properties, can they
be used with those
properties in the local office with the desktop machines? In other words,
if we plan to use the
tables on the Web, can we use the same tables and properties in the
office?

For what it's worth, the use in the office will be light. It's not that big
a place. The use on the Web probably won't be as heavy as I have read is
necessary to strain an "Access" database on a Web server.

Any and all info will be appreciated, as well as suggestions on where to get
info.

Happy Memorial Day!
Steve E.

See my earlier response today to another question on putting Access on
the web.

Specific answers to you questions:

1. No. You typically load the entire access database, database.mdb, on
the server. The web app then accesses it.

2. Correct the normal access queries, forms and reports can't be used on
the web.

Don't even try to use Data Access Pages. See the link in my prior post
for more info on that.

No you don't have to use scripts to create the screens. You can build
web sites using Access databases using a variety of tools such as
Microsoft Front Page and others.

3. Not sure. Haven't done that. Would only work if the web server was
also on your local network. Otherwise, forget it. Probably best if you
were to do all the changes on the local database and then upload a copy
of the database to the web site for read-only access. You could refresh
the database on the web server whenever the data changes.

Bob

[billmiami2]

Some additions to Bob's excellent response:

2. Your queries can and should be used by your web interface as they
are part of Jet (the database portion of your Access "database"). If
your queries use custom functions that you have in code, then those
functions will be used too.

3. The tables should be the same whether you access them from your
Access interface or your web interface. There is no need to change
them to make them more accessible from the web interface. The only
caveat is that because your users on the web will be querying the
tables differently, you made need additional indexing on some tables.
Access should take care of this for you automatically as you create the
reporting queries.

You would be much better off to have the web server on your network
rather than use a 3rd party host as Bob mentioned. However, if you
must use a 3rd party host, you can build your web interface so that it
handles reporting and data viewing/input (forms). In this way, you
wouldn't need an Access interface and you wouldn't need periodic
uploads. If you feel that you must go with the Access UI/DB in the
office and then upload it to the 3rd party web server, then you should
simply copy the entire MDB file--there's no need to strip out parts of
it.

Bill E.
Hollywood, FL

[Carl]

In Reply to your question 2.

The Database Queries can still be executed and using OLE you may
still execute the Reports. Forms would not be accessible, unless
there is some 3rd party software module available.
<bi********@netscape.net> wrote in message
news:11*********************@g14g2000cwa.googlegro ups.com...

Some additions to Bob's excellent response:

2. Your queries can and should be used by your web interface as they
are part of Jet (the database portion of your Access "database"). If
your queries use custom functions that you have in code, then those
functions will be used too.

3. The tables should be the same whether you access them from your
Access interface or your web interface. There is no need to change
them to make them more accessible from the web interface. The only
caveat is that because your users on the web will be querying the
tables differently, you made need additional indexing on some tables.
Access should take care of this for you automatically as you create the
reporting queries.

You would be much better off to have the web server on your network
rather than use a 3rd party host as Bob mentioned. However, if you
must use a 3rd party host, you can build your web interface so that it
handles reporting and data viewing/input (forms). In this way, you
wouldn't need an Access interface and you wouldn't need periodic
uploads. If you feel that you must go with the Access UI/DB in the
office and then upload it to the 3rd party web server, then you should
simply copy the entire MDB file--there's no need to strip out parts of
it.

Bill E.
Hollywood, FL

[Tom]

Carl,

Could you give an example of how to use OLE to execute reports.

Thanks.
"Carl" <mail2carl@_remove_yahoo.com> wrote in message
news:1y*****************@newsfe6-gui.ntli.net...

In Reply to your question 2.

The Database Queries can still be executed and using OLE you may
still execute the Reports. Forms would not be accessible, unless
there is some 3rd party software module available.
<bi********@netscape.net> wrote in message
news:11*********************@g14g2000cwa.googlegro ups.com...

Some additions to Bob's excellent response:

2. Your queries can and should be used by your web interface as they
are part of Jet (the database portion of your Access "database"). If
your queries use custom functions that you have in code, then those
functions will be used too.

3. The tables should be the same whether you access them from your
Access interface or your web interface. There is no need to change
them to make them more accessible from the web interface. The only
caveat is that because your users on the web will be querying the
tables differently, you made need additional indexing on some tables.
Access should take care of this for you automatically as you create the
reporting queries.

You would be much better off to have the web server on your network
rather than use a 3rd party host as Bob mentioned. However, if you
must use a 3rd party host, you can build your web interface so that it
handles reporting and data viewing/input (forms). In this way, you
wouldn't need an Access interface and you wouldn't need periodic
uploads. If you feel that you must go with the Access UI/DB in the
office and then upload it to the 3rd party web server, then you should
simply copy the entire MDB file--there's no need to strip out parts of
it.

Bill E.
Hollywood, FL

[Carl]

The poster asked if it was possible for his customers to view access reports
on the web. As I only use Perl for the CGI I was referring to the
Win32::OLE perl module.

And as you asked, here is the perl code to view access reports on the web:

### START PERL CODE ###

#!/usr/local/bin/perl

use Win32::OLE;
use Win32::OLE::Const 'Microsoft Access';

print "Content-type: text/html\n\n";

# Export Access Report to HTML File or Browser

my $access = Win32::OLE->GetObject("I:\\pathto\\database.mdb", sub
{$_[0]->Quit;}) or die "Error: connecting to Access";
$access->{Visible}=0;
$access->{docmd}->OutputTo(acOutputReport, "ReportName", acFormatHTML,
"I:\\pathto\\report.htm",1);
#$access->Quit;
undef $access;

### END PERL CODE ###

You could even embed the Microsoft snapview.ocx report viewer ActiveX
Control into your webpages.
Follow this link for info: http://support.microsoft.com/kb/q209145
Carl.

"Tom" <no***@email.net> wrote in message
news:1O*****************@newsread2.news.atl.earthl ink.net...

Carl,

Could you give an example of how to use OLE to execute reports.

Thanks.
"Carl" <mail2carl@_remove_yahoo.com> wrote in message
news:1y*****************@newsfe6-gui.ntli.net...

In Reply to your question 2.

The Database Queries can still be executed and using OLE you may
still execute the Reports. Forms would not be accessible, unless
there is some 3rd party software module available.
<bi********@netscape.net> wrote in message
news:11*********************@g14g2000cwa.googlegro ups.com...

> Some additions to Bob's excellent response:
>
> 2. Your queries can and should be used by your web interface as they
> are part of Jet (the database portion of your Access "database"). If
> your queries use custom functions that you have in code, then those
> functions will be used too.
>
> 3. The tables should be the same whether you access them from your
> Access interface or your web interface. There is no need to change
> them to make them more accessible from the web interface. The only
> caveat is that because your users on the web will be querying the
> tables differently, you made need additional indexing on some tables.
> Access should take care of this for you automatically as you create the
> reporting queries.
>
> You would be much better off to have the web server on your network
> rather than use a 3rd party host as Bob mentioned. However, if you
> must use a 3rd party host, you can build your web interface so that it
> handles reporting and data viewing/input (forms). In this way, you
> wouldn't need an Access interface and you wouldn't need periodic
> uploads. If you feel that you must go with the Access UI/DB in the
> office and then upload it to the 3rd party web server, then you should
> simply copy the entire MDB file--there's no need to strip out parts of
> it.
>
> Bill E.
> Hollywood, FL
>

[Serious_Practitioner]

A huge "Thank You" to all who took the time to answer. Feeling much better
equipped to do this now...
Steve E.

Big snip...