Gupta vs. Powerbuilder or VB
qiang yu
regarding client/server applications. Peoples talked about
using Visual Basic or PowerBuilder for a better client-end
interface. But I've not heard anyone mentioned Gupta(SQLWindows)
which should occupied a better position in this Client/Server
packages group to my opinion.
The Gupta has an excellent version-control feature, and the
Quest which is a easier tool for both end-user or developer,
along with the Team-Window for large project team of development.
Besides, it provides a good database access functions libs and covers
almost all the Database engins vendered in the market. From my points
of view, if someone tried to use Visual Basic or PowerBuilder to
develop a front-end application with a large amount of database
transaction works, he/she could always expect a better performance and
short term developing by adopting Gupta as the tool. It seems the
Gupta has all the advantages that PowerBuilder offered, Object-Oriented,
source code reuseable, and plus more, such as the outliner.
Now, my question is why this brilliant (Gupta) never attracted
enough attention from either business side or developers. Is there
anyone experienced all the packages (VB, PB, Gupta) or more has
a wise suggestion and give the points? Appreciated!
Ken
Daryl Biberdorf
Daryl
BIRZNIEKS--GUNTHER
PowerBuilder and VB over SQLWindows.
The big advantage of VB Is that it is not a database language, it is primarily
a general purpose language. Best of all, BASIC is not really that proprietary
(Well VB Is somewhat proprietary but if you already know BASIC it builds on it
rapidly).
And also, Microsoft has adopted VB as its generic macro language for all its
applications. So it makes sense to pool developer time into VB when possible
and when it makes sense..Excel, Word, Access all have or are slated to have VB
extensions.
The advantage of PowerBuilder is really similar to VB. The language is really
basically a dialact of BASIC of sorts. And I find it very easy to use..I
started developing within a few hours of playing around and got a good
overview (except reports) from the Getting Start book. .
I have HEARD... (And the only place I can remember that I can actually CITE
right now is BYTE MAGAZINE from a few months ago) that SQLWindows has a MUCH
higher learning curve for its internal language than PowerBuilder does.
By the way, PowerBuilder can use Visual BASIC VBX controls as well. (Maybe
SQLWindows can I Dont know).
I got a Demo of SQL WIndows last year and I was not impressed.. I also saw it
demoed at a show once a while ago and was not impressed with some responses I
got compared to PowerBuilder. HOWEVER, I hear that SQLWindows has upgraded
recently? That should change things.
As for having a built in Version Control system... I am afraid that I agree
with PowerBuilder's route more .. They have an "open" (Sortof) API for Version
Control and CASE tool vendors to link to their product. I think it is better
to have a fully professional version control system from a company that
specializes in making it than a half-assed job for application specific stuff.
Also, it lessens developer time to learn 10 million differenct configuration
utilities if you standardize on ONE instead of constantly relearning the
quirks of individual developer tool configuration managers.
Anyway, I am sure SQLWindows is worth a serious look by any developer... So
this isnt meant to talk down GUPTA>. Just stating a few reasons why we went
with our platform. By the way, Paradox For Windows 4.5 with the SQL Link is
actually quite nice too.. My only complaint is that Queries generate a local
answer table instead of a cursor based system like table views are.....
Later,
Gunther
Eric Keen
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
if times I've accidently deleted or moved an object and was SOL.
2) Inconsistent accelerator keys and access methods throughout the IDE,
it's just plain weird sometimes!
3) It's not easy to open multiple connections, and multiple databases
are impossible.
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!
5) Watcom-32 is hog compared to Gupta single-user (watch your resource
monitors as you fire-up afew instances).
Don't get me wrong here, PB is in a different class than Gupta when
it comes to some of the database design and integration tools; but all
this has a price. Gupta doesn't ask you to store custom database objects
(it's own mini catalog) - PB says put this stuff in the SYSTEM tablespace!
As a technical person - I'd take Gupta over PB, it has a C-like structure
that I'm familiar with and behaves like C. I'm not a Gates/BASIC convert,
especially when it comes to OPP.
---------------------------------------------------------------------
Eric J. Keen Though leaves are many, the root is one;
1707 Park Ave Through all the lying days of my youth
Baltimore, MD 21217 I swayed my leaves and flowers in the sun;
e_k...@digex.net USA Now I may wither into the truth. "W.B. Yeats"
---------------------------------------------------------------------
Qing Yin
>Anyway, I am sure SQLWindows is worth a serious look by any developer... So
>this isnt meant to talk down GUPTA>. Just stating a few reasons why we went
>with our platform. By the way, Paradox For Windows 4.5 with the SQL Link is
>actually quite nice too.. My only complaint is that Queries generate a local
Paradox for Windows 4.5?????? We have Paradox 1.0 for Windows shipped a few
months ago. No flame, I'm just curious about the current state of Paradox.
Version 1.0 was kind of primitive, I'd like to see a new version, but 4.5 in
a couple of months is hard for me to believe.
--
Vincent Q. Yin
um...@ccu.umanitoba.ca
Daryl Biberdorf
>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:
a) 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.
b) Low-level control is harder to obtain with PB than with SQLWindows.
c) 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.
d) 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.
e) 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.
f) 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.
g) SQLWindows table windows are MUCH easier to dynamically modify than
PB's DataWindows.
Daryl
BIRZNIEKS--GUNTHER
high because they are syncing the Windows product version numbers with the DOS
version numbers so customers dont become confused. 4.5 has a LOT of bug fixes
(Not that Borland admitted having bugs), some nice additional features in the
OPAL language and some cosmetic changes (like some forms are easier to
make)... Serial number constraints are gone.... And they have a SQL Link to
Interbase, Oracle and SYBASE now that is integrated with the newer version of
the ODAPI interface.
Later,
Gunther
Chris.c...@sandiegoca.ncr.com
>source code reuseable, and plus more, such as the outliner.
>
>Now, my question is why this brilliant (Gupta) never attracted
>enough attention from either business side or developers. Is there
>anyone experienced all the packages (VB, PB, Gupta) or more has
>a wise suggestion and give the points? Appreciated!
>
>Ken
I would like to add, is there any third party docs on Gupta?
If no, why not? Kind of wierd in my opinion. Has anyone seen the
performance differences between Gupta and other? I've read quite
a few reviews but have never seen any performance benchmarks using
a common Database. The last review I read showed Gupta #1 in
development productivity with all the bells and gongs.
Since opinions are allowed, Gupta hasn't done all that great
a job of marketing and ...Per user license for Oracle applications
can kill you.
1. $$$ for Gupta Runtime.
2. $$$ for Gupta Oracle Gateway.
3. $$$ for Quest.
4. $$$ for Oracle SQL*NET for PC
I hope Gupta doesn't get stupid and decide they only
plan to develop for their DB in the future.
Jeff Kyser
> 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
> if times I've accidently deleted or moved an object and was SOL.
I agree 100%. Also cut, copy, and paste are missing from many areas.
>3) It's not easy to open multiple connections, and multiple databases
> are impossible.
We use multiple connections and databases frequently in PowerBuilder with
no problems.
>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!
We haven't seen any major problems with data access, as long as the queries
are optimized. Setting 'retrieve as needed' on the datawindows helps,
as does using stored procedures on the server. 30 minute delays sound like
a design problem.
>Don't get me wrong here, PB is in a different class than Gupta when
>it comes to some of the database design and integration tools; but all
>this has a price. Gupta doesn't ask you to store custom database objects
>(it's own mini catalog) - PB says put this stuff in the SYSTEM tablespace!
I'm not sure what you mean by SYSTEM tablespace ... PowerBuilder extended
attributes are stored in user tables on the database server, not in the
SQL Server system tables.
>---------------------------------------------------------------------
>Eric J. Keen Though leaves are many, the root is one;
>1707 Park Ave Through all the lying days of my youth
>Baltimore, MD 21217 I swayed my leaves and flowers in the sun;
>e_k...@digex.net USA Now I may wither into the truth. "W.B. Yeats"
>---------------------------------------------------------------------
--
Jeff Kyser PGP 2.3 public key available via finger
jky...@netcom.com "Here we are now, entertain us." - Nirvana
Brian Porter
> In article <2dekik$n...@nova.umd.edu> cm32...@nova.umd.edu (BIRZNIEKS--GUNTHE
> >Anyway, I am sure SQLWindows is worth a serious look by any developer... So
> >this isnt meant to talk down GUPTA>. Just stating a few reasons why we went
> >with our platform. By the way, Paradox For Windows 4.5 with the SQL Link is
> >actually quite nice too.. My only complaint is that Queries generate a local
>
> Paradox for Windows 4.5?????? We have Paradox 1.0 for Windows shipped a few
> months ago. No flame, I'm just curious about the current state of Paradox.
> Version 1.0 was kind of primitive, I'd like to see a new version, but 4.5 in
> a couple of months is hard for me to believe.
> --
>
>
> Vincent Q. Yin
> um...@ccu.umanitoba.ca
I believe Borland release the second version of Paradox for windows as 4.5
to bring it up to the same version level as their DOS version...
___________________________________________________________________________
Brian Porter Spitzer Str. 14
por...@vincere.muc.de 80939 Muenchen
(49) 89/311-7363 GERMANY
Qing Yin
>
>I'm not sure what you mean by SYSTEM tablespace ... PowerBuilder extended
>attributes are stored in user tables on the database server, not in the
>SQL Server system tables.
The real issue is that PB needs the backend database at all for the extended
attribute. When version 3.0 comes out with built in Watcom SQL server, they
are saying that now you can program both at work (with Sybase for example)
and at home (with the built in Watcom.) I guess what they didn't tell you
is that, yes, you can do it as long as you don't use extended attributes.
Jeff Kyser
>The real issue is that PB needs the backend database at all for the extended
>attribute. When version 3.0 comes out with built in Watcom SQL server, they
>are saying that now you can program both at work (with Sybase for example)
>and at home (with the built in Watcom.) I guess what they didn't tell you
>is that, yes, you can do it as long as you don't use extended attributes.
That's not the case. Version 3.0 is out, with Watcom SQL, and extended
attibutes are supported in Watcom as well as SQL Server. The concept behind
extended attributes is that they are stored closest to the data that they
describe. So if you wanted to add attributes to Watcom data, then the
tables would be in Watcom. Extended attributes make no sense unless related
to the data structure in a database.
>Vincent Q. Yin
>um...@ccu.umanitoba.ca
BIRZNIEKS--GUNTHER
>um...@ccu.umanitoba.ca (Qing Yin) writes:
>>The real issue is that PB needs the backend database at all for the extended
>>attribute. When version 3.0 comes out with built in Watcom SQL server, they
>>are saying that now you can program both at work (with Sybase for example)
>>and at home (with the built in Watcom.) I guess what they didn't tell you
>>is that, yes, you can do it as long as you don't use extended attributes.
>That's not the case. Version 3.0 is out, with Watcom SQL, and extended
>attibutes are supported in Watcom as well as SQL Server. The concept behind
>extended attributes is that they are stored closest to the data that they
>describe. So if you wanted to add attributes to Watcom data, then the
>tables would be in Watcom. Extended attributes make no sense unless related
>to the data structure in a database.
>
I think that since PowerBuilder for NOW is primarily/only a Windows based
product, the value of using the database itself as an extended repository
may seem a little weird. But when PowerBuilder front ends come out for other
types of machines that all have different quirks and configurations.. It may
start to make sense to allow developers a common database repository than
a LAN based one. IMHO, however, I think they should have allowed developers
the option of creating a seperate SYBASE database for the repository instead
of putting the tables in the database in question. The reason is that we
use MANY other tools such as Paradox For Windows (Front end querying for
users), and some report writers..NONE of which recognize PB tables as system
tables so it makes these 3rd party products seem user unfriendly when a bunch
of PB tables shows up in a list of real tables!
Later,
Gunther
Qing Yin
>um...@ccu.umanitoba.ca (Qing Yin) writes:
>
>>The real issue is that PB needs the backend database at all for the extended
>>attribute. When version 3.0 comes out with built in Watcom SQL server, they
>>are saying that now you can program both at work (with Sybase for example)
>>and at home (with the built in Watcom.) I guess what they didn't tell you
>>is that, yes, you can do it as long as you don't use extended attributes.
>
>That's not the case. Version 3.0 is out, with Watcom SQL, and extended
>attibutes are supported in Watcom as well as SQL Server. The concept behind
I didn't get myself understood. My point is that the programmer may want to
create the same db structure in two databases (on two machines), one in
Sybase on Sun (for everyday work), the other on a laptop (for work at home
or travel or demo or backup). Since there's a transaction object in between
PB and backend database, PowerBuilder should work the same with either
db (suppose no triggers, stored procs are involved.) But now the extended
attributes are in the db, it's not easy for the programmer to swith to a
different machine when writing the application. In fact, Watcom SQL is so
bad as far as the SQL is concerned. You need to quote table and column names
in the SQL. That's just not acceptable for us Sybase programmers (and maybe
for anyone who use a variation of ANSI SQL.)
Remo Pennacchioli
>From: cm32...@nova.umd.edu (BIRZNIEKS--GUNTHER)
>Subject: Re: Gupta vs. Powerbuilder or VB
>Date: 30 Nov 1993 15:22:19 -0500
One of the main problems, from what I have read, with Paradox for Windows 1.0
was its speed. Compared to FoxPro for Windows, FoxPro would blow the doors of
Paradox.
Does Paradox 4.5 for Windows offer better speed?
-- remo --
Brian Vink
Yin) writes:
>In fact, Watcom SQL is so
>bad as far as the SQL is concerned. You need to quote table and column names
>in the SQL. That's just not acceptable for us Sybase programmers (and maybe
>for anyone who use a variation of ANSI SQL.)
WATCOM SQL does not require quotes around the table and column names when
specifying your query. These quotes are optional. They are only required
if the table or column name is a reserved word. This is as specified by the
ANSI standard.
Brian Vink
WATCOM
bri...@watcom.on.ca
Nigel Campbell
>
>>The real issue is that PB needs the backend database at all for the extended
>>attribute. When version 3.0 comes out with built in Watcom SQL server, they
>>are saying that now you can program both at work (with Sybase for example)
>>and at home (with the built in Watcom.) I guess what they didn't tell you
>>is that, yes, you can do it as long as you don't use extended attributes.
>
>That's not the case. Version 3.0 is out, with Watcom SQL, and extended
>attibutes are supported in Watcom as well as SQL Server. The concept behind
I think he may have meant, how do you test and program at home
using HOLD LOCK, BROWSE MODE and SQL Server datatypes or Transact-SQL
bits outside of normal SQL against WATCOM.
>extended attributes is that they are stored closest to the data that they
>describe. So if you wanted to add attributes to Watcom data, then the
>tables would be in Watcom. Extended attributes make no sense unless related
>to the data structure in a database.
>
I'm curious. If you develop an application in server database A. You
then need to move it into server database B. How do you move the
'extended attributes and validation' to the other server DBMS if
you did not save any scripts?
--
Nigel Campbell Voice: (613) 738-1338 ext 3016 P.O. Box 9707
UNIX/RDBMS Marketing Mgr FAX: (613) 738-0002 3755 Riverside Dr.
Cognos Incorporated MCI: nigel campbell || 3074729 Ottawa, Ontario
UUnet: nig...@cognos.COM CANADA K1G 3Z4
mdchachi
>I'm curious. If you develop an application in server database A. You
>then need to move it into server database B. How do you move the
>'extended attributes and validation' to the other server DBMS if
>you did not save any scripts?
If I've been reading correctly, this was the original point of the
thread... the fact that you'd have to maintain an exact duplicate of the
PB extended attributes in both servers (Watcom & Sybase), provided you
don't use database-specific syntax.
In answer to your question, you'd transfer the PB extended attributes
the same way you'd transfer data from a user table since they're stored
in regular (pb*) tables. If all I had was PB, I'd use the database painter
to save all the rows for each powerbuilder table to text files (one
for each table), then import the same files into the PB tables on the
second server.
Mike
--
C ^ ^ D _ mdch...@vela.oakland. // : elgn / mata nihon e /\ d
^0 0^ __ .edu (call me // : air / ikitai desu yo / /\ \ o
( v ) Mike for // .ri :t. / \ \/ / o
U Woof. short) // ght : / BRAIN MODERNITY \/ p