# History with Multiple Scan Classes

**URL:** <https://forum.inductiveautomation.com/t/history-with-multiple-scan-classes/17846>\
**Category:** Ignition\
**Tags:** ignition79\
**Created:** [April 27, 2018, 4:43am UTC](https://forum.inductiveautomation.com/t/history-with-multiple-scan-classes/17846 "2018-04-27T04:43:17Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![DavidWisely](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/davidwisely/32/10482_2.png) [@DavidWisely](https://forum.inductiveautomation.com/u/DavidWisely)\
**Post date:** [April 27, 2018, 4:43am UTC](https://forum.inductiveautomation.com/t/history-with-multiple-scan-classes/17846/1 "2018-04-27T04:43:17Z")

</div>

Hi Guys,  
I would like to keep tag history at a fast rate for a short time (1 second intervals for 1 week), and the same tag at a slower rate for a longer period of time (30 second intervals for 1 year). This will allow detailed analysis of recent events, and still provide the needed information for older data, while not taking up too much hard drive space for the older data.

I’ve had a look at the Tag History Splitter, but it uses the same scan class for both recordings.  
I’ve also considered Transaction Groups, but it’s a bit cumbersome to set this up for the number of tags I’m looking at (about 1,000 tags).  
Can anybody suggest a good solution?

Thanks,  
David

---

<div class="post-metadata">

**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\
**Post date:** [April 27, 2018, 12:09pm UTC](https://forum.inductiveautomation.com/t/history-with-multiple-scan-classes/17846/2 "2018-04-27T12:09:09Z")

</div>

If you want it to be fully automatic – trending the one pen gives you the appropriate detail – you’ll probably have to record at 1-second intervals all the time, and use a separate background process to prune the week-old data in the database.  
Another possibility would be to use transaction groups with wide tables to capture the long-term data. Wide tables generally hold more data with less storage for applications where the recording interval is fixed. For just a thousand tags, you might find the storage requirements for 1-seconds intervals really isn’t that much. (~120 GB for a wide table of DINTs or REALs for a year.)

---

<div class="post-metadata">

**Author:** ![DavidWisely](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/davidwisely/32/10482_2.png) [@DavidWisely](https://forum.inductiveautomation.com/u/DavidWisely)\
**Post date:** [April 29, 2018, 7:10am UTC](https://forum.inductiveautomation.com/t/history-with-multiple-scan-classes/17846/3 "2018-04-29T07:10:25Z")

</div>

Thanks pturmel. Great suggestions.  
The pruning idea is more attractive as it will automatically apply to any new tags that are historized without having to manually add them to a Transaction Group. And I assume that a trend will still display the recent data as well as the older data even if pruning is done.

I had previously thought about pruning but was worried about how it would affect displaying the trend. Will a trend still display well, even if pruning is done?

---

<div class="post-metadata">

**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\
**Post date:** [April 29, 2018, 1:00pm UTC](https://forum.inductiveautomation.com/t/history-with-multiple-scan-classes/17846/4 "2018-04-29T13:00:38Z")

</div>

> [@DavidWisely](#):
>
> Will a trend still display well, even if pruning is done?

You'll just have to try it. I've never done the pruning approach. My customers generally prefer simple storage structures over small storage requirements. Storage is pretty cheap, after all.

---

<div class="post-metadata">

**Author:** ![Kyle\_Chase](https://avatars.discourse-cdn.com/v4/letter/k/9de0a6/32.png) [@Kyle\_Chase](https://forum.inductiveautomation.com/u/Kyle_Chase)\
**Post date:** [April 29, 2018, 5:25pm UTC](https://forum.inductiveautomation.com/t/history-with-multiple-scan-classes/17846/5 "2018-04-29T17:25:56Z")

</div>

Why not just turn on the pre-processed table functionality?

---

<div class="post-metadata">

**Author:** ![DavidWisely](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/davidwisely/32/10482_2.png) [@DavidWisely](https://forum.inductiveautomation.com/u/DavidWisely)\
**Post date:** [April 30, 2018, 12:14am UTC](https://forum.inductiveautomation.com/t/history-with-multiple-scan-classes/17846/6 "2018-04-30T00:14:29Z")

</div>

Hi Kyle, not sure what you mean here, could you elaborate?  
Or do you mean turn Pre-Processing off, to reduce space?

---

<div class="post-metadata">

**Author:** ![paul-griffith](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/paul-griffith/32/37249_2.png) [@paul-griffith](https://forum.inductiveautomation.com/u/paul-griffith)\
**Post date:** [April 30, 2018, 3:13pm UTC](https://forum.inductiveautomation.com/t/history-with-multiple-scan-classes/17846/7 "2018-04-30T15:13:15Z")

</div>

You could also use the splitter to store into two different schemas - then build out two screens with “long term” and “short term” data retrieval (or switch providers automatically in your charts/trends/whatever else based on date range).

---

<div class="post-metadata">

**Author:** ![DavidWisely](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/davidwisely/32/10482_2.png) [@DavidWisely](https://forum.inductiveautomation.com/u/DavidWisely)\
**Post date:** [May 1, 2018, 12:56am UTC](https://forum.inductiveautomation.com/t/history-with-multiple-scan-classes/17846/8 "2018-05-01T00:56:51Z")

</div>

Hi PGriffith, The problem with the splitter is that it uses the same scan class for both records. I want to record the long term data at a slower rate. Cheers.
