# Better CSV layout for tag alert properties **URL:** \ **Category:** Ignition\ **Created:** [April 25, 2011, 10:50pm UTC](https://forum.inductiveautomation.com/t/better-csv-layout-for-tag-alert-properties/2893 "2011-04-25T22:50:09Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![MadMax](https://avatars.discourse-cdn.com/v4/letter/m/8baadc/32.png) [@MadMax](https://forum.inductiveautomation.com/u/MadMax)\ **Post date:** [April 25, 2011, 10:50pm UTC](https://forum.inductiveautomation.com/t/better-csv-layout-for-tag-alert-properties/2893/1 "2011-04-25T22:50:09Z")
The current SQLtag CSV import/export alert data format is difficult to use, with multiple alert data items jammed into one column. It should be easy to migrate alert parameters from a competitor’s HMI, with one column per data item. A side benefit would be a more human readable/editable/verifiable format. The name of the game in successful system integration is speed and precision. Beefing up Ignition’s abilities to import competitor’s HMI configurations will go a long way in helping upgrade systems. Just say’in… 😉 ---
**Author:** ![Carl.Gould](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/carl.gould/32/7262_2.png) [@Carl.Gould](https://forum.inductiveautomation.com/u/Carl.Gould)\ **Post date:** [April 29, 2011, 6:13pm UTC](https://forum.inductiveautomation.com/t/better-csv-layout-for-tag-alert-properties/2893/2 "2011-04-29T18:13:20Z")
This is tricky for us since our alarming configuration allows for an arbitrary amount of setpoints, and CSV is purely tabular - no nesting ---
**Author:** ![MadMax](https://avatars.discourse-cdn.com/v4/letter/m/8baadc/32.png) [@MadMax](https://forum.inductiveautomation.com/u/MadMax)\ **Post date:** [May 4, 2011, 4:24pm UTC](https://forum.inductiveautomation.com/t/better-csv-layout-for-tag-alert-properties/2893/3 "2011-05-04T16:24:32Z")
As long as each “State Name” is unique for each tag’s alerts, a new spreadsheet row for each alert should be workable. I must also emphasize the importance of an easy, human-readable format. The SCADA systems I work typically require client independent QA verification and documentation of tag configuration and alert configuration. Importing/Exporting with CSV files has always been the tool for this job, but if it takes a Rosetta Stone to encode it/decode it, it’s for all practical purposes unusable. Please take this as a suggestion, not a criticism. I know you guys are peddling as fast as you can! ![:thumb_left:](https://us1.discourse-cdn.com/inductiveautomation/original/1X/e26afb081ddde6df016df6ee49159cf56aaca688.gif ":thumb\_left:") ---
**Author:** ![Carl.Gould](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/carl.gould/32/7262_2.png) [@Carl.Gould](https://forum.inductiveautomation.com/u/Carl.Gould)\ **Post date:** [May 5, 2011, 11:52pm UTC](https://forum.inductiveautomation.com/t/better-csv-layout-for-tag-alert-properties/2893/4 "2011-05-05T23:52:50Z")
> [@MadMax](#): > > Please take this as a suggestion, not a criticism. I know you guys are peddling as fast as you can! ![:thumb_left:](https://us1.discourse-cdn.com/inductiveautomation/original/1X/e26afb081ddde6df016df6ee49159cf56aaca688.gif ":thumb\_left:") Don't worry, we're used to plenty of "constructive" criticism. I agree that the CSV format is pretty gnarly. Curious - would an XML format be acceptable for client verification? ---
**Author:** ![MadMax](https://avatars.discourse-cdn.com/v4/letter/m/8baadc/32.png) [@MadMax](https://forum.inductiveautomation.com/u/MadMax)\ **Post date:** [May 6, 2011, 3:19am UTC](https://forum.inductiveautomation.com/t/better-csv-layout-for-tag-alert-properties/2893/5 "2011-05-06T03:19:43Z")
I think XML format is forward-looking, and I could get used to using it, no problem. With more and more industry usage and better editing/viewing tools coming available, I think it would be a fine choice, not only for verification but also bulk imports and exports. Just please stay away from the urge to compact the data format with encoding so it is very readable. -Thanks ---
**Author:** ![Robert](https://avatars.discourse-cdn.com/v4/letter/r/e95f7d/32.png) [@Robert](https://forum.inductiveautomation.com/u/Robert)\ **Post date:** [May 6, 2011, 9:22pm UTC](https://forum.inductiveautomation.com/t/better-csv-layout-for-tag-alert-properties/2893/6 "2011-05-06T21:22:12Z")
> [@](#): > > Curious - would an XML format be acceptable for client verification? Could you do both? One of the (big) reasons for the XML format is that when importing/exporting to/from other tools/programs, the data can be manipulated easily into different formats. The easiest format to work with (manually) is excel. Maybe you can created a number of "plugins" to create files in different formats for different size=50[/size] programs