Dpeter

This is where the issue is. The record of open connections has a type issue with DVR for whatever reason. I've gotten the library working by making a packed library of all the commands that I need to use, and running diagram disables to remove all calls to Result Record.vi and Connection Record.vi (where the multi threading is handled). I wonder if it is because the DVR section is not a type def or a strict type def.

It appears to be the unbundle by name. on the DVR. But it behaves...oddly. Reinstalling the package because I managed to really break something. <Whoops the DVR was something else>. maybe.

OK I just updated one of our systems to LabVIEW 2024 and the latest postgresql. We have been running out of packed libraries due to a plugin architecture. Everything works fine right up until I pack it. This has been driving me up the wall for the past day and a half. I finally distilled it down to just the PQ Connect to try to limit potential issues and ask help from people that may not have other packages installed. Under the .1.1.9 version, I am reasonably sure that I had to copy the DLLs into the support folder to get them to work. Does anybody have an idea what I am doing wrong here? Or more to the point how to get it to function out of a packed library.

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.

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.

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.

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.

Thank you for this. Started playing with it a few days ago. It is a bit clunky to migrate SQLite code because you've changed how you approach it. That being said, now that I look at the screenshot at the top of this thread, some of this makes a lot more sense than just concatenating an SQL statement and running it through the execute. Hopefully at some point you get a chance to make this a bit more full featured and release it.