Jump to content

Recommended Posts

index.php?app=downloads&module=display&section=screenshot&id=240

Name: libpq

Submitter: SDietrich

Submitted: 01 Mar 2014

Category: Database & File IO

LabVIEW Version: 2009

License Type: Other (included with download)

This is a package containing LabVIEW bindings to the client library of the PostgreSQL database server (libpq).

 

The DLL version 9.3.2 and its dependencies are included in the package. This DLLs are taken out of a binary distribution from the Postgres-Website and are thread-safe (e.g. the call to PQisthreadsafe() returns 1). As of the moment the DLLs are 32bit only.

 

The VIs are saved in LabVIEW 2009.

 

So this package works out of the box if you have a 32bit LabVIEW 2009 or higher on any supported Windows operating system.

 

Because this obviously is a derived work from PostgreSQL it is licensed by the PostgreSQL license.

 

 

A few words regarding the documentation: This package is meant for developers who know how to use the libpq. You have to read and understand the excellent documentation for the library. Nonetheless all VIs contain extracts of that documentation as their help text.

 

What's coming next?

- adding support for 64bit

- adding support for Linux (anybody out there to volunteer for testing?)

- adding support for MAC (anybody out there to volunteer for testing?)

Click here to download this file

Link to post
Share on other sites

Hi SDietrich.

 

The DLL as of version 9.3.1 is included in the package

 

 

The DLL isn't in the package so I couldn't check, but I looked at the CFLNs and they are set to re-entrant. So did you compile with "--enable-thread-safety"? (otherwise it will have to be run in the UI thread).

 

A note in the description of exactly what platforms/labview versions you are supporting would also be useful (Windows, Linux, Mac, VxWorks etc) For Windows users it would also be of benefit if you say whether you are supplying just the 32 bit or both 32 bit and 64 bit DLL (LabVIEW x64 cannot load 32 bit binaries and vice versa).

 

jgcode is the Lavag Tools Network admin. Send him a PM and he can advise on how to get it on the tools network under the Lavag banner.

Edited by ShaunR
Link to post
Share on other sites

Hi ShaunR,

 

thanks for your feedback. I added the DLL, which was hiding somwhere deep in the System32-directory (actually SysWOW64, as I use a 64bit Windows). Now it is part of the package and is installed right with the VIs to userspace, so there is no need to run VIPM as administrator and the VIs always use the DLL that they were tested with.

 

I also added notes about the thread-safety and the supported versions.

Link to post
Share on other sites

Hi SDietrich

 

It seems the libpq.dll has a load of other dependencies. When loading, it couldn't find libintl.dll. Looking at the website, the binary download is 44 MB so there are a few more than just libintl.dll. I downloaded the zip and there were a few wxwidgets DLLs that you probably don't need, but there were the libeay, zip and a few other binaries (including libintl.dll). For an out-of-the-box experience, some of those will need to be bundled too.

Link to post
Share on other sites
  • 4 weeks later...
  • 6 months later...

The current release includes the following DLLs:

  • libpq.dll (the actual driver)
  • libintl.dll
  • libeay32.dll
  • ssleay32.dll

According to Dependency Walker these are the only external dependencies. Everything else is Windows stuff and the Visual C++ runtime, of course. But I think, this might even be bundled with Windows itself, so no problem here.

Link to post
Share on other sites

Sorry for the repeated upload/release, but VIPM really got me with those source file prefixes  :frusty:  Version 1.0.0.12 now is as intended.

 

