Web-Based DB Application

I have an Access 2000 mdb with a SQL Server 7 back end run on a WAN. The
client is talking about converting it to a web-based application, after
input he got some input suggesting that. (He has a separate web database
which customers use for browsing inventory on the web. The web database is
read-only, and is synchronized nightly with the WAN database so that it
lists current inventory.)

I assume that a web-based application would be written in ASP or Java. Are
there other technologies or applications that would be used specifically for
that purpose?

Also, though a web-based database application would be simpler for this
client (since he has a database on the web that needs to be synchronized
with this one), I assume that a web based db application would be far more
limited in functionality than one written with an MDB front end. Is that
correct?

Any comments/input/etc. regarding this would be appreciated.

Thanks,

Neil

Neil Ginsberg wrote:
> I assume that a web-based application would be written in ASP or Java. Are
> there other technologies or applications that would be used specifically for
> that purpose?

I'm very happy with PHP but I don't know if there is an interface to
Jet. There *is* one for ODBC.

> Also, though a web-based database application would be simpler for this
> client (since he has a database on the web that needs to be synchronized
> with this one), I assume that a web based db application would be far more
> limited in functionality than one written with an MDB front end. Is that
> correct?

Mmm. Functionality may mean several streets of industry.
As of database operations (adding, changing and deleting data) there is
no limit, of course.
Reporting might be different than in an Access environment, but you can
have anything that is possible with XML/CSS--and that is hell of a lot.
All kinds of interface tweaks are also different. Access has a quite
elaborate repertoire of controls with built-in behavior. Whether that is
a benefit or a pain is up to the developer.

I (as professional) have developed a web-able database interface, and I
use it for my own bookkeeping to much satisfaction. I cannot show
samples yet, have been too busy working on other projects. It can be
hired. It is very easy to build applications with, if you are satisfied
with several limits--as with any system.

Please understand I am not advertising here for this product and I
cannot handle requests.
--
Bas Cost Budde, Holland
http://www.heuveltop.nl/BasCB/msac_index.html
I prefer human mail above automated so in my address
replace the queue with a tea

In message <XBzzd.10109$9j5.5649@newsread3.news.pas.earthlink .net>, Neil
Ginsberg <nrg@nrgconsult.com> writes

>I assume that a web-based application would be written in ASP or Java. Are
>there other technologies or applications that would be used specifically for
>that purpose?

There are a lot of different technologies that can be put between an SQL
Server database and the web. If your client already has a
database-backed web site then they will probably already have some
expertise. You should probably aim to use the same technology to avoid
the need for them to support multiple technologies. For instance which
web server do they use, and what scripting language do they use?



--
Bernard Peek
London, UK. DBA, Manager, Trainer & Author. Will work for money.

"Bas Cost Budde" <b.costbudde@heuvelqop.nl> wrote in message
news:cqmgu1$75t$1@news2.solcon.nl...
> Neil Ginsberg wrote:
>> I assume that a web-based application would be written in ASP or Java.
>> Are there other technologies or applications that would be used
>> specifically for that purpose?
>
> I'm very happy with PHP but I don't know if there is an interface to Jet.
> There *is* one for ODBC.

The back end is SQL Server, so that would be fine.
>
>> Also, though a web-based database application would be simpler for this
>> client (since he has a database on the web that needs to be synchronized
>> with this one), I assume that a web based db application would be far
>> more limited in functionality than one written with an MDB front end. Is
>> that correct?
>
> Mmm. Functionality may mean several streets of industry.
> As of database operations (adding, changing and deleting data) there is no
> limit, of course.
> Reporting might be different than in an Access environment, but you can
> have anything that is possible with XML/CSS--and that is hell of a lot.
> All kinds of interface tweaks are also different. Access has a quite
> elaborate repertoire of controls with built-in behavior. Whether that is a
> benefit or a pain is up to the developer.

Definitely a benefit, and what I was referring to by "limitations." The
current interface has much functionality beyond just entering and editing
records that would need to exist.

