Bit of an interesting problem here. I have an analysis functioning as a totalizer. This takes a given rate (say gpm), and calculates the integral since the last calculation. As a side feature, it also calculates daily totals, previous day totals, hourly totals, previous hour totals, etc...
The problem is whenever the totalizer tries to backfill (such as due to server restarts), my totalizer looks like a lightning bolt. Bah!
My solution that I've been working on is as follows: an afsdk application will routinely scan these tags, notice the lightning bolt, and shift the history prior top the lightning bolt. It works quite well except it introduces a new problem: while the totalizer snapshot is correct, the calculated totals are not due to internal analysis caching. For instance, when I calculate the current day's flow (TagVal(tag, '*') - TagVal(tag, 't')) the current value is fine but the value at midnight will be the uncorrected value.
Workaround for that is to cycle the analysis, but in order to accomplish that I need to find the analysis... The tag is named with the pattern %Element%.%Attribute%.%ID% so I thought this would be easy with that ID attribute. For analyses not defined from a template, this sql seems to work:
SELECT [id] FROM [PIFD].[dbo].[AFAnalysis]
WHERE analysisrulevariablemapping LIKE @guid
The parameter @guid is the guid at the end of each tag name, and the id returned is the guid of the Analysis.
This does not work with Analyses created from templates though. Best I can get is a hit on [dbo].[AFElementAttributeDR].[configstring], but I can't seem to find any references in or out of that element. Searching from AFAnalysis, the analysisruleconfigstring and analysisrulevariablemapping are null. No other tables seem to reference the AFAnalysis id key.
So how does AF know that "this" analysis outputs to "that" point?