Unable to create file buffer DB Tools Open Connection LabView

[darrenlwoodson]

Hello all,

This is my first time posting in this forum so I apologize if I am not utilize this tool correctly. Please let me know if there is a better location/topic/tags etc. that I can use to better align myself with forum expectations.

Here is my setup; I am attempting to use the DB Tools suite in LabView (LabView 16.0 (32-bit)) to create (Open Connection) a database connection reference object and then use the Select Data tool to query my PostGRE server for the required information. Pretty standard stuff I imagine. I'm using the string variation of the Open Connection tools with a network filepath leading to a stored dsn file containing all the network information. I then feed my username/password info and timeout information into the sub-vi. On other machines around my workplace that have a similar program (I'm duplicating portions of it for another project) run this portion of the program fine. However my current setup on my own dev PC receives an error on the Open Connection tool.

I'll include screenshots of the vi and the error.

I've searched NI forums, I've searched forums specific to ODBC and the very few posts even contain this error suggests one of three things:

The first possible issue that the forums suggested was that the dsn file and dsn object in the ODBC Data sources manager tool was configured with the 64 bit version of ODBC and needed to be deleted and reconfigured using 32 bit.

The second suggestion was that whatever is running the driver for this connection does not have either the space or necessary permission to create the temporary files it needs to run this process. The solution for this suggestion was to ensure the operating account has the needed permissions and that the temp directory is not full, or (as part of the suggestion mentioned) renaming one temp file to CTT0 as apparently ODBC cycles through CTT#### file names and if it reaches CTTFFFF without being able to cycle back to 1 it can cause an error.

Lastly one forum solution was that the program running the task utilizing the ODBC driver does not have enough handlers and to manually allocate more using the SetHandleCount function from the Windows API to allocate more to this task.

I've completed the first task without the problem being fixed. I am unaware of whether or not LabView utilizes a separate temp folder than most other programs, or if LabView isn't even involved but rather I need to find the ODBC temp folder. Either way I did search the usual places (i.e. /Temp and AppData/Local/Temp and Tmp) and neither had any temp files with the naming convention mentioned above. In fact I did an entire C drive search for all tmp files and none of them matched that naming convention. So I'm not sure if that is the problem.

I'm not familiar enough with the third solution to be sure how to even tackle it or if I'd be wasting my time pursuing it as it may be unrelated and I simply am not aware.

I also understand that this could be unrelated to LabView as a whole and I might need to relocate to the Microsoft ODBC forums for further assistance. But on the off chance that someone here has ran into this problem within LabView specifically I figured it was worth a shot to reach out.

Please ask any questions if I need to elaborate on any portion of this post and I appreciate any feedback anyone can offer.

[JensG69 · Accepted solution]

Hello,

according to a internet research one reason for error code 0x80004005 might be a problem of accessing a file over the network.

Can you copy your access file to your local system.

And also use "DB Tools Open Connec (Path)", not the connectionstring implementation of that polymorphic vi.

Regards, Jens

[darrenlwoodson]

I did indeed copy the .dsn file into a local location and I was then able to connect successfully and query the database. This is bizarre and unexpected because my user account is "supposed" to have higher privileges than the lab computer with a generic account that successfully runs this same program with the network file location. But alas that is another issue. Thank you for your help!