LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Labview/Postgres crash when recovering Array of REAL?

Hello all,

I have got a strange behavior when requesting 1 record (LIMIT 1) from a Postgres table. The table has 3 fields:

  • Time
  • ID: Array of 4023 INTEGER
  • Value3: Array of REAL

I am executing the following command:

SELECT time, "ID", “Value3” FROM "ExtrudersHead_Measurements_Values_Arr" LIMIT 1

When there are less than 3505 elements in Value3 I get my one record back successfully.

When there are more than 3505 elements in Value3 I get a Labview crash message (see attached file).

What is wrong ?

Thank you very much for any insight

Christophe

Download All
0 Kudos
Message 1 of 7
(1,141 Views)

Unfortunately, I can't open your VI.  I just have a bunch of questions about your post. None of them will likely solve your issue.

 

  • Why would you query every item in the table only to select 1 at random?  You don't have a WHERE clause or an ORDER BY clause to narrow down the recordset.  What is the purpose of this query?
  • I don't understand what you mean by "Array of 4023 INTEGER" or "Array of REAL".  I'm not familiar with Postgres nor am I familiar with having an array as a field type.  To me, this seems like a bad idea and really defeats the purpose of an SQL database.  How does LabVIEW interpret this array data when it returns a recordset? 
  • I would recommend to use better naming convention for your field names.  Time and ID are keywords in most databases and value3 is just meaningless. 
aputman
------------------
Heads up! NI has moved LabVIEW to a mandatory SaaS subscription policy, along with a big price increase. Make your voice heard.
0 Kudos
Message 2 of 7
(1,097 Views)

- The reason of the LIMIT 1 is just to be sure that I am asking a very small amount of data back from the server in the recordset. It is of course not something that I plan to use in production

- If I use a WHERE that is supposed to return the least information back, Labview crashes if I define my ARRAY of REAL (Value3) with more than 3500 elements. Same as if I do not use WHERE but LIMIT 1. If I use a WHERE that is supposed to return nothing then Labview does NOT crash and returns nothing (as expected)

- ARRAYS are types that do not exist in SQL SERVER but well in other families of relational database such as POSTGRES of TIMESCALEDB. Very convenient when you have to store a collection of elements acquired at the same timestamp for instance. Way more efficient than storing each element separately like we have to do in SQL Server. 

- I have replaced Time and ID with other names and it did not change the problem.

- I am attaching a snapshot of the very basic code that I use.

 
0 Kudos
Message 3 of 7
(1,094 Views)

It sounds like LabVIEW doesn't support the array datatype since the only time LabVIEW doesn't crash is when there are 0 records in the recordset.  Why not store the data as CSV in a text field type?  This can easily be read into LabVIEW and can be converted into an array after the query is executed.

aputman
------------------
Heads up! NI has moved LabVIEW to a mandatory SaaS subscription policy, along with a big price increase. Make your voice heard.
0 Kudos
Message 4 of 7
(1,088 Views)

No. Labview and the DB Tools support Array Datatype. Like I said in my original post: the restriction that I found does not apply to INTEGER ARRAY (this works with thousand of elements, no problem) but only to REAL ARRAY (above 3500 elements. Below 3500 elements, no problem).

0 Kudos
Message 5 of 7
(1,079 Views)

I wouldn't call that supported but maybe that's just me.  😉

So why can't you use CSV data stored as text in the dB, as i mentioned before?  That, on the other hand, is fully supported and easy to convert to an array in LabVIEW.

aputman
------------------
Heads up! NI has moved LabVIEW to a mandatory SaaS subscription policy, along with a big price increase. Make your voice heard.
0 Kudos
Message 6 of 7
(1,066 Views)

I do not want to use CSV for various reasons, the most obvious one being wasting so much memory to store REAL or INTEGER into STRINGS...

But let us wait for other Labview/PostGres users feedbacks 😉

0 Kudos
Message 7 of 7
(1,062 Views)