Hi Kelly;

    While most DLLs have unique names however, a few   DLLs have the same name. So the latter could be your issue. There are two ways to proceed (IMHO).... 

1) Place the respective run time DLLs in each App's folder where the EXE resides.

2) Use the PB Packager utility to install the respective run-time DLLs into their unique folder. Then place a link to each in the System Path. However, make sure the the higher PB version is 1st in the System Path. The common named DLLs need to come from the higher runtime library folder.

HTH

Regards ... Chris

always put the dlls' in the application (exe) directory.  it prevents so many easily avoided installation errors.

That is strange because we run what seems to be an identical setup and have never had a problem with two or even three versions running simultaneously. In out setup, we have a PBDLLS folder that contains the PowerBuilder runtime dlls (excluding any .NET DLLs).  This folder is included in the workstation's path.  We also have a PBEEXC folder that contains our compiled PowerBuilder applications, .EXEs and .PBDs an any necessary .NET DLLs.  In our PBDLLS folder most of the PB DLLS are version named, PBVM125.DLL, PB170.DLL so there is no issue.  The ones that are not such LIBJCC.DLL, LIBJUTILS.DLL, LIBSYBUNIC.DLL have always been backward compatible.

The exclusive issue we ran into was with Sybase.PowerBuilder.DataWindow.Excel12.dll.  It is a .NET DLL supporting export to XLSX but does not have a versioned name, so when migrating dependent applications whichever application has the mismatched DLL will blow up upon saving to XLSX.  The best workaround we could come up with was to put a flag into our databases that the the applications could read and determine whether or not to give the export to XLSX option, allowing us to disable saving to XLSX any apps that were version mismatched with that DLL. 

Your problem sounds darned peculiar because if I am reading your post correctly both PB126 and PB2019 fail with the same message.  I could understand new DLLs stepping on old ones and forcing the old version to blow up, but if that is happening, it does not make sense that the new version would blow up as well.

Could some sort of a global update whether by your network people or Microsoft have blown up your computers from running any PB apps?  Can you take a step back, and on a machine that is failing with both versions, get PB126 to work in separate folders and PB2109 to work in another set of separate folders.  And maybe from there play around to isolate what is causing the issue?  Take a look at the DDLs that are not version named, because they are used by both versions maybe one got corrupted?  I know it is grasping at straws, but whatever is afflicting you must be something strange.  

For a quarter of a century we have been putting all the files into the exe folder.  But we do knife edge cutovers.  We have a separate group that creates an installshield version of the latest app with the latest PB version dlls and it gets pushed to each PC.  I separate out whether the it's a 32bit or 64bit version and this group creates the two separate install packages.

When a patch or small enhancement update is needed or even if I want to push a new version of the app because of a new version of PB, it gets pushed from the database using a modified version of Roland Smith's PBUpdater (https://www.topwizprogramming.com/tools.html).  They need the initial install done by Installshield due to DLL registration (third party related) that can only happen by this "push" or if they are an admin on the pc, and 99% of the users are not.  After that, the patch process is pretty seamless.