Re: Visual Basic and Oracle

From: Billy Verreynne <vslabs_at_onwe.co.za>
Date: 1998/02/17
Message-ID: <6cba7f$pl$1_at_hermes.is.co.za>#1/1


Grinalds wrote in message <34E87FE0.1AF1D930_at_konts.lv>...
>> I would recommend not using Forms. <snipped>
>
>Forms modules can be converted to Unix or used in WWW thru the Server
 runtime -
>more platform independant than VB. Generation from Designer, common
 standarts
>and common repository can later help in maintenance and reengineering in
 large
>projects. All this Windows things of animation and e-mail can also be
 embedded.
>There are also "100% Generate or die" crew, who can convince you more than
I.

Doubt that anyone will be able to convince me that Forms is a Good Thing (tm) after having witness Forms development using Designer & Developer for more than a year now.

A couple of comments. Is developing cross platform applications in a corporate environment that important? I doubt that it even features on the list of technical or business requirements. Corporates standardises on a specific desktop environment for their clerical staff - they are the ones going to use the application. Why then develop to support Unix and other front-ends if the standard in that corporation is Windows?

One of the most critical part of an application is the GUI (not saying that the other parts of the app is important). This is what the user is going to work with. You slap a CASE generated GUI on an app and give that to users - well, that's one way to get them pissed off at you (for example, data typsters often work on a data volume captured insentive scheme - a bad GUI influences directly the monery they make at the end of the week/month). The users know their work, and they know what interface will suite them the best. And therefore any developer worth his/her salt, will design the GUI to meet (even exceed) that requirements. And this is simply *NOT* possible with Forms (generated code or not).

OLE sucks. It looks good, but is complex with a lot of performance overheads. Embedding OLE controls in a Forms application, instead of using the native Windows API for that service, is pure stupidity IMO. You want to rely on 3rd party OLE controls for a corporate app where stability and robustness are key requirements - think again. (BTW, embedding OLE in your Forms app defies the whole issue of building portable applications.)

Why do many Forms programmers sing the praises of Forms - simply because they have never seen a true rapid interactive development environment in action. They have no clue about object orientated application design or object orientated programming.

You mention "all these Window things can be embedded" - with Forms, is it possible to send results to an Excel application via DDE, or automatically publish it by calling web server CGI, or automatically FTP it to a server, or store it in a local Access database, or built a multidimensional decision cube of the data in memory, or e-mail it using either MAPI or SMTP? Is it possible to built visual components that can be re-used by other developers for other applications? Is it possible to use native Windows API calls and register callback functions? Is it possible to develop 3 tier applications?

The time for single stand-alone applications are fast becominging a thing of the past. The key issue for applications today is integration. Faster, better and transparent information delivery to the local client and network services. And don't tell me you can do that with a mickey mouse development tool like Forms!!

I fail to see how anyone can even consider to compare Forms with development tools like Visual Basic, Delphi or Power Builder...

regards,
Billy Received on Tue Feb 17 1998 - 00:00:00 CET

Original text of this message