Question Re: Visual Studio Vs Powerbuilder in Technology Q&A

Visual Studio Vs Powerbuilder

Former Member — Thu, 06 Jun 2013 13:21:48 GMT

ok guys,

I have to prepare for a session to a meeting where I have to convince developers to switch from Visual Studio to Powerbuider.

Can you give me 10 good reasons for the mission?

GMY

Re: Visual Studio Vs Powerbuilder

Former Member — Thu, 06 Jun 2013 16:09:58 GMT

Hi Gimmy;

If you send me an email on this - I can respond with my $0.02 worth on the subject.

Regards ... Chris

Re: Visual Studio Vs Powerbuilder

Former Member — Thu, 06 Jun 2013 16:39:18 GMT

Here's 4 for a start:

1. The DataWindow allows for automatic handling of optimistic concurrency. That is, you can tell it to check for update conflicts with just updated columns, or for all columns in the result set without having to add any special logic.

2. The DataWindow renders at runtime as two controls, a bitmap and an edit mask, regardless of how many rows/columns are retrieved, reducing the demand on graphic resources.

3. The DataWindow, if handled correctly, can be backend database agnostic. You can easily have one set of code that supports a number of different databases.

4. The Rapid Application Development features of the DataWindow and the PowerBuilder IDE mean that developers can be much more productive using the tool than other more 3GLish IDEs.

Re: Visual Studio Vs Powerbuilder

Former Member — Thu, 06 Jun 2013 17:35:01 GMT

While I'm not all that familiar wity Visual Studio, I do think I have one large item to add to the list:

5. Performance; PowerBuilder executes significantly faster than identical applications written in Visual Studio.

Re: Visual Studio Vs Powerbuilder

Former Member — Thu, 06 Jun 2013 18:44:22 GMT

6. Datawindows for adding data & reporting is significantly better than VS because the data entry form can be used to print the data, with no other objects/reports needed.

7. Inline SQL for times when you don't need a datawindow just to grab a value from the database (or doing updates that don't need individual value changes (ex: reset a flag in a table with a where clause)).

Re: Visual Studio Vs Powerbuilder

Former Member — Thu, 06 Jun 2013 22:04:56 GMT

I have not tour email, but you can find my email on my profile Ty Chris Gmy

Re: Visual Studio Vs Powerbuilder

Former Member — Fri, 07 Jun 2013 01:34:00 GMT

