I would agree with blawson. Try removing the while loop and using the native recordset data type to see if that reduces the execution time. Also, confirm that the SQL query you are writing returns the desired results with MS SQL Server Management Studio. If that query is correct, you should only be seeing results within the desired timeframe.
I've tried using "normal fetch recordset data" but result is the same.... I run another query with MS SQL SMS with a good result then copy and paste the query and use it with LabVIEW... and still the same.. so I'm starting to believe that it's not the "fetching"...
I have never tried the link that "blawson" recommends (using OLE DB connection)... I haven't heard any thing from our IT but I will try it ASAP...
the question is how much data is in the table, but how much data is in the recordset that this query is returning... it doesn't look like a lot: 6 columns for data from the last few days for a given machine.
delays could be several things: 1) communication between server and client is slow or, 2) laggy, 3) the server is choking on the request, 4) the client is choking on the data. the first three seem unlikely since SMS works fine, but you don't know where exactly it is slow.
Benchmarking this could be informative. where does it delay: is it the query? is it the fetch? is it converting the variant? throw down some tick count functions and compare them
remove that while loop, too.
I have resolved the issue by using OLE DB connection instead of ODBC which is stated in the link you provided.. It was a huge difference.
"Why Is the Database Toolset Slow in Returning Table Data?"
(I suspect that the database-variant to data at the core of Fetch Table is the culprit. Try the normal Fetch recordset that outputs an array of variants.)