cancel
Showing results for 
Search instead for 
Did you mean: 

PB 12.6 Issues with 64 Bit Executable

Former Member
0 Kudos

Good Day!

I have migrated my PFC-based application to PB 12.6.

First Issue:

Using a 64 Bit deployment, my application crashes when a very simple function call is made:

SQLCA.of_SetMyVariable( TRUE ) /* All this does is set an instance variable in my transaction object (n_tr) */

The app crashes and halts immediately. I get no meaningful messages. I ran it with /PBDEBUG and I saw that a runtime error was incurred, but nothing meaningful. If I comment out that call, the application continues just fine. When testing, I put some message boxes in to see, for certain, whether or not this was the culprit and it is. The code never gets into the function, itself. It fails when it tries to call it.

Obviously, all works just fine in the IDE (32 bit) and a 32 bit executable.

Second Issue:

When I use the runtime packager and try to create a 64 bit MSI, I get an error stating file pbrth126.dll cannot be found. I've tried with and without DB Interfaces and Other Components. The file does exist but it's in C:\Program Files (x86)\Sybase\Shared\PowerBuilder\x64 and the packager is looking for it under C:\Program Files (x86)\Sybase\Shared\PowerBuilder. Has anyone else hit this? Is this a known issue?

Any assistance would be appreciated.

Tom

Accepted Solutions (1)

Accepted Solutions (1)

former_member202249
Active Participant
0 Kudos

Hi,Tom,

On the second issue, I just ran the PB 12.6 64 bit runtime packager with all the defaults.  It ran successfully without the error that you are seeing. Using Process Monitor, I can see that it is only accessing pbrth126.dll from  C:\Program Files (x86)\Sybase\Shared\PowerBuilder when creating the msi.    Do you have a copy of the 32 bit dll in this directory?  

Pat Steinhardt

Former Member
0 Kudos

No, there is no pbrth126.dll in that directory.

former_member202249
Active Participant
0 Kudos

Tom,

pbrth126.dll is used for ADO.NET.  I do see in process monitor that when I uncheck for ADO.NET database, it still does access the 32 bit dll when creating the msi.   When installing PB 12.6, did you do a complete install or only install the database drivers you use? 

Pat

Former Member
0 Kudos

I only installed the drivers I use. When the packager runs, ADO.NET is not checked, nor is it select-able (it must know I did not install the ADO.NET driver).

former_member202249
Active Participant
0 Kudos

Tom,

I've uninstalled PB 12.6 completely and only reinstalled the PB 12.6 Classic(WPF runtime uses that dll also) with the ODBC drivers and the pbrth126.dll is still installed in C:\Program Files (x86)\Sybase\Shared\PowerBuilder and the msi gets created successfully without errors.   If you could tell me exactly what  you installed when you installed PB 12.6, I could try that and open a CR if I can replicate the error but you might want to uninstall PB 12.6 and reinstall at this point.


Pat

Former Member
0 Kudos

Hi Pat -

I went ahead and uninstalled PB 12.6 and re-installed as follows:

  1. Only PowerBuilder (de-selected SQL Anywhere and InfoMaker)
  2. Selected only the following for install:
    1. PB base componants (including x64 runtime)
    2. Native Database Interfaces
    3. SCC Interface
    4. PB Resource Monitor
    5. PB Runtime Packager
    6. Help Files

PBRTH126.DLL was only installed under C:\Program Files (x86)\Sybase\Shared\PowerBuilder\x64.

Silly questions: Why does the Runtime Packager not look for this under x64 when I am creating an x64 MSI? Why does the 32 bit MSI get created just fine even though the 32 bit file was not installed?

Thanks!

Tom

former_member202249
Active Participant
0 Kudos

Hi Again,

Reproduced it with just what you have installed.   Not sure what I unchecked would have installed it but will research it and probably open a CR.

Pat

Former Member
0 Kudos

Thanks!

former_member202249
Active Participant
0 Kudos

Tom,

There seems to be more issues when PB .NET is not installed when creating MSIs.   I have opened CR 769876 and will escalate it to engineering.

Pat

Former Member
0 Kudos

Thanks and have a great weekend!

Former Member
0 Kudos

Hi Pat,

Please let us know when a fix is available.  We are unable to create an MSI that will allow us to test our application on stand-alone workstations.  We did NOT install PB .NET but did install all the DB drivers. - We are getting the same message reported above PBRTH126.dll missing (it is not in Shared) .  After copying the file from x64 to the Shared (just to get past the message) got another message about Sybase.powerbuilder.datasource.db.dll missing - it is NOT missing.

Please advise

former_member202249
Active Participant
0 Kudos

Hi Yakov,

I can see that the CR says it has been fixed and is in QA but I don't have a build to test it with so cannot verify that myself.  It is unclear to me what the fix actually is though as the notes say that what the developer did was disable the checkboxes for .NET components if PB .NET is not installed.   Hopefully it will be in the next EBF released.  I don't have a date on that either but hopefully soon.

Pat

Former Member
0 Kudos

Has there been any news on this issue?

former_member202249
Active Participant
0 Kudos

Tom,

The fix should be in the next EBF.  The fix was implemented the same day as the build for EBF 23645: 12.6 SP00 PL01 (build 4011) but is not listed in the fixed bug list.   I have not tested it but QA has but you may want to download and test it as many times fixed bugs do not make it into the list as they have not yet been tested by QA.

Pat

Answers (3)

Answers (3)

Former Member
0 Kudos

Have you done a full regen and optimized the pbls?

This sounds like an error in an internal object.

Former Member
0 Kudos

I did several full regens, but no optimization... let me try them both.

Former Member
0 Kudos

I optimized, full rebuild, project deployment with Full Rebuild and still dies... very odd.

former_member190719
Active Contributor
0 Kudos

>>Second Issue:


You should consider posting unrelated technical questions in separate threads.   Otherwise, people may only see one and not respond to the other, or feel compelled to be able to answer both if they are going to respond at all.  Could make figuring out what they are responding to later difficult as well.


Former Member
0 Kudos

Good point...  I will move it

Former Member
0 Kudos

Just a thought,

Do you have a pfc_n_cst_platformwin64?

Don't think you will be able to call 32-bit external functions.

Ben

Former Member
0 Kudos

Hi Ben -

This function is just a native PB class function which sets a variable. Should the platform object matter for that type of call?

We do not have a 64 platform object yet.

Thanks!

Former Member
0 Kudos

Hi Tom,

Well it is guessing for us to.

Is the SQLCA OK, where you able to connect successfully?

Maybe it is the argument, is there some implicit type conversion, what arguments does it have?

Does the export of the object looks OK; what does the function actually look like, i.e. it's type definition?

One rather harsh way to check if the object is OK is to export the object and then completely delete it from the pbl (or better in a backup) and then re-import it. Sometimes it will show errors especially with inheritance that are not catched otherwise. But I would say it might be the argument and it's types.

Ben

Former Member
0 Kudos

The application is not connected at the point when this function is called. SQLCA is instantiated, of course. All that function does is accept a Boolean parameter and set it into an instance variable. Super simple...

I tried your idea. Deleted and imported the object using exported source (sr file). No errors. 32 bit works just fine but x64 does not. I think it's time for a support ticket.