Re: DBForms convert Access db and forms from Access to PHP + Mysql

"Bob Alston" <bobalston9@xxxxxxxxx> wrote in message
news:_gbXl.7040$i01.2629@xxxxxxxxxxxxxxx
Anyone using the product called DBForms to convert an access db and forms
into a web based solution? It converts to PHP and Mysql.

Here is their web site:

http://dbconvert.com/convert-accessforms-to-web-mysql.php

Bob

It looks interesting, but I think it only good for some layout help
here...not an application that does real work.

I suppose I'd be more interested in what the actual limitations are. For
example it mentions it can convert combo boxes, but doest it support multi
column combo boxes? (ie: more then 2 columns - I doubt it).

Furthermore it mentions that NONE OF your code the or program logic is
converted at all.

In other words it can convert some part of the forms for you, but then what?

I think most the work and value in an application is "connecting" of the
controls to program events so that when the user interacts with the screen
(application) then useful work is actually done. No events means that you
have nothing for when a button is clicked, or even simple things like after
update events in a combo box don't exist anymore.

After conversion you'll have to use PHP tools, AJAX and work with MySql. In
other words you'll have to learn about 3-5 new "major" technologies to get
any kind of real work done. That means you better be very familiar with
mySQL, PHP, and even ajax. Once you've converted the form, then you have to
use some web based development tools + system here. What will one use for
form design for example? These tools have steep learning curves and have no
where near the ease and ability of what access has.

There is very little said about what you going to use for reports in this
case. Again the rich reporting features of MS access is very much one of the
reasons we are using this product in the first place.

So even just basic things like opening a form as a result of a clicking on a
button is NOT going to be converted for you. So, you now be coding in web
based languages.

I suppose that this type of conversion program could be used as a starting
point. You are certainly not going to get a web application out of an access
application by using this approach. You can certainly convert some of the
forms and save some of the initial layout work.

I think all of the big questions arise after you've converted the form. What
form design and development tools are you going to use for coding when
buttons are clicked on?

What are you going to use for a report writer? Someone might come along and
say hey here's some great report writer that works with mySql. However the
simple idea of having a button on a form, pressing that button, and passing
some "where" restriction parameters to the report is something that access
does in it's sleep and does with 1, perhaps two lines of code.

With some 3rd party report writer, you lose that integration and ease of
building a report, let alone a simple menu on the menu bar to launch that
report with passed filter/values.

At the end of the day it's how all the little bits and pieces work from
reports to forms to macros that makes access such a great development
platform.

I think if your experienced in PHP, mySQL, ajax etc and also use some "web"
forms building system and a new reports building system and you *ALSO* have
a lot of experience using those web tools then I suppose converting up some
forms would be a starting point.

However, those forms after conversion tend to look VERY crappie, don't have
correct control anchoring (thus don't re-size correctly when viewed in a
browser etc.) I think at the end of the day if you're converting something
to web based, you'd be best off to take a look at the form, and use it as a
starting point. You then would probably redesign the form from scratch since
you'll get a better browser experience here anway.

The other issue is we tend not to distinguish between what a web application
and that of an access application.

access applications:

In multi user mode in an typical office every user might be on the phone
taking orders from a customer. There's really no distinction made in terms
of security and any user in the office can in fact view any piece of data in
system. Not only can any staff use "all" of the information in the
database, it's pretty typical and how an application has to function. If a
person orders something and then phones later on they might get a different
office staff member who can freely and easily bring up that information
about that customer.


web based applications:

Web based applications are all about self service. In other words a web
based user can NOT be allowed to simply bring up any order in the system. In
other words, other reocrds and informaton is to be private to other
customers. What this means is you need all kinds of logon systems,
authentatcion systems. You will even have to write a system to allow users
to "recover" their passwords. Since the whole layout and design of the
application now for "one" customer, the overall philosophy and design of the
application will have to be modified to now deal with one person and one
customer. This is NOT how an typical access application is desinged.

That one customer does not need a search and find for every customer . The
whole focus of the application changes from an operator on a phone to easily
and quickly bring up ANY customer, to that of a whole application that built
around serving ONE customer with ease.


Often it not web enabled we need, but remote use:

So often we hear people here saying that they want their application to be
web based. What they really want is the application to be usable by their
internal staff anywhere when they're on the Internet even outside of the
office.

In other words for the case of a few salespeople your office needing to use
this application outside of the office, then you're far better off use one
of the many remote desktop technologies in which those users can run and use
that application anywhere they have an Internet connection.

I suppose an application could be web enabled to allow staff to use the
application, but that's a huge cost to simply take an existing application
that can be so easily used over the Internet with so many these new remote
desktop type technologies we have today.

So, customer self service and web based applications are significantly
different designs in terms of philosophy of how a typical access application
was built.

In most cases what people are actually looking for is remote use of the
access application, not a web based application.

When people really need an web based application, they are talking about
something that functions and works significantly different then the typical
access based application that they have. The web based system usually does
not need all kinds of reporting features, but will be some type of customer
self service system. That means lots of security and a system designed
around making things very easy for each customer. Those customers can really
be trained to run the whole application and understand all the business
rules and aspects of running your business or that application.

In all software the real key to understanding how application should
function is to look at the viewpoint of everything from an imaginary typical
user. It's the typical user of the softwaer and what information they need
that will decide if you need to move the whole application to the web, or as
I mentioned typically just parts that allow the customer to feed themselves.

--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pleaseNOOSpamKallal@xxxxxxx


.