8. The DataWindow performs better on retrievals because it retrieves rows in blocks rather than one at a time (assuming you don't have code in the RetrieveRow event).

9. PowerScript is a very clear, no-surprises language. Readable code means fewer bugs and easier maintenance. And the learning curve is very rapid.

10. PB is object-oriented. Pick one of the available frameworks, spend a little time customizing it, and each time you add a feature you will find 50% of the work is done by inheriting the appropriate object. And it's the boring part of the work, the wiring and plumbing, leaving you to concentrate on the business logic.

Re: Visual Studio Vs Powerbuilder

Former Member — Fri, 07 Jun 2013 01:42:47 GMT

3a. And when you use the DW painter, you don't waste time looking up the exact column name spellings or details of SQL syntax. For instance, when you do a join, it lists the options in plain English so you don't have to worry about which side of the = gets the *. And did I mention it's mostly point and click?

Re: Visual Studio Vs Powerbuilder

Former Member — Fri, 07 Jun 2013 09:34:25 GMT

You have something to add between Java and Powerbuilder?

1K Thanks for your opinion.

I will treasure it.

Gimmy

Re: Visual Studio Vs Powerbuilder

Former Member — Fri, 07 Jun 2013 15:50:51 GMT

So, let me start off by saying that you're in an unenviable position: trying to convince Visual Studio lovers not to use Visual Studio. "You know what you love, and you love what you know." I'd suspect that this is akin to convincing them that the table you're around doesn't exist, the chairs they're sitting in don't exist, and they're actually naked in a vat of goo (xref The Matrix).

You haven't given us much to go on in terms of what the project is. It's hard to argue what the best tool for the job is without knowing the job. For some examples, if you project involves any of the following as a primary component, I'd argue in favour of Visual Studio:

Console application
Sharepoint integration
Office plug-in
WebForms (OUCH!! Too soon?)

That being said, here's some generic arguments:

DataWindow (all features below come built in, with little or no coding required)
- single object can be used visually or nonvisually
- dynamic sizing / positioning of controls based on data
- dynamic modifications of almost all UI attributes either based on data (expressions in attributes) or based on run time conditions (Modify(), although expressions can do this too)
  - e.g. alternating background shading between rows takes a one-line expression; I've seen an article that suggested it took 2-3 pages of code in .NET
  - e.g. each row can have a distinct UI based on the data (e.g. walk-in customers can show a different UI than shipping customers, all integrated into a single list)
- WYSIWYG printable, or run-time-modifiable for printing (e.g. add a page number footer)
- SQL injection prevention / input sanitization
- Null argument handling (e.g. "CustId = :custarg" gets translated when arg is null to "CustId IS NULL")
- Minimal SQL creation on updating databases (e.g. doesn't update columns that haven't changed; often not the case when programmers build their own SQL)
- strong field formatting and validation
- controlled retrieval of large quantities of data
- disk-cached retrieval of large quantities of data
- handling of identity values
- conversion of database errors to events
- ability to monitor, intercept, modify or cancel generated SQL at any time
- ability to export data to many formats
PowerScript
- probably the easiest sell to this audience is quoting the Appeon Pet Store Lines of Code study

And so you can start thinking about responding, with my clients recently, the most compelling argument against PB (at least that I have a hard time arguing against) is the lack of available, active talent. If they can't* hire people now to code the system, or in the future to maintain it, they're painting themselves into a corner. (* "Can't" doesn't have to mean impossible; it can just imply high cost or effort.) This isn't to say that SAP couldn't possibly turn this situation around by changing PB's position in the market (imagine if every SAP installation needed a team of PB developers for customization?), or that .NET's position is secure (many think Win8 / WinRT was a body blow to .NET). However, hunting for bodies today, this is the situation managers face.

Good luck,

Terry.

Re: Visual Studio Vs Powerbuilder

Former Member — Fri, 07 Jun 2013 15:59:30 GMT

A lot of the same points. Java is even more 3GLish than Visual Studio.

The reason I love PowerBuilder is because I want to spend most of my time actually writing the application, not writing application infrastructure to support writing the application. Pair PowerBuilder with a decent framework like PFC and you can pretty much immediate get down to generating something the end user can use, and produce it rather quickly.

In the inverse of what Terry says below, people who have learned PowerBuilder and know how productive it can be can have a real hard time with anything else, particularly because of how much more time it seems to take to get anything done with them.

Re: Visual Studio Vs Powerbuilder

Former Member — Fri, 07 Jun 2013 17:11:36 GMT

Hi Jerry;

FYI ... #8 is not true ... while the DB driver get an entire packet, the DWO runs an internal FETCH loop 1 row at a time to get all the rows for the primary buffer. Things can also go better or worse on top of that depending on whether the developer used an ODBC connection, OLE-DB, ADO.Net, JDBC, native, etc driver connection mechanism.

Regards ... Chris

Re: Visual Studio Vs Powerbuilder

Former Member — Fri, 07 Jun 2013 17:21:48 GMT

Really? Then what would be the point of the Block DBMS parameter?

http://infocenter.sybase.com/help/index.jsp?topic=/com.sybase.infocenter.dc33820.1200/html/dbparm/CCJBFHJG.htm

Block (ODBC, OLE DB, Oracle, and SNC)

Description

For those interfaces that support it, Block specifies the cursor blocking factor when connecting to a database. The blocking factor determines the number of rows that a DataWindow object can fetch from the database at one time.

Using the Block parameter can improve performance when accessing a database in PowerBuilder.

Re: Visual Studio Vs Powerbuilder

Former Member — Fri, 07 Jun 2013 17:30:20 GMT

Hi Terry;

I must say ... "Very well put"!

Personally, I have tried this scenario over 5 times in the past many years and seen many others attempt this feat. The outcome for me is PB - 0 and VS - 5 and the same for the few others I have seen attempt this change in IDE argument. Add to your VS list: integrated testing, integrated SCM, integrated SSIS reporting, proper support for SS2012, etc and you pretty much wipe PB out of the game from the VS developer's perspective. Now add proper support for ASP, Windows 8, Windows Mobile .. etc and you would be better off defending yourself against a pack of wild dogs IMHO.At least the chances of survival might be better. 🙂

So let me also say ... "you are in an unenviable position: trying to convince Visual Studio lovers not to use Visual Studio"!

Now, can SAP turn things around ... Hmmm - no road-map, no PB 15 (maybe 2014 now), no change in management, maybe no PDC this year, no PB Classic "how to videos", retiring / no longer using PB resources, no support for education from major ED centers like Learning Tree, etc and I doubt whether SAP is in a position to effect any PB change in 2013 .. just my impression FWIW..

Sorry to be so negative! While I am personally super productive in PB - especially adding Appeon Web & Mobile to the mix - this is "hard sell" for VS developers who have grown up into IT through college & university using VS.

Regards ... Chris

PS: Good Luck anyway!

Re: Visual Studio Vs Powerbuilder

Former Member — Fri, 07 Jun 2013 17:42:41 GMT

"internal" = memory to memory = very very fast, mircoseconds. Blocking reduces the number of times the client must handshake with the server over the network. As I recall it's two or three messages each before and after each data block - regardless of the actual number of rows in that block. Time for each would be in milliseconds. As always, it depends on the speed of the network , traffic level, and load on the server, but with a substantial result set the difference is often discernible to carbon-based life forms.

Re: Visual Studio Vs Powerbuilder

Former Member — Fri, 07 Jun 2013 17:51:41 GMT

Hi Bruce;

That is an excellent question and probably a big misconception in PB/DB-Land!

You have to remember that the real DB client driver is the one that is handling the DB data packetization on both sides of the C/S fence. PB's DB driver is not the one doing that .. in fact, the PB DB driver ( for example PBSNC125.dll) is really only an "interface" to the real DB client driver that the DBMS vendor or 3rd party provided.

So... many things that you put in the SQLCA.DBParm or other SQLCA settings are really just "passed through" to the real DB driver from PB's "interface" driver. Thus, when the blocking eature you refer to is activated its actually implemented at the real DB driver level - then, the PB interface DB driver runs a FETCH on that buffer to get it into the PB application.

FYI: Just run a PB SQL Trace and a DB Driver SQL trace and you will see what I mean.

HTH

Regards ... Chris

Re: Visual Studio Vs Powerbuilder

Former Member — Fri, 07 Jun 2013 22:15:18 GMT

Hi Terri,

Well said.

I'm assuming the discussion centers around PB Classic and not PB.Net since PB.Net uses the VS shell.

Disclaimer: I'm not VS expert by any stretch (yet) but I do use both environments daily. I suspect the VS experts Gimmy works with would have some rebuttal to a few of the suggestions. Here are a few I would be leery of mentioning (in my humble opinion of course).

Dynamic sizing or positioning of controls based on data can easily be controlled in XAML by specifying "Auto" as the width and/or height among other properties.

Any property can be modified dynamically at runtime in VS as long as it is a dependency property (which most are) via the binding mechanism in .Net.

To alternate the background color of a datagrid you add this property to your XAML: AlternatingRowBackground="LightBlue"

To make it alternate every other row's color you add this property in your XAML AlternationCount="2"

Not exactly 2 or 3 pages so I wouldn't make this argument.

I think SQL Injection can be a pro or con either way depending on how queries are written and what tools are used (LINQ, EF etc).

Minimal SQL creation can go either way too (Garbage In Garbage Out). If and ORM is being used it is probably creating the best (but probably most obfuscated) SQL.

The field formatting and validation is fast and easy in PB but I've found that the functionality in VS is much more powerful and extensible if using data annotations. The ability to create custom validations, use regex expressions, localizing error messages, and code sharing across server and client make it very powerful.

Regarding your negative experience with attracting PB talent we've actually seen just the opposite here of late. We've found it is much easier to find local PB talent than it was a year or two ago. This doesn't make it a negative for PB but a push.

The biggest and most important advantage PB has over VS is the reason it is still around and the reason we still use and support it. It is far and away the best and easiest tool for Rapid Application Development (Bruce's #4). IMHO All other reasons pale in comparison. I am an order of magnitude more productive in PB than VS. I've been doing PB a lot longer than VS but that is not the entire reason. I would surmise that if two equally skilled developers went head to head the PB guy/gal would win. I would also warn that if you lay down that gauntlet you better be ready to back it up.

Anyway just my 2¢

Mark

PS Too soon

Re: Visual Studio Vs Powerbuilder

Former Member — Mon, 10 Jun 2013 13:17:19 GMT

It might help if you could give more details of the project being worked on then people could point out how PB would help.

Re: Visual Studio Vs Powerbuilder

Former Member — Mon, 10 Jun 2013 13:56:36 GMT

We are trying to figure out whether to continue with PB or convert all our programs in VS / Java.

we run an entire system:

- accounting

- warehouse

- orders

- bubbles

- Invoices

- statistics

- MRP

- etc.

A very large project started with PB V3.0A and currently in development on PB 12.1

i'm so sad in PB

The team consists of 10 programmers.

Re: Visual Studio Vs Powerbuilder

Former Member — Mon, 10 Jun 2013 16:38:49 GMT

If the code is already in PowerBuilder then converting the applications you have to VS and/or Java is going to cost a HUGE amount of money, the applications will run many orders of magnitude slower (which will then require significantly more money to buy faster hardware), and like as not, NEVER GET DONE.

I cannot tell you how many projects I've run into where PowerBuilder applications were being "sunset" in favor of Java and/or VS and where the "new" application was subsequently cancelled due to cost and/or lack of performance, leaving the PowerBuilder app still running many years after it was supposed to have been replaced.

True story; my current main client brought me on back in 2008 to baby-sit their customer service application (written in PB 10 and supporting 500+ users) for the last year of its life while the new Java app was being finalized. Due to budget cuts they let me go in 2009 figuring "enough" had been done to allow the PB app to live long enough. In 2011 they brought me back part time to upgrade the app to PowerBuilder 12.5 and Windows 7; a project which I completed in a whopping 29 hours. As they had budgeted 1,000 hours for me to complete the project, they just kept handing me bit work to keep the app limping along until its (new) scheduled retirement date of 2013. Not surprising, my part time gig got extended into 2012 and then 2013 with the sunset date being extended to 2014.

Two weeks ago it was revealed that the Java app had thus far consumed between 45 and 60 million dollars (depending upon which group you talk to), and after all of money and years of development it was still only able to do about 25% of what the PowerBuilder app could do. Needless to say, when the gross expenditures leaked out, there was a management shakeup and within days the new Java application was "suspended" until further notice.

And the PowerBuilder app? It is now the "new" (again, it was initially developed back in the PowerBuilder 3/4 era) enterprise customer service application; I'm suddenly being handed more than enough work to keep me busy full time and it looks like we're going to be nosing around for another PowerBuilder resource by year's end.