Hi
A customer asks me how to rename variables and not lose archived data in proprietary format?
I have an idea without change tag number in the varexp but I am not sure if it is possible with PcVue 12.
Thanks
Hi Anthony,
Is it for Trends or Logs?
Anyway, I think it is not really possible....
Nico
Trends
Anthony, you asked if we could do it with 12.0
Does it mean you did it already with a previous version?
I would be surprised...
Nico
Hi Antony,
I am just guessing, and I am not having deep experience with archive data management, but if I am not wrong, the whole proprietary archive data are in plain text, so maybe it is possible to do batch script to loop through all the archive files (trend), and do find and replace. Of course few things, we need to make sure the batch script is really tested, pcvue is stopped before run the script, and varexp updated at the same time to make it align with the new proprietary files. Also this must be done if backup has been configured for the proprietary archives.
But like I said, its just my guess, so maybe there is some point that did not cross my mind to make it feasible. Probably others could explain better.
Thanks,
Kantha
Hello,
On my opinion, what Anthony is asking is not possible. In oldest version if I remember well, it was not the name of the variable who was stored, but the number. But not now.
Kantha, if you do what you said, you will break all the index file and nothing will work anymore.
Stéphan
Exactly what i wanted to say !
Thank you Stephan for correcting me. Looks like much more for me to learn. 🙂
Hi all,
In old versions it was possible to configure Proprietary archive units "without attributes", then only the Tag Number was recorded and not the variable name. It is no lnger possible except for migration and compatibility.
But even if you have the variable name, it is not that easy to do.
Here are a few things a learnt when I tried to hack understand the TH files. It is just a matter of size and position
For instance here is a sample .dat content
LB,00205,0,T,System.Localhost.Mimic.OpenCount,20200108T140200.000Z,20200108T140550.239Z
TR,System.Localhost.Mimic.OpenCount,0,4294967295,1,1,,0,0,2
20200108T140200.000Z,2,192
20200108T140550.239Z,0,64
LB,00335,0,T,System.Localhost.resource.FreeVirtualMemory,20200108T140200.000Z,20200108T140550.239Z
TR,System.Localhost.resource.FreeVirtualMemory,0,4294967295,1,1,,0,0,2
20200108T140200.000Z,3467656,192
20200108T140300.000Z,3477812,192
20200108T140400.000Z,3477812,192
20200108T140500.000Z,3462900,192
20200108T140550.239Z,0,64
LB,00233,0,T,System.Localhost.resource.GDI,20200108T140200.000Z,20200108T140550.239Z
TR,System.Localhost.resource.GDI,0,4294967295,1,1,,0,0,2
20200108T140200.000Z,1483,192
20200108T140300.000Z,1736,192
20200108T140550.239Z,0,64
The blue number corresponds to the block size in bytes, then you can understand that changing a variable's name won't be a simple search/replace.
And second, in the associated .ind file you'll find these lines:
T,20200108T140200.000Z,20200108T140550.239Z,0,205,System.Localhost.Mimic.OpenCount,0
T,20200108T140200.000Z,20200108T140550.239Z,205,335,System.Localhost.resource.FreeVirtualMemory,0
T,20200108T140200.000Z,20200108T140550.239Z,540,233,System.Localhost.resource.GDI,0
The red number corresponds to the position of the first character
The blue number corresponds to the size of the block.
You may check with Pascale if the tool she did to rebuild the index file also rebuild the .dat files
Thank you for your answer.
Anthony


