mrtweaver,
Thanks for the recommendation. I should elaborate on my earlier post and shouldn’t have used the term “cheesy”. Those devices are often a perfect fit for a particular problem. Suppose you had to log data 30 days back in case there was a problem, but in most cases nobody looked at the data. Compared to a PC based solution, this device is cheaper and has less potential points of failure. FTP access (or a builtin web server) provides simple access from anywhere, and the CSV format (hopefully zipped) is easy to read on any computer and manipulate with Excel.
These devices get knarly and loose much of their benefit when integrated into the Enterprise - particularly when you want to deal with data in SQL databases (for IT support, maintenance, backups, distributed visualization, analysis, etc, etc). Any way you cut it, you’ll introduce all the points of failure for the PC based approach plus this device. You’ll need to deal with transferring the file via FTP, which assumes that an FTP server is up AND implies historical data lag time since you’re probably doing an infrequent batch transfer. Writing a script to read the CSV into the SQL database isn’t hard, but something (probably a computer) has to do this periodically. Dealing with multiple logging data sources and missing/overlapping data is a big pain to deal with. It’s not that integrating these devices into your process can’t be done - it’s that they add too many moving parts. You can do better, simpler. They’re very cool and work well for what they were designed.
I interpret Al’s request as a device that basically does what FactorySQL historical groups do. The technical difference is pretty subtle, but it would play nice with an enterprise system. The device would log data remotely to an SQL database and have a local cache. It’s a pretty simple concept that could solve a lot of problems. I’m guessing that vendors don’t do this to avoid stepping on their “Enterprise Software” space. Also, given these capabilities, users will feature request this thing to death. They’ll need to support different SQL database types/schemas, want to log at variable rates or based on events (triggers), want to scale/format data, transfer data in batches, compress the data, support some form of redundancy, etc, etc. This leads to a computer and FactorySQL, RSSQL, inSQL, or whatever.