Re: Opinion of Forms

My associate and I have many names for Forms and Reports.

One of our sayings is: "success in spite of Oracle". Another one is that we now understand why Oracle consultants make a lot and are in demand: It takes a long time to learn how to work around the quirks to be productive, and once you are productive and have your own little "bag of tricks" you are worth more..

Another one is that it seems that Oracle took something that really isn't object oriented at its core and made it look object oriented, but lacking many of the powerful features of objects that are already in other languages.

Many things about Forms are not natural compared to other languages like XBase, Visual Foxpro, VB, C, Pascal, Delphi... I have a separate list of bugs that are very irritating, many are like beginning programmer bugs. It appears like the Forms team and the Reports team went off in separate directions.

You asked for examples. Here are a few. 1. Most languages give you access to many properties. Here, oracle has covered over many properties in their objects and allowed access to only some properties. Examples: a. Alerts only allow access to title and message; colors, numbers of buttons, which ones are enabled, etc. are all not available. Foxpro and visual basic have MessageBox, very powerful, flexible functionality. b. Reports apparently does not allow access to the FileName property for "queries from an external file". Therefore, the developer is forced to hard code filenames and cannot provide flexibility or use unique, dynamic filenames...or is forced to make separate but similar reports, which goes against the whole reusability thing... c. Can't find the client area of a window dynamically, only the true size of the window.

2. Stupid bugs. a. When you change Coordinate systems, the mouse cursor changes to busy, then never changes back. b. When you use alert boxes, the cursor changes to busy for the end user while alert loads, but never back to arrow, so user thinks he is still waiting when really the alert is ready for user to press the the button. c. Try to create a hard coded list of parameters. The object for adding parameters does not have any delete capability. If you make a mistake, you will have to delete the entire object, then recreate it and recreate the list just to avoid having an empty or blank line in the popup. d. Our DBA tried to generate scripts from Designer 2000. The scripts were incorrect. She had used the "generate" function from the menu. She was told this was a known bug. To get the proper result, she had to highlight the desired tables, right click for a small menu, and pick "generate" off of that menu. Thus the same command from two different places did not work right...[to me, that is just plain bad coding] .... many others...

3. Quirks and Outright Crashes
a. Tool gets confused and won't compile perfectly good code: says "internal error". Close and reopen the file and it compiles OK. b. Search for PL/SQL code at the wrong moment and the entire Forms tool crashes instantly. To guarantee safety, you must close and reopen the file before any searches. c....others....

4. Arrays. Other languages have simple easy to use array declarations. Not so in forms or PL/SQL. The only thing coming close is a PL/SQL Table, which is cludgy to code and use. We "invented" a methodology using globals that works like arrays, simply and easily, but it has its limitations.

5. Globals. All globals are strings, maximum 255. WHY? There are legitimate needs for global variables, like persistence, passing parameters to multiple forms in an easy way, etc. Other languages have powerful globals.

6. Printing. There is no easy way to print your code from the tool. File/Print ONLY does a screen dump. It seems that you cannot, for example, easily print the contents of 3 or 4 program units in a module without much cutting and pasting into an outside editor.

7. Mismatch between Oracle PL/SQL backend and frontend: example: PL/SQL uses DATE. This translates into DATE in the front end. However, the correct usage is really DATETIME in the front end. This caused us much trouble, and cost a few hours troubleshooting and figuring out this "Quirk"....Of course, now it is easy, now that we made a rule "Be Careful for Date and Datetime conversions".

8. Reports programmer is unable to control the size of the runtime viewer window dynamically (even says so in their online help), and yet the result is less than desirable: the report is chopped off, and the user is forced to have extra mouse clicks to maximize or stretch every single time.

9. In their attempt to 'HELP' the user by 'doing a lot behind the scenes' they end up limiting the developre. Example: App checks data blocks and automatically determines when to update or insert and commit. Very powerful. But if you have a situation where you manually update and commit, the commit will be intercepted and there will be an error: Nothing to commit. You are forced to be ingenious or to force a block to become "dirty" JUST so the app will see it and do the right thing you already told it to do (commit) in the first place....So you have to go OUT of your way to do things that are very natural, even in their own back end PL/SQL...they 'helped' too much.

...many more .... need I go on?

You may want to ignore me as just an "Oracle Basher". But no, really, I am saddened, because I was quite happy with Oracle back end and PL/SQL. Lots of things "just made logical sense." I just naturally thought that their GUI tools would be "just as good".

Nevertheless, I will use these tools, and in spite of their limitations I will find ways to be successful with them...But the facts remain, they really are quite lacking when stacked up against the wealth of other languages. And in many ways, I think, that users have no idea what they are being sold until they really get the toolset and begin trying to use it. Then it's too late, it's already paid for.

Your comments welcome,
Robert Proffitt
Brea California

--== Sent via Deja.com http://www.deja.com/ ==-- ---Share what you know. Learn what you don't.--- Received on Fri May 14 1999 - 20:22:56 CEST