Visual Basic vs. PowerBuilder
Dave Borowiec
10 on Unix on an HP9000 series 800 server. We plan to do Windows client
development using one of these 2 packages. Any information/results would be
appreciated....Of course, any general comments would be great, too! Thanks in
advance.
Ricardo Olenewa
: Has anyone done a comparison of these 2 tools? We are running Sybase System
If you're looking to do. From the sounds of your setup, it looks
like you need a serious Client/Server environment, in which case
Powerbuilder would be the way to go. On the other hand -- if you're
looking for a quick and dirty way of making a user friendly front-end,
then you could squeak by with VB.
<other opinions welcome>
---------
"Gather ye rosebuds while ye may" - Walt Whitman
==============================================================================
Ricardo Olenewa U of Goo role...@uoguelph.ca
Room 50 The Flamingo Hotel L\A L\A Land
------------------------------------------------------------------------------
ncha...@mutualfunds.com
In article <davebo.18...@mcs.com>, <dav...@mcs.com> writes:
lterdial.uu.net comp.os.386bsd.development:2954 comp.lang.basic.visual:31060
comp.lang.basic.visual.misc:991 comp.databases.sybase:13308
quite happy w/ the results. We coded using both PB and VB for head to head
comparisons and our preference was VB. One major consideration was look and
feel -VB clearly had a much more standard interface. While PB definitely eases
the creation of db linking, VB provided a great deal of flexibility. You know,
it has a lot to do with the talents of your programmer -ours was so good
Microsoft hired him away!\
good luck (oh yeah, we're on a Sun 1000)
neil
David I. Laudicina
> If you're looking to do. From the sounds of your setup, it looks
>like you need a serious Client/Server environment, in which case
>Powerbuilder would be the way to go. On the other hand -- if you're
>looking for a quick and dirty way of making a user friendly front-end,
>then you could squeak by with VB.
><other opinions welcome>
I disagree with your comments about VB. Powerbuilder is a beautiful product
but whne you start adding up the cost to put it on each developers desktop
with serious db access it is pretty expensive. VB gives you most of wht
powerbulider does at a very inexpensive price. We use ODBC and call stored
procedures against million row databases very nicely. As a programmerI like
the data object paradigm. It provides a nice common interface to data and is
very flexible. The real question that neither Powerbulider or VB addresses is
enterprise wide development with data modelling tools and central repositories
for all objects. Uniface and Symantecs have nice products but they are new and
who knows who will win and what do you do when VB and Powerbulider get these
capabilities.
Thx Dave L
Gunther Birznieks
>> If you're looking to do. From the sounds of your setup, it looks
>>like you need a serious Client/Server environment, in which case
>>Powerbuilder would be the way to go. On the other hand -- if you're
>>looking for a quick and dirty way of making a user friendly front-end,
>>then you could squeak by with VB.
>><other opinions welcome>
>I disagree with your comments about VB. Powerbuilder is a beautiful product
>but whne you start adding up the cost to put it on each developers desktop
>with serious db access it is pretty expensive. VB gives you most of wht
>powerbulider does at a very inexpensive price. We use ODBC and call stored
I hate to get into religious discussions (OK maybe I do like to) but
I think there is a definite difference in terms of VB and PB for C/S
development.
I've personally developed C/S applications in both and found PB to be
my preference for a variety of reasons.
Ultimately, Performance was defintately better accessing databases with PB
than VB with stock ODBC (its not odbc's fault, just the implementation of
data controls). Chalk one up on the PRICE bit on having to buy some add
on to VB if you want decent data access.
PowerBuilder has a built in report writer that reuses the same datawindow
paradigm making it more seamless in terms of memory usage and performance
in not having to load a 3rd party DLL to do reporting.
With VB you have to pick and choose a third party report writer. Chalk one
up onthe PRICE bit on having to buy yet another add-on to VB. VB should
be renamed to YAAO (Yet ANother Add-On).
If you develop ONE application in PB vs VB, you might find they compare.
But if you understand OO paradigm and either buy or make a good class
library for PB, development is much easier in PB. Even internally to
an application, inheritance is an incredible thing that VB frankly
lacks. I found that even in my first project with PB, I saved a lot of
time with just inheriting standard data entry screens within the application
I was writing (Not using class library at the time).
PB has more flexible data access in terms of implementing views and stored
procedures as updatable modules than ODBC with VB. (Reference the purchase
of requirement to buy a 3rd party data acess tool if you do serious work
with VB).
Although it is nice and powerful to be able to buy addons, it can tend
to lead down a road to hell and nightmares. Remember that you have to
keep track of not just one vendor, but multiple vendors.. This means
keeping track of updates on each product, making sure the updates integrate
properly with each other,... Not to mention that when you find a big
bug in an add on that you have to spend time back and forth arguing
which bug was caused by which 3rd party add on.
PowerBuilder very nicely operates as a one-stop solution to the whole
Client-Server develoipment cycle. With VB you HAVE To buy 3rd party.
When youHAVE to buy 3rd party instead of being a CHOICE, it ceases to
become a 'good' thing.
As for expense of VB vs PB.
Well,
(A) VB sans add ons is relatively inexpensive (VB Pro).
(B) You need addons and the best c/s ones to make it even remotely
compare to PB are going to cost you a bundle o' $$$.
(C) PB for more than one project and even internally to a project will
save you coding time through inheritence techniques.
(D) Maintenance has been shown to be upwards of 67% of the cost to the
development life cycle of a product. By requiring developers to
use multiple coding products instead of one, you increase overhead in
maintenance and making sure that updates to individual controls do not
interfere with old "builds". When you have an integrated product, it is
easier to do this when you have one global update coming out.
As well, maintenance cost is cut down with PB because if the application
is developed in a hierarchical inherited manner, it is easier to make
changes at the appropriate level. With VB, it is much more difficult to
manage code when you have copies of windows that do the same thing instead
of inheritence where you can change the behavior of a button and have it
propogate to all the windows.
Anyway, the above is an oversimplification of the matter and I am sure I
will receive some or a lot of flak for posting this, but giving a whole
long drawn out explanation would monopolize my time when I already know
I am using the best tool for the job. ;).
PS Dave, I agree that PB and VB lack in enterprise development repositories
and tools. Although with PB it is better because you can have
a global class library stored on a LAN and access those as enterprise
objects. In terms of team source control, you can buy add-ons to PB to
do this which integrate pretty well... since PB is made to integrate with
add-ons like PVCS etc.
This does not solve the complete problem, but of course, it makes PB somewhat
better I Think in this respect.
Later,
Gunther
Michael Joseph Brennan
>
>In article <davebo.18...@mcs.com>, <dav...@mcs.com> writes:
>lterdial.uu.net comp.os.386bsd.development:2954 comp.lang.basic.visual:31060
>comp.lang.basic.visual.misc:991 comp.databases.sybase:13308
>>
>> Has anyone done a comparison of these 2 tools? We are running Sybase System
>> 10 on Unix on an HP9000 series 800 server. We plan to do Windows client
>> development using one of these 2 packages. Any information/results would be
>> appreciated....Of course, any general comments would be great, too! Thanks
>in
>> advance.
>we've been using vb as a front end for the past two years and have been
>quite happy w/ the results. We coded using both PB and VB for head to head
>comparisons and our preference was VB. One major consideration was look and
>feel -VB clearly had a much more standard interface.
I used VB, switched to PB for a while and quickly moved back to VB. Although
I loved the PowerBuilder (Desktop) Environment, I just ran into so many bugs
and problems that it really slowed me down. I have heard they have fixed
many of the bugs I ran into. The next version of VB will have many of
the programming features I want (ie real objects).
Borland Delphi sounds better on paper than both VB and PB, althought I
would like to get a good look at it before recommending it.
mjo...@halcyon.com
Ricardo Olenewa
: But if you understand OO paradigm and either buy or make a good class
: library for PB, development is much easier in PB. Even internally to
: an application, inheritance is an incredible thing that VB frankly
: lacks. I found that even in my first project with PB, I saved a lot of
: time with just inheriting standard data entry screens within the application
: I was writing (Not using class library at the time).
Agreed. However, you can build up a pseudo-library if your code is
flexible enough. But for that matter you could have one developer spend
all their time on this one task. This is one area in which competitive
environments tend to beat out VB (ie. SmallTalk, PB). I wonder when MS is
going to get off of their buts and develop this a little further.
---------
"Man is born free, but everywhere he is in chains" - Jean-Jacques Rosseau
Ronny Ong
>Has anyone done a comparison of these 2 tools? We are running Sybase System
These threads are really a dime a dozen and if you step back and take a real,
hard, long look at the issues, what you'll find is that PowerBuilder kicks
butt if you are in a traditional, corporate MIS (i.e. COBOL background)
environment. Visual Basic rules if you are more of a pedal-to-the-metal coding
shop.
Ultimately, you _can_ do anything with either tool. (A few things require
nitty gritty code in one that don't in the other, but there are
always other things where the situation is reversed. It all depends
on exactly what you want to do.) Ultimately, they cost about the same _if_ you
really want/need to equip VB with all the extras that PowerSoft throws in
their box. (Maybe you do, maybe you don't.) People will try to tell you that
PB requires less coding. That's only true if you _don't_ buy all the add-ons
that raise VB's price to match PB's. PB is buggy, but so is VB. PowerSoft has
merged with Sybase, casting shadows of doubt on them as a supplier. Many
people despise Microsoft, too, though. PB and VB both have incomplete object
models. PowerScript is very similar to Visual Basic in the language department.
We handle complex application development projects that most of the small
"consultant" and contract shops won't touch for under $100 an hour. We find
that PB, VB, ObjectView, SQLWindows ... they all make easy stuff easy, but the
hard stuff is still hard. Things like unbalanced control breaks and multiple
types of detail bands in reporting are largely unaddressed by anything but
code. The tools all have some sort of auto-lookup capability in forms design,
but they never have automatic explosion of component detail. We chose not to
go with PB because if you're doing hard stuff, you'll be writing code for it
anyway, so might as well buy the cheaper tool. We haven't eval'ed PB4 yet, but
if we ever find a tool that does the hard stuff without code, we'll jump in a
heartbeat.
Gunther Birznieks
>I used VB, switched to PB for a while and quickly moved back to VB. Although
>I loved the PowerBuilder (Desktop) Environment, I just ran into so many bugs
>and problems that it really slowed me down. I have heard they have fixed
>many of the bugs I ran into. The next version of VB will have many of
>the programming features I want (ie real objects).
I read an article about the beta of 4.0, and it said that VB 4.0 is "boring"
with no new exciting features.. Including real objects ... I think when
some people are talking objects and VB, they are actually talking about
OCXes which is just one step above VBX.
>Borland Delphi sounds better on paper than both VB and PB, althought I
>would like to get a good look at it before recommending it.
>mjo...@halcyon.com
I too am anxiously awaiting Borland Delphi. Cool name for a product too. :)
Later,
Gunther
Jordan K. Hubbard
Uh, _folks_, can we move this the heck out of comp.os.386bsd.development
now PLEASE? I don't know what sort of collective blindness has befallen
the folks in this thread, but PowerBuilder and Visual Basic do NOT
run under 386BSD or any of the *BSDs for the PC, have never run there
and with all likelyhood _will never_ run there. They're not even UN*X
products.
Thank you. Please note that comp.os.386bsd.development has been
REMOVED from the Followup-To: line. I would be most grateful if other
posters in this thread would show similar consideration. I, in
return, will refrain from posting BSD kernel source code to rec.pets!
:-)
Jordan
--
Jordan K. Hubbard FreeBSD core team Clams are your friends
Ray Porter
>From: ronn...@unicomp.net (Ronny Ong)
>Subject: Re: Visual Basic vs. PowerBuilder
>Date: Tue, 29 Nov 1994 10:23:01 LOCAL
>In article <davebo.18...@mcs.com> dav...@mcs.com (Dave Borowiec) writes:
>>Has anyone done a comparison of these 2 tools? We are running Sybase System
>These threads are really a dime a dozen and if you step back and take a real,
>hard, long look at the issues, what you'll find is that PowerBuilder kicks
>butt if you are in a traditional, corporate MIS (i.e. COBOL background)
>environment. Visual Basic rules if you are more of a pedal-to-the-metal coding
>shop.
I have to disagree with this point. We are an old-style, mainframe/COBOL shop
with around 135 application developers (though we're an academic institution
and not a corporation) serving several thousand users spread across campus and
distributed among about 8 application development groups. We have developed a
number of applications in VB ranging from check writing systems to a gui
interface for our purchasing system that uses screen scraping to interact with
legacy systems to a VB front-end for a 4,000,000+ row Sybase database using
DB_SQLPASSTHROUGH and ODBC to execute stored procedures. Performance has been
excellent (so far), and usually a match for our old CICS/VSAM/IDMS systems.
We actually found the fact that VB requires a little more coding to do
somethings than PB to be an advantage (increased programmer control and
flexibility). We have generally learned to stay away from the data control
and rely almost exclusively on data objects. Where we have met some
resistance is among some of the older programmers who have done nothing but
COBOL for 30 years and have no desire to learn the new technologies. However,
they would be just as resistant to PB as they are to VB.
>Ultimately, you _can_ do anything with either tool. (A few things require
>nitty gritty code in one that don't in the other, but there are
>always other things where the situation is reversed. It all depends
>on exactly what you want to do.) Ultimately, they cost about the same _if_ you
>really want/need to equip VB with all the extras that PowerSoft throws in
>their box. (Maybe you do, maybe you don't.) People will try to tell you that
>PB requires less coding. That's only true if you _don't_ buy all the add-ons
>that raise VB's price to match PB's. PB is buggy, but so is VB. PowerSoft has
>merged with Sybase, casting shadows of doubt on them as a supplier. Many
>people despise Microsoft, too, though. PB and VB both have incomplete object
>models. PowerScript is very similar to Visual Basic in the language department.
We haven't experienced any need to buy a large number of add-ons for VB. The
only additional controls we have purchased are TrueGrid Pro and Crystal
Reports Pro. Data objects and what comes in the box with VB Pro seem to
provide everything we need (at least so far). At least in our case, the cost
of VB has remained considerably below that of PB (especially when you consider
the number of additional db interfaces we'd have to buy from PB). Of course,
your mileage may vary.
>We handle complex application development projects that most of the small
>"consultant" and contract shops won't touch for under $100 an hour. We find
>that PB, VB, ObjectView, SQLWindows ... they all make easy stuff easy, but the
>hard stuff is still hard. Things like unbalanced control breaks and multiple
>types of detail bands in reporting are largely unaddressed by anything but
>code. The tools all have some sort of auto-lookup capability in forms design,
>but they never have automatic explosion of component detail. We chose not to
>go with PB because if you're doing hard stuff, you'll be writing code for it
>anyway, so might as well buy the cheaper tool. We haven't eval'ed PB4 yet, but
>if we ever find a tool that does the hard stuff without code, we'll jump in a
>heartbeat.
These are all valid points. I would particularly like to see a reporting tool
that handles multiple detail bands and unbalanced control breaks. We haven't
looked at PB in a while and we may at some point in the future evaluate it
again. When we did consider it, the price per developer was truely
prohibitive. We could purchase sufficient licenses for VB Pro for our entire
shop for the initial price of PB and a license for one or two developers (out
of 135). The price differential became even more siginificant when the
educational discount was factored in and the fact that we could buy a limited
number of copies of VB and site lock them while PB required a separate license
for each and every developer.
We may have to reevaluate PB at a later date and we may look at some of the
other products (the hints about Delphi certainly sound interesting), but up to
now, VB has admirably met all of our needs. Of course, someone else mentioned
that these discussions tend to take on elements of religious debates, kind of
like the ongoing debate between Mac users and IBM/clone users about which is
the better machine. I think it largely depends on which you're really
familiar with. They'll both do the job; which tool you prefer is mostly a
matter of which you've had the most experience with.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Ray Porter
Applications Analyst Programmer
Administrative Data Processing
University of North Carolina at Chapel Hill
Phone: 919/966-5878 Fax: 919/962-0900
eMail: lrp....@mhs.unc.edu
unc...@uncmvs.oit.unc.edu
Bruce S. Tobin
: Dave Borowiec (dav...@mcs.com) wrote:
: : Has anyone done a comparison of these 2 tools? We are running Sybase System
: : 10 on Unix on an HP9000 series 800 server. We plan to do Windows client
: : development using one of these 2 packages. Any information/results would be
: : appreciated....Of course, any general comments would be great, too!
: : Thanks in advance.
: If you're looking to do. From the sounds of your setup, it looks
: like you need a serious Client/Server environment, in which case
: Powerbuilder would be the way to go. On the other hand -- if you're
: looking for a quick and dirty way of making a user friendly front-end,
: then you could squeak by with VB.
: <other opinions welcome>
I'll take you up on that, since my opinion is directly counter to yours.
Developing C/S apps in VB is more difficult than with PB, because PB builds
a lot of the functionality you need into the base product, while with VB you
must build or buy it. But VB apps run faster and are more stable. In
addition there is no guarantee that you will be able to do everything you
need to do with PB; many developers report 'hitting the wall' and being
forced to write C or C++ to get the job done (PB does enable you to call
external DLLs). VB can do anything that can be done at all in the Windows
environment.
In sum: PB is more productive (if it can handle the job in question). VB is
more flexible, more stable, and a better performer.
By the way, you might want to post your question to
comp.soft-sys.powerbuilder also.
Curtis Young
Olenewa) writes:
I can't see using VB even in a squeak mode. I have been able to put
together an application from scratch much quicker in PB than in VB.
Robin Strong
>Uh, _folks_, can we move this the heck out of comp.os.386bsd.development
>now PLEASE? I don't know what sort of collective blindness has befallen
>the folks in this thread, but PowerBuilder and Visual Basic do NOT
>run under 386BSD or any of the *BSDs for the PC, have never run there
>and with all likelyhood _will never_ run there. They're not even UN*X
>products.
PB is currently being ported to Unix. The first Beta should be available early next year. It is supposed to run on all major Unixes and I think it requires Motif. Don't know if 386BSD is included, but yes, lets keep it in comp.lang.basic.visual, comp.lang.basic.visual.misc, comp.soft-sys.powerbuilder, etc. until there is a Unix version.
>Thank you. Please note that comp.os.386bsd.development has been
>REMOVED from the Followup-To: line. I would be most grateful if other
>posters in this thread would show similar consideration. I, in
>return, will refrain from posting BSD kernel source code to rec.pets!
>:-)
>
> Jordan
>--
>Jordan K. Hubbard FreeBSD core team Clams are your friends
Cheers,
------------------------------------------------------------------------
Robin Strong Salomon Brothers International Limited
BTO - CATS Project --------------------------------------------
Certified PowerBuilder Developer
Phone: +44 (0) 171 721 2255 Email: rob.s...@sbil.co.uk
Chris Lee
>These threads are really a dime a dozen and if you step back and take a real,
>hard, long look at the issues, what you'll find is that PowerBuilder kicks
>butt if you are in a traditional, corporate MIS (i.e. COBOL background)
>environment. Visual Basic rules if you are more of a pedal-to-the-metal coding
>shop.
I have to disagree here. The real power (pardon the pun) of PowerBuilder is that
it has good OO support ... hardly the sphere for someone with a COBOL background.
Just my 2p's worth.
Chris Lee
Howard Ackerman
role...@uoguelph.ca (Ricardo Olenewa) wrote:
> If you're looking to do. From the sounds of your
>setup, it looks like you need a serious Client/Server
>environment, in which case Powerbuilder would be the
>way to go. On the other hand -- if you're looking for a
>quick and dirty way of making a user friendly
>front-end, then you could squeak by with VB.
>
><other opinions welcome>
>
>---------
>"Gather ye rosebuds while ye may" - Walt Whitman
>
>========================================================
"Quick and dirty", oh please. No flame intended but have
you developed with either product?
With either product anyone can do quick and dirty things.
Likewise you can build production apps with either. We used to
use Powerbuilder but dropped it at v3.0a. Without
going into many details, we have used VB for production apps
since the introduction of VB 3.0 and have had lots of success.
Mark Pfeifer
equivalent to PB's DataWindow.
This control can save some signifcant coding time.
Barnacle Wes
: The simply answer is if you want to do database applications,
: PowerBuilder is going to be a better choice. Visual Basic does
: not offer any control which is equivalent to PB's DataWindow.
Could we *please* get this discussion out of comp.os.386bsd.development?
At least until Visual Basic or PowerBuilder run on 386bsd? <Shudder!>
Thank you!
David I. Laudicina
Granted it doesn't offer anything like a data window but I have found the data
object to be a really beautiful paradigm if you are a programmer. It fits in
really nicely to VB and allows you to think more object like with one
standard for all data connections when dealing with data connectivity.
Thx Dave L
Ken Priest
> flexible enough. But for that matter you could have one developer spend
> all their time on this one task. This is one area in which competitive
> environments tend to beat out VB (ie. SmallTalk, PB). I wonder when MS is
> going to get off of their buts and develop this a little further.
>
Microsoft are off their butts. They are developing VB 4.0. New features
that I have heard of include :-
1. More object oriented so inheritance is supported.
2. Can run multiple development environments at once so OLE client and
server can be debugged together.
3. Written in C so portable across all NT architectures including
Intel, Alpha, Mips and Power PC.
The written in C part has led to poor performance so it is not likely
to stabilise until mid 1995.
As for the VB versus PB argument. I use VB cos its cheap any easy
to learn. I use PB cos I am told to at work. If I had a choice I would find
something else. VB is only good using DBLib with Microsoft of Sybase
SQL Server and generic library of code for inheritance. PB is only good
when all the intelligence is built into the front end (poor C/S
design) and you can force people to use the same class hierarchy.
Sounds to me like we need real C/S tools like Forte or perhaps Delphi
from Borland.
Ken Priest | "We believe Developers are REAL people too."
Quicklink Computers Ltd | NeXT Salesman
k...@qlink.demon.co.uk |
Horsham, England |
Raymond M. Glassmeyer
I have never worked with Powerbuilder, but I have ben building
client server apps with VB since 1.0. From what I understand about
Powerbuilder, I believe this to be an accurate statement:
Visual Basic is a Windows programming language with data access
features build in. Powerbuilder is a database front end builder for
Windows.
I do have a question about Powerbuilder. My VB applications are run
on 95 Novell file servers by about 3000 users a month about 17000
times.
How would Powerbuilder work out in this environment? I have heard
that if more than 10 users try to run a Powerbuilder application it
starts to slow down.
Is that a correct "rumor"?
Raymond Glassmeyer
ra...@mcs.com
Gordon Bell
>From: bir...@aplcenmp.apl.jhu.edu (Gunther Birznieks)
>Subject: Re: Visual Basic vs. PowerBuilder
>>><other opinions welcome>
<Copious cutting>
Although I'm a big fan of PB and never used VB, I feel obligated to point out
one flaw in your argument - to some extent, the add-on scenario works against
PowerBuilder too. As you've mentioned, you need to add-on source control to
PowerBuilder. And if you want to do something a little less database-related,
you'll also need to add-on.
For example, there are a plethora of extra controls, either VBXs or DLLs being
marketed to the PowerBuilder community to cover controls not provided natively
within PB (e.g., hierarchical folders, tabbed dialogs, etc.). There are DLLs
for doing imaging, integrating geographical information, using enterprise-type
middleware (DCE, Encina, RPCs, etc.), and text processing among others.
I would agree with you for basically informational type systems, but the more
interesting applications may utilize these other technologies & require
integrated add-ons as well. Not to mention the "add-ons" integrated through
DDE and OLE!
>PS Dave, I agree that PB and VB lack in enterprise development repositories
>and tools. Although with PB it is better because you can have
>a global class library stored on a LAN and access those as enterprise
>objects. In terms of team source control, you can buy add-ons to PB to
>do this which integrate pretty well... since PB is made to integrate with
>add-ons like PVCS etc.
>This does not solve the complete problem, but of course, it makes PB somewhat
>better I Think in this respect.
>Later,
> Gunther
I also heard someone mention in this thread that Uniface was a new product. I
did a comparison of PowerBuilder and Uniface three years ago! It kinda sounds
like Uniface is an up and coming overnight success that has been at it for
years.
We didn't select Uniface as the Windows product wasn't really ready for us and
the language was missing some important constructs (like loops - using GOTOs
just didn't cut it for me). I believe these limitations have been addressed
in the intervening years.
Regards,
Gordon
Gunther Birznieks
argument.
The difference between the add-on market for PB versus the add-on market
for VB, is that to do any decent C/S programming on VB, you MUST get
at LEAST 2 3rd party products. This is not true with PB.
Yes, in SOME projects you will ALWAYS need a 3rd party product such as
an IMAGE processing library or the like, but those are specific to the
project and do not hurt the maintenance cycle of ALL your applications.
Just a FEW of them.
There is also a difference between add-ons that extend the capabilty
of the product in terms of the end-product program Versus the programming
environment.
PVCS and other CODE add-ons to PB are not really detrimental to maintenace
of PB applications because if Metasolv went out of business today and
you discovered a horrendous bug in PVCS, you could drop PVCS without
actually having to drop the software that it was developed with. PVCS
is a development tool NOT a control or library that is integrated into
the actual client-server program that is being develivered to users.
Later,
Gunther
Gordon Bell
>From: "Raymond M. Glassmeyer" <ra...@mcs.com>
>Subject: Re: Visual Basic vs. PowerBuilder
I don't believe so. It is a client application running locally on the users'
PCs. All other performance should be dependent on the speed of the database
server engine.
I suppose if you distribute applications from a shared drive, you could get
this problem. I personally believe in running these programs locally if
possible - better performance in my mind.
Gordon Bell
gb...@shl.com
>Raymond Glassmeyer
>ra...@mcs.com
Jon Barron
Birznieks) writes:
Gunther,
You've been slamming VB now for several posts, but IMHO your arguments
are slanted, and somewhat weak.
>The difference between the add-on market for PB versus the add-on market
>for VB, is that to do any decent C/S programming on VB, you MUST get
>at LEAST 2 3rd party products.
This is not true. I have the Pro edition of VB, and I have yet to shell out
for any third party tools. There are some out there that would make life
a bit easier, but they aren't required. Crystal Reports could be nicer,
but it gets the job done. At any rate, if I buy VB Pro edition with any
four third party tools, I'll still spend half of one PB developer seat.
>PVCS and other CODE add-ons to PB are not really detrimental to maintenace
>of PB applications because if Metasolv went out of business today and
>you discovered a horrendous bug in PVCS, you could drop PVCS without
>actually having to drop the software that it was developed with. PVCS
>is a development tool NOT a control or library that is integrated into
>the actual client-server program that is being develivered to users.
>
This is the same with ANY development environment. This goes well beyond
VB or PB.
At any rate, it's very clear in this thread who the VB advocates are and
who the PB advocates are. It's almost religous. For the most part I think
this is because, other than the normal programmers prejudice to use the
system they have grown comfortable with, the two products are so closely
matched in abilities and features that no clear winner can be proclaimed.
Regards,
Jon
coll...@foundr.enet.dec.com
>These are all valid points. I would particularly like to see a reporting tool
>that handles multiple detail bands and unbalanced control breaks. We haven't
>looked at PB in a while and we may at some point in the future evaluate it
Can you explain the terms : multiple detail bands and unbalanced control breaks
Thanks
Luke
Jon Barron
>
>The simply answer is if you want to do database applications, PowerBuilder is
going to be a better choice. Visual Basic does not offer any control which is
>equivalent to PB's DataWindow.
>
So? PowerBuilder does not offer .VBXs. This alone can make or break a project.
Regards,
Jon
David Zammit
Danny Ames
>: So? PowerBuilder does not offer .VBXs. This alone can make or break a project.
>
>Yes it does.
Sure if you have VBX's from VB 1.0, I have worked with powerbuilder for
about a 1 1/2 years and have yet to find a VBX that would help.
An interesting side note is a simple PB window with 1 button and a list
box (NO DATABASE CONNECTION) results in a 14k EXE and 2.1 meg of DLL's
Plus PB windows are not ever true windows, making it harder to deal with
in the API. VB is quicker, albeit more code, than PB in database hits
and queries.
In addition PB is simply for database applications, with its data windows
it is much easier to manipulate the database, but that is what it is
designed for. VB on the other hand is open as to what the application
can do, games, database, graphics, so on etc.... Have you ever seen a
shrinkwrap PB app??? There are several VB ones. PB is primarily for
internal Client/Server apps, You can't compare apples to oranges.
It is kinda like the PB vs. Delphi thing, only the big mistake there is
that VB is BASIC and Delphi is PASCAL. They are not in the same arena.
Brian Wilson
> So? PowerBuilder does not offer .VBXs. This alone can make or break a project.
While you cannot *create* VBX's with PowerBuilder, you can *use* them as
user-defined objects.
Myself, I have yet to see a situation where being able to use VBX's made
or broke a project.
--
Arrogantly twisting the sterile canvas snoot of a | a-Henh!
fully charged icing annointment utensil, he poots forth |
a tiny green rosette near the summit of a dense but | Brian
radiant muffin of his own design. | Wilson
|
We miss you, Frank! |
Joe Cool
There is one important issues that Powersoft likes to keep quite about...
Powerbuilder only supports version 1.0 of MS's VBX standard (if you want to call it a standard.)
Many of the version 3 VBX's will not function correctly with Powerbuilder,
Regards.
Horne Broward
: Myself, I have yet to see a situation where being able to use VBX's made
: or broke a project.
Well, let me take a risk here. We're currently evaluating
several different languages for development of PEN computer
programs. One of our biggest concerns is that anything we
choose be able to use the pen controls from VB. Now, I imagine
I could probably design something that would mimic these controls,
but I'm not *sure*. :)
We're looking at VB and PowerBuilder, but we're also highly
interested in DBase for Windows, and CA-Visual Objects.
Why would I NOT choose Dbase for Windows? After looking it over
for the past two days, I find that it "matches" our application,
which is roughly 70% 2-d arrays that must be read/written from
databases.
Danny Ames
> for the past two days, I find that it "matches" our application,
> which is roughly 70% 2-d arrays that must be read/written from
> databases.
One reason would be that the .dbf dbase files happen to be one of the
the slowest database file types available. If you have a large amount
of data in the flatfiles it would be better not to use dbase format.
And if you are developing Client/Server apps, you might want to use
somthing like SQL Server and do a front/back end with VB or PB. Although
PB will slow things down almost as much as the .dbf will.
Mark J. Howell
>From: da...@pic.net (Danny Ames)
>Subject: Re: Visual Basic vs. PowerBuilder
I thought the poster _was_ talking about using dBase as front end to SQL
Server. There are alternatives to PB and VB of course. I use Paradox for
Windows and SQL Server.
Mark J. Howell
mho...@rtd.com
(pretty boring signature)
Brian Wilson
> There is one important issues that Powersoft likes to keep quite about...
> Powerbuilder only supports version 1.0 of MS's VBX standard (if you want to call it a standard.)
> Many of the version 3 VBX's will not function correctly with Powerbuilder,
We generally don't use VBX's in our PowerBuilder projects and yet we keep
buying more copies of PowerBuilder. I don't think that the lack of VBX's
is going to make or break PowerSoft or Sybase. It would appear that VB
programmers will find this to be a "needed" feature, while those of us
who don't work with VB might not see it as an ommission if it is not
included.
Brian Wilson
> : Myself, I have yet to see a situation where being able to use VBX's made
> : or broke a project.
> Well, let me take a risk here. We're currently evaluating
> several different languages for development of PEN computer
> programs. One of our biggest concerns is that anything we
> choose be able to use the pen controls from VB. Now, I imagine
> I could probably design something that would mimic these controls,
> but I'm not *sure*. :)
Well, if your project depends on VBX's, then I suppose VBX support would
make or break the project. Generally speaking, however, critical success
factors for software projects do not include the toolset. Usually the
need is established, then the platform, then the tools.
Brian Wilson
On Thu, 29 Dec 1994, Sean Kelly wrote:
> > We miss you, Frank! |
>
> Would that happen to be TV's Frank?
Guess again. It's Frank Zappa. He died a little over a year ago.
Later... (and perhaps even on-topic)
Brian
tab...@vms.huji.ac.il
>
> I thought the poster _was_ talking about using dBase as front end to SQL
> Server. There are alternatives to PB and VB of course. I use Paradox for
> Windows and SQL Server.
> Mark J. Howell
> mho...@rtd.com
> (pretty boring signature)
I just read of Oracle 7 for Windows and Oracle Objects for Visual Basic
in VBPJ. Has anybody looked at the pair of products yet? Can Oracle
7 for Windows translate an Access MDB in the same way Microsoft's
Upsizing Tools can for SQL server?
-dennis turner