Re: Gupta vs. Powerbuilder or VB

In article <e_keen.754668136_at_access> e_keen_at_access.digex.net (Eric Keen) writes:
>Having worked extensively with Gupta SqlWindows and PowerBuilder in Oracle
>client/server configurations, I would choose Gupta over PowerBuilder
>(from a technical perspective). Powerbuilder had some serious shortcomings
>in the development environment:
>1) lack of an edit/undo on form/object tools. I can't tell you the number

I think it's more of a toss-up than you indicate...I'll address your points below.

> if times I've accidently deleted or moved an object and was SOL.

This is true. To be fair, PB has gone a long way now that they've implemented a Gupta-esque right mouse button menu on the screen objects -- you can jump straight to scripts, etc. without leaving the control.

>2) Inconsistent accelerator keys and access methods throughout the IDE,
> it's just plain weird sometimes!

Examples?

>3) It's not easy to open multiple connections, and multiple databases
> are impossible.

Easy? The statement "CONNECT USING <transaction object>" is hard? All you have to do is set up the fields (and you can duplicate them into other transaction objects using a simple assignment statment such as NEWTRANS = SQLCA) and connect. Not at all harder than Gupta's SqlConnect().

As for multiple databases, I just got back from the Advanced DataWindows class at Powersoft HQ in Boston. The instructor informed us that multiple databases are indeed possible. Just make sure you have the appropriate interfaces and set up your transaction objects for each database in use. Maybe I'll give this a shot later today....

>4) The product applies system modals everytime you hit the databases -
> does anyone know a way around this? I've seen PB apps hang Windows
> for 30 minutes just to validate (or present) a 300 table list!

What exactly do you mean by system modals? Do you mean it simply doesn't yield the processor or what?

>5) Watcom-32 is hog compared to Gupta single-user (watch your resource
> monitors as you fire-up afew instances).

To be fair, don't throw any complicated queries at SQLBase...it'll choke a large portion of the time. I haven't been able to crater Watcom yet.

Other points of note:

1. PB still crashes too often. Expect at least a couple every day. The debugger in particular has had problems since version 1.0, and it STILL crashes from time to time.
2. Low-level control is harder to obtain with PB than with SQLWindows.
3. PB 3.0 is a bit inconsistent in its function naming conventions. The new release has altered many functions to be in the form control.function() when they used to be in the form of function(control,...). However, the changes are not yet universal, so it's a bit tricky.
4. SQLWindows lacks the useful presentation styles available with DataWindows. The freeform style, in particular, is quite useful in that you can use it to mimic a paper form. SQLWindows will force you to code the fields as separate controls on the form.
5. PB has some truly insane quirks in some of its functions (and they've been there since 1.0, probably to avoid breaking code). For example, the Integer function which converts strings to integers either returns the integer value of the conversion or it returns 0 if there's an error. Well, the last I checked, 0 is considered part of the set of integers.... You have to use a stupid IsNumber call to fully check things out. I think the programmer who wrote that call was having an LSD flashback or something when he wrote it.
6. SQLWindows as a whole requires more code to do things. On the flip side, PB buries a lot of attributes in dialog boxes that take some digging to find at times.
7. SQLWindows table windows are MUCH easier to dynamically modify than PB's DataWindows.

Daryl

-- 
darylb_at_sugar.neosoft.com