Some examples of limitations, I'm concerned with:

* Events triggered by interface actions (example: when an item's status is
changed to Sold, an e-mail is automatically sent to accounts receivable).

* Multi-level data display (i.e., subforms/subreports).

* Delays in refreshing data (examples: a) an item is selected in one combo
box, and another combo box gets refreshed; in Access only the combo box gets
refreshed and is almost instantaneous; with a web app, it seems the whole
page needs to be refreshed; b) with a tabbed control in Access, going from
tab to tab is almost instantaneous; in a web app the entire page is
refreshed; etc.).

Thanks,

Neil



>
> I (as professional) have developed a web-able database interface, and I
> use it for my own bookkeeping to much satisfaction. I cannot show samples
> yet, have been too busy working on other projects. It can be hired. It is
> very easy to build applications with, if you are satisfied with several
> limits--as with any system.
>
> Please understand I am not advertising here for this product and I cannot
> handle requests.
> --
> Bas Cost Budde, Holland
> http://www.heuveltop.nl/BasCB/msac_index.html
> I prefer human mail above automated so in my address
> replace the queue with a tea

Neil Ginsberg wrote:

> The back end is SQL Server, so that would be fine.

I have no experience to share about SQL server. :-(

> Definitely a benefit, and what I was referring to by "limitations."

I usually agree with that :-)

> current interface has much functionality beyond just entering and editing
> records that would need to exist.
>
> Some examples of limitations, I'm concerned with:
>
> * Events triggered by interface actions (example: when an item's status is
> changed to Sold, an e-mail is automatically sent to accounts receivable).

A very interesting example. Is it possible to invoke the default email
client from a browser page? I think it is. I do not know the exact
environment.
We have developed our own mail transfer agent for this.

> * Multi-level data display (i.e., subforms/subreports).

I have done that with PHP->HTML, based on a "simple" data dictionary system.

> * Delays in refreshing data

These rely on programming effort for the display engine. That is work
you have to do once, and has already been done in Access, I completely
agree.

> a) an item is selected in one combo
> box, and another combo box gets refreshed; in Access only the combo box gets
> refreshed and is almost instantaneous; with a web app, it seems the whole
> page needs to be refreshed;

It depends. Javascript, for instance, can send and receive HTTP
requests, so it is possible to change just a small portion of a page to
reflect a small change. It takes a little extra thinking.

> b) with a tabbed control in Access, going from
> tab to tab is almost instantaneous; in a web app the entire page is
> refreshed;

This can be done with layers.

Mozilla has a fairly rich language, XUL, to create dynamic forms. I am
still in the learning process for XUL but it looks extremely promising
to me.

From your question I feel that I can do useful work in this area :-)
--
Bas Cost Budde, Holland
http://www.heuveltop.nl/BasCB/msac_index.html
I prefer human mail above automated so in my address
replace the queue with a tea

I this "web" application going to run over the InTERnet? Or is it
restricted to a InTRAnet? If it's an Intranet OR if you know that the
all the users are using Internet Explorer, you should consider using
the Data Access Pages feature of Access.

The idea is that they have two databases -- one for customers over the
Internet, and one used by them over their WAN -- and make them one. So it
would be over their Intranet, and, yes, I think the Data Access Pages
feature is a good idea.

In my opinion, though, the supposed simplicity gained by having one
database, rather than two that are synchronized (as it is now), is eclipsed
by the complexity of rewriting the front end in a format that's not as
straightforward. It seems that just keeping the front end in Access, itself,
is the best solution.

Neil

<rcmail14872@yahoo.com> wrote in message
news:1104174242.469556.302610@z14g2000cwz.googlegr oups.com...
>I this "web" application going to run over the InTERnet? Or is it
> restricted to a InTRAnet? If it's an Intranet OR if you know that the
> all the users are using Internet Explorer, you should consider using
> the Data Access Pages feature of Access.
>