Open Source PowerBuilder based EMR Clinical Groupware

The PowerBuilder group on FaceBook pointed to the open source project “EncounterPRO EMR Clinical Groupware for Pediatrics and Primary Care” at encounterpro.org.  This project uses a mix of C# and our beloved PowerBuilder.
PowerBuilder 11.5 is used for both the client application UI and server components.

This seems to be an open source version of a proprietary product – don’t ask me how that all works and the relationships.
This open source version is still in development, there don’t seem to be any installations yet.  The However the project is addressing the common issues in both the client UI and EMR server-side that I am familiar with.  I will be giving this a look, see how it stacks up to ‘openMRS‘ and whether I should be spending my spare time here instead.

Open MRS has the advantage of an installed “customer” base with a worldwide mission.  This ‘EncounterPRO’ project has a strong focus for the physician/nurse encounter workflow – which I see as more important the back-end services.  From skimming the docs it seems to be using a more general workflow engine, which matches my general approach to problems.  Additionally, using PowerBuilder just makes the cake that much tastier!

Maybe mobilize this with Appeon?  Version 2.0 is now in beta and it looks good.

Advertisements

SAP Archived PocketBuilder

I was poking around the Appeon and SAP sites and such when I fell across a link to our beloved PocketBuilder.  It has not been totally scrubbed but moved to an ‘archived’ location:
http://www.sybase.com/products/archivedproducts/pocketbuilder

So, if you’re wanting win bar bets by pointing out the “already invented by PocketBuilder” ideas, just reference this area.  Things like:

  • Occasionally connected, transactional, data access objects using MobiLink (2003).
    On top of the rock solid ACID SQL within the device itself.
  • Easy access to web services from the mobile device (2004).
  • 4GL objects for barcode & fingerprint readers (2004).
    This included support for multiple hardware variations.
  • Referring to the user’s source code library as the ‘pickle’ (in homage to a PowerBuilder shorthand).
  • 4GL objects for tying the contact list to the device’s phone for easy calling and lookups (2003)
  • 4GL objects for GPS, SMS, Camera, and SIM card (2005).
    And yes, these support multiple hardware variations.
  • The PocketBuilder group also ‘snuck’ features into PowerBuilder – like enhancements to direct file access, edit masks, and display formats (hex, boolean, etc).

Internally this project was run using agile techniques such as nightly builds, nightly QA runs, burn-down lists, and frequent internal and external releases.  This was a small project that made a profit, but not large enough for a big company to bother with (IOW – if this was a company in my garage, we would be very very happy).

Blast From the Past – Same PBL in Different Targets

This PowerBuilder shortcoming popped up again in some emails this week…
The issue – having the same PBL in different targets (all in the same solution).
We first discovered this problem ages ago (even before ‘targets’ existed) – where one PBL is shared between different applications.

The cause of the issue is that the compiled P-Code (stored with the PBL) is dependent on the other PBLs in the target (the code generated depends on its ancestors in the inheritance tree).  IOW – the P-Code became slightly application and environment specific.

The result – sharing that P-Code between different targets, with possibly different ancestors, will lead to difficult/impossible to debug runtime errors. Needless to say, this led to a long history of customer issues…

However – if the ancestors were the same (and same order!), and if all the applications had the same compiler switches, sharing a PBL between targets would work.  Unfortunately, there is that one time where something was changed, and the system would be inconsistent.  This is that difficult/impossible to debug runtime error.

In PB.Net – we wanted to relax this distinction, but we ran into the same code generator issues.  The intermediary code and other cache information is stored in the PBL directory, next to the SR* files (in the ‘obj’ directory) hence locking in a target dependency (sigh).
There was some reason (I don’t remember what) the compiler guys wanted the files in the same directory structure rather than a parallel directory somewhere else (I can imagine a host of housekeeping logistics there, so I can sympathize).

One other thing – PB-Classic would attempt to prevent you from having the same PBL in multiple targets, but its checking was quite imperfect.  This checking was improved in PB.NET (having a fresh slate makes those things easier).

In short – don’t share PBLs between targets.

File.New behavior with SCC in PowerBuilder.NET

Question:
What happens when the library (PBL) is not checked out, and I try “File → New” ? Or more generally, how does “File→ New” interact with Source Code Control systems…
Short Answer:
The “File → New” action may fail, depending on how “automatic checkout” is set.
The attached document (PB125_SCC_Note1.pdf) contains the three scenarios for how “Automatic Checkout” may be set along with screen shots of the (current) behavior in PowerBuilder.NET.
The test case is for Microsoft’s Team Foundation Server (TFS) but everything should be the same for other SCC providers.
(Originally published 17 February 2011)