frontend possibilities for Oracle

If it helps, there are only about 30 tables, and there would only be about 5 users accessing the DB at the same time

I've never come accross any 'turn this Acess form into ASP/JSP/PERL page' tool. The first person to write one that works well enough to be usable in earnest should make a fortune.

A lot will depend on how complex you Access app is and how well it's written. If everything is split up tidily into separte layers (data acess layer, busness logic layer, gui layer), AND the app isn't very complicated, then you could redo the gui in asp (or jsp) fairly easily.
That's not likely in my experience. ASP programmers are cheaper that Oracle programmers ;)

VB(visual basic-frontend) - oracle(backend)

HTML DB is a rapid web application development tool for the Oracle database.  Using only a web browser and limited programming experience, you can develop and deploy applications that are secure, fast and that look exactly the way you want. You can convert ACCESS Application to Oracle HTML DB. Thats your best bet I guess.

This is an old topic and I would like to share with you my notices from old discissions I took part:

Let us speak about Forms on WEB. I just set in "production" the "Personell system" of my company. It is available only on Intranet, you cant use it. but the conclusions are interesting.
The main conclusion is: it works. The overhead exists (too much loading time at the beginning of the sesion). Another disadvantages: record navigation in multirecord blocks is confusing - very often the form looses the control over the navigation with mouse clicks. So I put the standard button "Next record" on the toolbar and recommend to use it. Also there are difficulties with iconic buttons - the images are not available, but I know what to do.

But there are big advantages. First at all the users have the whole Windows functionality in a WEB apllication - mouse clicks, tabs, multiwindows, the advanced Oracle Forms access to the Oracle DB. This is not the limited WEB page application, slow, stupid (from DB view of point of course). Also I would like to say that I succeed to make the application very fast and easy. My colleagues who make WEB apps using HTML and Java need as rule 5-6 men team to do the same. Of course it was not easy to learn how to deal with Forms Server and with Reports Server. So Forms really is a RAD.

As Mr. Alexander said Forms of the WEB are used in the so called "Back Office" implementations - for supporting the infrastructure of big enterprises. They are not approprite for random user access - the overhead is to big.

The next advantage of Forms on the WEB is that you escape the Forms Client instalation on every user station. You avoid to declare a remote directory with .fmx, to share the username/password/host with user. The only thing you do is to publish the URL. This is a big advantage.

About the overhead. In "old" environment (DB listener, Forms Server in the Forms Toolkit) the application really runs slow 9at the beginning of the sesion). But I sow apps based on iOAS9i and the integrated there Forms Server. They were fantastic fast (the overhead was 5 secs in comparison with the 40 secs on my computer).

Maurício Pacheco (mauricio.pacheco@br.flextronics.com)
Joseph is right and I would like to add
two things :
- Although there is some overhead in starting
Forms Server (let's say 20-40 seconds) the
usage is much faster than any HTML
application. Try to create in ASP a dynamic
page to query a table in tabular form with
page navigation (one of many examples).
While Forms needs 2 network packets, HTML
needs 15 (obvious because the data we see
is only a small part of the page, the rest
are tags, formatting information, scripts,
etc). This comparison was made with the
same table, showing the same columns and
with the same records/page. WEB Forms seems
slow but in fact is faster than HTML
because the GUI frame runs on the client.

- In one occasion there was an international
competition to create a WEB application
for product catalog (reports, queries,
maintenances, drawings, etc). While with
Forms we took 1 week (1 developer) the
fastest competitor took 3+ months (3
developers)! And worst, the user
functionality regarding complex queries and
reporting was far better in Forms than
the competitor's tool (I am not going to
give names). Perhaps this was a matter of
training but Forms is really fast to
develop database applications. If
productivity, simplicity, database
performance, data integrity and user
functionality is not important don't use
Forms.

Once more, Forms was not projected for public
sites where multimedia content and
presentation is required. It was projected
for authenticated database applications,
to handle and present data and to reduce
development and maintenance time.

In the end I will be using PHP.  I discovered a RAD tool called Code Charge that easily allows you to create web-based database frontends from a wizard.  Code change will generate the web app in Java, ASP, JSP, Cold Fusion, VB.NET, C#.NET, PHP, or Perl. This product is also very inexpensive.