However there is some good news, yet completely unrelated: I found the 64bit-Edition of PostgreSQL and it includes the libpq.dll in 64bit and all the dependencies. So all you LabVIEW-64 users out there look forward to the 64bit edition of this package.

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Similar Content

    • By Bryan
      TestStand Version(s) Used: 2010 thru 2016
      Windows (7 & 10)
      Database: MS SQL Server (v?)
      Note: The database connection I'm referring to is what's configured in "Configure > Result Processing", (or equivalent location in older versions).
      Based on some issues we've been having with nearly all of our TestStand-based production testers, I'm assuming that TestStand opens the configured database connection when the sequence is run, and maintains that same connection for all subsequent UUTs tested until the sequence is stopped/terminated/aborted.  However, I'm not sure of this and would like someone to either confirm or correct this assumption. 
      The problem we're having is that: Nearly all of our TestStand-based production testers have intermittently been losing their database connections - returning an error (usually after the PASS/FAIL banner).  I'm not sure if it's a TestStand issue or an issue with the database itself. The operator - Seeing and only caring about whether it passed or failed, often ignores the error message and soldiers on, mostly ignoring every error message that pops up.  Testers at the next higher assembly that look for a passed record of the sub assemblies' serial number in the database will now fail their test because they can't find a passed record of the serial number. 
      We've tried communicating with the operators to either let us know when the error occurs, re-test the UUT, or restart TestStand (usually the option that works), but it's often forgotten or ignored.
      The operators do not stop the test sequence when they go home for the evening/weekend/etc. so, TestStand is normally left waiting for them to enter the next serial number of the device to test.  I'm assuming that their connection to the database is still opened during this time.  If so, it's almost as though MS SQL has been configured to terminate idle connections to it, or if something happens with the SQL Server - the connection hasn't been properly closed or re-established, etc. 
      Our LabVIEW based testers don't appear to have this problem unless there really is an issue with the database server.  The majority of these testers I believe open > write > close their database connections at the completion of a unit test. 
      I'm currently looking into writing my own routine to be called in the "Log to Database" callback which will open > write > close the database connection.  But, I wanted to check if anyone more knowledgeable had any insight before I spend time doing something that may have an easy fix.
      Thanks all!
    • By FixedWire
      Thanks to the nice work of drjdpowell I was able to easily connect & work with PostgreSQL. Did have to use the 32bit included dll's though.
      Now when I try to install & run it on a Win10 IoT machine the dll's are not found and throwing errors. Sorry no screenshot at the moment.
      The 64bit of PostgreSQL is installed on both machines & works.
      The exe of course works just fine on the dev machine.
      Does anyone have any ideas? I'm at a loss at the moment & need to get this running.
      Thanks.
    • By 0_o
      Hi,
      This is not specifically LabVIEW related:
      How do you organize important posts you read and want to save for the time of need?
      For example, I want to save an interesting post from Lavag/NI Forums or any other LV blog.
      This post might contain VIs and I would like to tag it in a way that will let me find it when it becomes relevant.
      I would like such a post to be saved locally like an RSS so that I'll get the new comments and won't depend on the site to keep the links alive.
      I see the veterans here keep track of all the new posts and even offer solutions by giving links to some old posts without having to search for them sometimes.
      Do I miss something? How do you organize it all? I hope to hear of some cool little RSS app that will let me search through the tagged vis and posts stored on my computer and not about some bookmark manager.
      Thanks in advance.
       
    • By Gepponline
      Hi,
       I'm trying to insert some NULL values in a datetime field.
      In the example, the DATA_INSERIMENTO field has a non empty value and it works correctly but DATA_INTERVENTO doesn't accept NULL.
      If I use an empty string instead of null, the VI run without any errors but it fill the database field with a 1900-01-01 and it's not what I want.


       
      If I use the DB Tools NULL VI it gives me another type of error, maybe 'cause I'm connecting a variant to a cluster of string.
      If i use a Variant to Data VI for the NULL value it returns an empty string so not the result I need.
       

      If use the string you see in the label at the bottom of my diagram in SQL Server manager, it works correctly.
      How can I obtain the same result with labview?
    • By ATE-ENGE
      Background:
      I've been using LabVIEW for a few years for automation testing tasks and until recently have been saving my data to "[DescriptorA]\[DescriptorB]\[test_info].csv" files. A few months ago, a friend turned me on to the concept of relational databases, I've been really impressed by their response times and am reworking my code and following the examples with the Database Connectivity Toolkit (DCT) to use "[test_info].mdb" with my provider being a Microsoft jet oldb database.
      However, I'm beginning to see the limitations of the DCT namely:
      No support for auto-incrementing primary keys No support for foreign keys Difficult to program stored procedures and I'm sure a few more that I don't know yet.
      Now I've switched over to architecting my database in MySQL Workbench. Suffice to say I'm a bit out of my depth and have a few questions that I haven't seen covered in tutorials
       Questions (General):
       Using Microsoft jet oldb I made a connection string "Data Source= C:\[Database]\[databasename.mdb]" in a .UDL file. However, the examples I've seen for connecting to MySQL databases use IP addresses and ports.
      Is a MySQL database still a file? If not, how do I put it on my networked server \\[servername\Database\[file]? If so, what file extensions exist for databases and what is the implication of each extension? I know of .mdb, but are there others I could/should be using (such as .csv's vs .txt's)  My peers, who have more work experience than me but no experience with databases, espouse a 2GB limit on all files (I believe from the era of FAT16 disks). My current oldb database is about 200mB in size so 2GB will likely never happen, but I'm curious:
      Do file size limits still apply to database files? If so, how does one have the giant databases that support major websites?  Questions (LabVIEW Specific):
      I can install my [MainTestingVi.exe], which accesses the jet oldb database, on a Windows 10 computer that is fresh out of the box. When I switch over to having a MySQL database, are there any additional tools that I'll need to install as well? 
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.