SMAT DB Message History

[Doug Miller]

I searched this topic, but just not finding answers to my questions.  We want to switch to the SMAT DB for ease of search and other benefits.  We would like to maintain a single file structure for each thread, but can’t seem to figure out how to keep that file size to 30 days of messages.  Do we utilize the Maximum Age of SMAT Files under History Options or is there another way we need to implement this configuration?  Is there any enhanced documentation on the SMAT DB and how to keep the database size manageable?  Thanks!

Topic

[Peter Heggie]

It really depends on what you mean by 30 days. If it is a ‘rolling’ 30 days, then it is difficult. If it is not rolling, then as soon as the job or utility runs that cycle saves and starts a new Smat DB, you will only have a day or less of data and will have to go back to the .old or whatever name you have for previous versions.

The site options seem to be geared towards file management but not a ‘date range’. We implemented a two part system where we cycle save out Smat DBs weekly, and then rename the .old to _.back7.

So basically we have the previous week plus the current, partial week. So at least we have a week’s worth of Smat available. It is not a true, rolling 7 days. If I was more adventurous, I might try experimenting with SQLite commands and see if we could manually copy messages in and out of a ‘week’ Smat DB just to keep it a consistent 7 days worth of data, but that seems like a lot of work for not much gain.

Peter Heggie

[Mark Thompson]

You can enable SmatHistory in site options to keep multiple versions of old SMATDB files.  Setting the Maximum Age of SMAT Files on that same panel will clean up old files when they age out.  The search tool allows the option of searching in the SmatHistory directory located in the process directory.

There is no built-in option to cycle SMATDB files on a regular schedule.  Might be coming in 6.3?  Many people do that by cycling SMAT files using a script that runs from cron or a UPOC timer.

- Mark Thompson
HealthPartners

[Doug Miller]

I guess I missed the email reply to this message.  Is there a good resource on how SMAT DB works that I could reference?  Tried reading the help pages, but not very helpful.  For example, if I use the default SMAT DB configuration – how long will a single SMAT file save messages?  If I implement the SMAT History on SMAT DB – how does that work?  We used to have a SMAT cycle job that ran nightly but were told by our engineering team it’s not needed any longer.

The bottom line is, I would like to set up a configuration that uses a single SMAT file for each thread that will hold about 30 days worth of messages and then clear them out.  I’m not opposed to using SMAT History, but just want to understand how it works.  

SMAT Files seemed logical in it’s functionality.  So far, I haven’t been able to figure out SMAT DB and am looking for whatever I can to help it make more sense.  Thanks for any help!

[Keith McLeod]

Doug,

We use a script to cycle daily for the smatDB files.

[Keith McLeod]

In regards to SmatHistory, when you have it enabled it will automatically create the /SmatHistory directory.  Whenever you cycle a saved message it will move the current file with a date and time stamp into the SmatHistory folder for the given process.  Similar to the hcicyclesavemsgs of yester year with Inboundsave and Outboundsave directories.

If you cycle mid day with SmatHistory enabled it will perform the same process by placing a copy in the smatHistory and zeroing out the current.

Hope this helps again…

[Author]

Replies