Fix Apparent Bug with BIGINT in Database Toolkit

[zenthoef]

When I try to pull a BIGINT value from a SQL database with the Database Toolkit the variant that is returned apparently does not have the value from the database. I say apparently because if you convert that variant to a string you get the data. 

My issue is that when the data is in variant format it looks like the data is gone. I think that the value should be displayed to avoid errorneous thinking that there is a problem with my SQL query. This is very misleading and I think the variant value and the string values should match. Otherwise, it looks like there is an issue with my SQL statement. 

Here is a screen shot of my code in which this occurs:

[Wart]

I've seen this lots of times, and occasionally it throws me for a loop.  I don't think this is unique to BigInts either, because I've never used them.  I've never worried about it enough to pay attention to what field types cause the variant to not display a value.

[AristosQueue (NI)]

I *think* the following is true. It might be totally wrong... this is not an area of the LabVIEW code base that I usually work in.

I believe that the problem comes from data whose value we don't know how to interpret. When you make the call to actually convert the variant into a string, I *think* the OLE Variant actually calls back to the database system to do the translation. The LabVIEW Variant (which contains the OLE Variant) is just holding onto some key or something and needs the database to make it a string.

I don't know that is true. I think that's why you're not seeing anything in the LV Variant control. And I think that's why this isn't a bug. If anyone on the R&D team gives me more information, I'll let you know.

[zenthoef]

AristosQueue, I think you are probably right. Even if that is the case, it is incredibly frustrating to look at the 2D variant control and think that some of the data didn't make it through. Only to find later it really was there all along, but just hidden! 

When doing these queries I usually look at the variant that is returned first to make sure my query is working before doing any processing of the data. Maybe I just need to stop doing that... 

Maybe its not a bug, and maybe nothing can be done about it, but it sure is counter intuitive when all of the data is in the variant except for one piece!

[AristosQueue (NI)]

Yeah, I can understand that frustration. Looking at the variant, you see at least the data type. That tells you that something put data in there. Might be just an empty array not the 2D array of values you were hoping for, but you know it got far enough to put *something* in there.

It may be worth modifying the variant control to display a bit differently, but I don't think there's anything buggy with its current definition... just that the current definition isn't as helpful as it could be.

[Wart]

An interesting idea!  Is that why there are two ways of turning the variant data into a type we care about?  Variant to Data maybe doesn't try to have the database do the conversion, but Database Variant to Data does?  Or, like you said, that might be totally wrong or out of date.

[Darren]

Any idea that has received less than 2 kudos within 2 years after posting will be automatically declined.