JollyRoger7

I was very excited to recently find the MySQL connectors for LabVIEW. There was a free/OS one posted on NI, and there was a pay for proffesionally supported one from Safir over in France. (www.safir.fr) I think a Lava member developed the free one. After I got the PO together for the Safir version, my boss tells me we may be switching to PostgreSQL, and BAM, I am back to square one. Why does it matter? Because our code base is supposed to run the same on Windows, Linux and cRIO depending and need and circumstance. Now there is a Sourceforge project for LabVIEW and PostgreSQL, but it relies on DLLs. I suppose I could do something weird like write a wrapper in LabWindows CVI and talk to that via LabVIEW? Or I could read the prorocol chapter in the postgreSQL manual and do it from scratch in LabVIEW?

Recently I was tangentially involved in a software management mess where the fact that a 3rd party LabVIEW add on was not in our source control (SVN) made it very difficult to build a new binary of a previous revision. This particular add on has many revisions. It is a work in progress as we and the 3rd party do R&D on the application. In addition they are primarily PhD's in something other the Software Engineering. The code shows this and noteably the pinouts to the applications VIs change from revision to revision. I think the OO jargon for this is Highly Coupled, meaning certain revision of our code work only with certain revisions of thier code. We have a situation where instead of any developer being able to do a build at any time, only one or two machine can succesfully build this project. I was reading other threads on this forum, specifically http://lavag.org/topic/13492-reuse-packages-and-scc/ and it looks like VIPM might be an answer. But I have specific questions about how it would work. Apparently there is a VIPC file that would be committed to SVN or any SCC. When exporting, a developer would use this file in some way to verify that the right version of the packages are installed. Is this correct? What is the "some way"? Will this process downgrade the 3rd party add on as needed? Presumably also the VIPM would in some way make sure there were not two version of the packages in the VIPC, or do something else to prevent cross-linking? So the way I imagine the use would be: Checkout the code from a previous revision. Update the 3rd party add ons to the correct version based on the VIPC file. Build the binary and installer. Delete working folder. Or if a we needed a branch of a previous revision say 5.1 from 5. Checkout version 5. Update the 3rd party add ons to the correct version based on the VIPC file. Make the required 5.1 revisions. Check the VIPC for new dependencies. Build/Test/Validate etc... Commit changes including VIPC. Is that right and does VIPM handle the package updates and dependency checks? Thanks!