|By Bruce Armstrong||
|March 4, 2013 09:30 AM EST||
For the past year plus I've been spending a lot of time working with a web-based BI tool (the development is actually done in a plug-in to Eclipse, but the end users access the results through a browser). The tool reminds me a lot of the DataWindow. You create objects that can either map directly to a database table or are based on textual SQL. Those objects are then combined into a composite object that the user can access to do ad-hoc queries without having to know how the underlying tables are related. The data connection is abstracted from the data access layer, and the reports it generates have an extensive event model that can be coded to respond to a wide variety of system events and user interactions.
That being said, it also reminds me of PowerBuilder and the DataWindow because as powerful as it is, it can also be extremely frustrating to work with. It rewrites the SQL in the composite objects, and sometimes it undoes a rather complicated operation that I didn't need rewritten. At that point I'm left trying to find a way to isolate my complicated operation so that the tool doesn't try to rewrite it for me.
I have been having similar problems with PowerBuidler .NET 12.5 lately. One of the updates in the .NET Framework 4.5 is a native Ribbon control for WPF. There was one in the .NET Framework 4.0, but it looks like it might have been a WPF wrapper around a non-WPF control. I wanted to try out the new control, so I installed the new framework. As soon as I did, I could no longer compile *any* WPF applications. So I uninstalled .NET 4.5, at which point I couldn't even run PowerBuilder .NET any longer. I ended up having to (a) uninstall .NET 4.5, (b) uninstall PowerBuilder 12.5, (c) reinstall PowerBuiler 12.5 and (d) reinstall .NET 4.0. Yes, I had to reinstall the previous version of .NET to completely clean it up.
I'm not sure it's PowerBuilder .NET's fault. I've got a lot of software tools on this machine, including multiple copies of Visual Studio, the Windows SDK, etc. Sybase wasn't able to replicate it with a fairly clean install. I was also setting up a second machine that had MS SQL Server 2012 on it, which also installs a couple of the Visual Studio 2010 shells. Since PowerBuilder.NET needed the Windows SDK, I attempted to install that. However, that wouldn't install until I removed all traces of the Visual Studio 2010 shells that MS SQL Server installed. It seems it's not that uncommon for Microsoft .NET related tools and SDKs to step on each other.
For what it's worth, that particular pain point was enough to finally convince me to start using virtual machines and to put the different development tools (and versions of different development tools) on different virtual machines. Once I got started (I'm using Oracle's VirtualBox, which is free), I'm surprised at how simple it is and wondered why I waited. The only snag so far is that I had to order more memory for my laptop and desktop. And eventually I might need to do hard drive upgrades. But it's better than the nightmare of software conflicts that I had to keep dealing with. If I do run into configuration problems in the future, I can just send tech support the VM image so they can see exactly what I'm dealing with.
That's all well and good, but what's the point you're probably asking. Well, all this pain got me thinking about how much pain we're willing to put up with to continue to use products that we like. There's got to be some point where the pain we experience from the tool not working the way we need it to overrides the benefits, at which point we start looking for some new development tool. With PowerBuilder the pain isn't really new. As long as I've been using the tool, and that's been for just about all the time it's been around, there's always been a point using it when it's a struggle to get it to do something, often times because something's not working the way it's supposed to. At one point somebody commented, and I think there's a lot of truth to it, that using it was like playing soccer in a minefield. The tool was buggy, but the people who had been using it for a while knew what the bugs (mines) were and avoided them, so they were successful using it. People who were new to the tool kept running into the mines, and wondered why the more experienced people even bothered using it.
I think the key for the product at that time, as well as for some of the other tools I've mentioned, is that the pain factor only reared its head after you'd been using it and being productive with it for a while. So you had some feel for what the tool could do and liked it, and you were willing to put up with the pain to continue to achieve the benefits. That's important, because if you start experiencing the pain point sooner than that, you won't get a feel for the advantages that the tool offers and wouldn't be motivated to continue using it.
I also got to thinking that this may be the reason that some people aren't as excited with the PowerBuilder .NET IDE as I am. Of course, I'd already been doing .NET development using Visual Studio for quite some time by the time that PowerBuilder .NET became available, so I was already familiar with the advantages that a .NET development tool offers. But for people who aren't sold on the benefits of .NET just yet, I'm not sure if some of the pain points associated with using that IDE aren't enough to keep people from using it before they get to the point where they realize the benefits. In particular, when I want to have PowerBuilder .NET interact with some .NET classes, I'm often starting with what I know is working C# code. I might even have created a small sample of what I needed to do in C# first. So when I'm working in PowerBuilder.NET, I'm mostly converting the C# code into the syntax that PowerBuilder .NET will accept. People who aren't that experienced with C# - or who aren't starting off with working C# code - face a double burden because they often don't know what the script is supposed to look like yet.
So, I do feel your pain. I know that I can find the .NET IDE a struggle to work with at times, and I imagine it's much more of a struggle for people new to .NET. We need to encourage SAP to work on making PowerBuilder.NET even simpler to use, particularly for people who are new to .NET. Customers will never learn to appreciate what it can do if they have trouble with it when they first start using it. Eventually you hit roadblocks with any tool, but they should come when you're pushing the envelope, not when you've first using it.
|mlibner 04/29/13 10:18:00 AM EDT|
I agree completely. I struggled with the same problems until I installed PB.net and Visual Studio on a different VMs. SAP needs to continue developing the tool to reach its full potential. If people will step out of their comfort zone and give PB.net a chance (instead of bashing it) they will see how much easier integrating with other .net developers, vendors, tools, controls etc. it is than Classic. When a hammer is the only tool you have everything tends to look like a nail.
|Dimitri Joosten 12/29/12 08:18:00 AM EST|
Totally agree on this article! I find myself in solving problems in C# first and then "translate" it into PB script. To me PB.Net is the best PB yet as you can do much more with it once you know how .Net and XAML works.I know for many people it will be a learning curve. I hope SAP comes with improvements on the product soon with new targets like HTML 5 and winRT and an upgrade to .Net 4.5
- Where Are RIA Technologies Headed in 2008?
- PowerBuilder History - How Did It Evolve?
- Creation and Consumption of Web Services with PowerBuilder
- Cloud People: A Who's Who of Cloud Computing
- DDDW Tips and Tricks
- Cloud Expo 2011 East To Attract 10,000 Delegates and 200 Exhibitors
- Working with SOA & Web Services in PowerBuilder
- Dynamically Creating DataWindow Objects
- OLE - Extending the Capabilities of PowerBuilder
- DataWindow.NET How To: Data Entry Form