Why does the DB Tools List Columns.vi only report -1 for the defined column size?

[SciManStev]

I am using LabVIEW 8.2.1 with the database connectivity toolset with an SQL Server 2000 database. I would like to see how large a full record could be, so I used the DB Tools List Columns.vi in the database toolset. It easilly displays the column name and the column type, but only returns a -1 for the defined size. Of course when I add up the defined size elements, it gives me -351, which is the number of columns in that particular table. The vi I am using is very simple. I open a database connection, retrieve the data, and close the connection. The retrieved data is an array of clusters. I index it by running it through a for loop, and unbundeling each of the three parameters, and reforming arrays at the end of the for loop. This is as about the simplest vi I have ever made, but only part of it works.

[G-Money]

SciManStev-

          I don't know if this gets you the functionality you want because I don't have access to your file, but I would have code it this way (see attached picture). I would have used a Array to Cluster.vi to convert the column info ouput array into a cluster so I could use Unbundle by name. I think this is what you are wanting because from what I see, you only access the file once everytime the VI runs (right?). Try this and let us  know how it works out. Thanks!!

[SciManStev]

This did not work. It gave me 351 separate clusters that each had to be selected for the defined size. Even with this rediculously sized cluster, every result was still -1. The first code should have worked. It worked fine with the column names and column type, but always gave me a -1 with the defined size. I manually added up the defined size in about 30 minutes, and got 4432. The maximum size allowed in any SQL Server 2000 record is 8060 bytes, so I was within my limits. I had wanted to test the other 45 tables in my database, quickly rather that add up the sizes individually, which would take eons. I think that either this function will not work with SQL Server 2000, or it is a true bug. Thank you for your responce.

[G-Money]

SciManStev-

           The bug part of your answer got me thinking and I checked this behavior against our CAR (corrective action request) database and found that in fact it was a bug originaly reported in 2003, found again in 2007, and now finally fixed with the release of Database Connectivity Toolkit 1.0.2 in June of 2008. So it is actually a known bug but unfortunately there was no known workaround added for older versions. I hope this helps some more. Cheers!!

[SciManStev]

Thank you so much! I will be trying to upgrade my 8.2.1 version of LabVIEW to 8.6 in the next few weeks. The last time I tried to upgrade to the first version of 8.5, I had all kinds of errors in my database communication, so I had to pull it out and reinstall 8.2.1. As soon as I get the time I will try again, only this time to the latest version, and hopefully this problem win't be there. Thank you very much for your time.