Issues with PostgreSQL and packed libraries

[Dpeter]

I've been using the JDP Science VIPM package but it has been causing no end of consternation when I try to pass a handle between 4 different packed libraries.  The initialize library should open the connection, Test start does a database query, test complete does a transaction and commit, and shutdown closes the connection.  I find that it takes too long to open and close a new connection in test start and test complete libraries.  I can cheat and package a global that holds the connection handle inside  the test start and a separate one inside test complete and load it on the first call to the packed library.  The issue with that is the connection count rises by two every time the product is changed, and doesn't clear until the executable is exited.  So far I found that if I go into the PostgreSQL package and change the vi to hand out the PGconn U32 directly and accept it rather than the connection, I can then get it to pass through the variant from packed library to packed library.  It looks like in the packing process each library creates it's own typedef for the connection and does not hand off well.  Generally there is an error in trying to unpack the variant.

I would really prefer to use the library as written rather than modifying it.  Does anyone have suggestions on ways to pass the handle through a variant from packed library to packed library? I included a screen shot of some of the attempts to get it to work as the connection handle or as a reference. Here is the difference between the variant when unpacked vs from a packed library.

'PQ Conn' -> PQ Connection.lvclass
'PQ Ref' -> F0C000A7
'Numeric' -> 466326216

'PQ Conn' -> Product Initialize.lvlibp:PQ Connection.lvclass
'PQ Ref' -> 5C7000FC
'Numeric' -> 466328936
 

As best I can tell wrapper from the packed library makes them incompatible and I have not found any way to get them to translate.

To be fair I also went through the effort of converting everything to ODBC and using those tools with similar problems on passing the handles.

[drjdpowell]

I have never used PPLs, but my understanding is that you would first need to put the PQ library in its own PPL, and have all other code call that PPL.  It looks like you have instead made independent copies of PQ in each PPL.

[Dpeter]

This is apparently easier said than done.  It seems that you can not just insert a class into a library.  I'll probably have to wrap each of the class functions in a higher vi and see if I can get that to work.

[drjdpowell]

Again, I've never used PPLs, but that seems wrong.  Why can't you put a class in a library/PPL?

[LogMAN]

17 hours ago, Dpeter said:

It seems that you can not just insert a class into a library.

You cannot directly create PPLs from classes. Instead, put the class inside a project library to create a PPL.

[Dpeter]

Hmm. it would not let me move the class into the project library yesterday, but it will allow it now.  <shrug> At any rate I do currently have it working by wrapping the functions and putting them in a library.  Hopefully that means that if the PQ library gets updated, I may just need to repack the wrapped library.

 

Edited August 5, 2022 by Dpeter

[Neil Pate]

On 8/5/2022 at 5:29 PM, Dpeter said:

Hmm. it would not let me move the class into the project library yesterday, but it will allow it now.  <shrug> At any rate I do currently have it working by wrapping the functions and putting them in a library.  Hopefully that means that if the PQ library gets updated, I may just need to repack the wrapped library.

 

Sometimes some weird locking of classes/libraries can occur if you dont perfectly close all opened resources.

Totally off-topic, why do you have a reference to the class and also the class object itself? I see you don't actually do anything with this cluster so it could be throw-away code, was just curious about your use case. 

[Dpeter]

That was specifically during debugging to see what I could pack and unpack through the variant.  The only one that worked was the U32 if I stripped it out when it was accessible.  That portion I left to show  things I had already attempted to get to pass through.

 

[Rolf Kalbermatter]

On 8/4/2022 at 4:59 PM, Dpeter said:

This is apparently easier said than done.  It seems that you can not just insert a class into a library.  I'll probably have to wrap each of the class functions in a higher vi and see if I can get that to work.

Basically you should attempt to use each class that you wan't to use from another class NOT in the same PPL into its own PPL. Then relink the source code of each class lib to reference to the PPL version of the class. And be VERY, VERY strict about that. If you call VIs that are not already part of an existing PPL (or don't enable the Exclude dependent library/typedef etc build option), the PPL build will include those VIs in the PPL itself and that will be a completely different VI and class in terms of name space, since myGreatLib.lvlib:myGreaterClass.lvclass is NOT the same as myGreatLib.lvlibp:myGreaterClass.lvclass as far as LabVIEW is concerned. The library name gets part of the fully qualified class name and that p at the end of lvlibp is enough to make both classes completely different implementations.