LabVIEW
Variant attributes are deleted when used with Network Streams - why?
I noticed this as well. My only thought was that since these are like a "pointer" that they aren't included. One way to get around this is to convert the variant to a string using the "Flatten to String" function. You can then send it over the network as a string and then convert it back to a variant on the other end. This action does preserve the variant attributes. I will say that this new converted string can get to be very long so sending it over the network might not be as fast as some other methods of transfering the data.
@Jed394 wrote:
I noticed this as well. My only thought was that since these are like a "pointer" that they aren't included. One way to get around this is to convert the variant to a string using the "Flatten to String" function. You can then send it over the network as a string and then convert it back to a variant on the other end. This action does preserve the variant attributes. I will say that this new converted string can get to be very long so sending it over the network might not be as fast as some other methods of transfering the data.
Your analysis is almost right! 
The string can get indeed very long but there is no way of sending that data over the network in a more compact form (save from some sort of explicit compression). So the reason that the string can get so long is the real reason why this metadata is not getting transfered within network streams. It could potentially make the network stream VERY slow.
Variant attributes being only metadata and not the real value data are not considered as important as the value data anyways. They don't change usually that often either as the value data. So by including them in the network stream transfer a potentially big performance overhead would be created that in most cases is not only unneccessary but also hurting. And adding conditional transfer of those data only when something changes complicates the whole network stream protocol significantly.
@rolfk wrote:
Your analysis is almost right!
If you absolutely need to send the variant data over the stream and both ends are running under Windows, you could compress and uncompress it using this
https://decibel.ni.com/content/docs/DOC-7200
So a year and a half later and 2015 SP1 still behaves this way. Was there a CAR made by NI to track this issue? I have several work arounds that I'll be testing for performance, but I'd much rather not need them.
Hello,
I know this is an old tread but is there any updates on this?
Hooovahh I am using your variant repository tool (very cool) how can I send this using a network stream. You mentioned a work around. I am using LabVIEW 2018
Thanks!
Okay so I think for me the work around I used was to just use the variant value and not the attributes. So for instance I had a single Variant that contained attributes of things like "Event Name", "Event Error", and "Event Data", which that last one was a Variant inside a Variant attribute while the other two were scalars of known data types.
Before sending it off to a Network Stream Write I would essentially unflatten my Variant's attributes, putting it into a cluster of a String for the "Event Name", an cluster of the error data type for "Event Error", and then a Variant for the "Event Data". I could then read, and write this cluster with Network Streams, and just use the Variant to Data to convert from my Variant to the datatype of my "Event Data" for that particular event. Still annoying but works great and ended up building off of this to allow generating user events locally, or on remote systems.
