loquin

We've had quite a few requests over the years for information on trending. That is, displaying a continuously changing set of data in a graphical format. Essentially, you are plotting Y-Value(s) over time.

In my prior life (Before IT) I was a control engineer, and I was heavily involved in this area, so I threw together a couple of simple demo applications. Both the apps use a very simple graphing technique - just drawing lines on a picture box. In a more fully developed system, you would probably want to move to a more powerful charting tool set, such as MS Chart, or review BillSoo's excellent tutorial: How to Create a Line Graph.

The preferred method of storing data for such a system is by using a database. There are several reasons for this. First, the ADO database objects and relational databases offer powerful methods for storing, retreiving, and sorting data. You can greatly improve the security and reliability of your system by using a database. In addition, database servers such as MS SQL Server (MSDE), Oracle, PostgreSQL, and MySQL are designed for multiuser access. This greatly enhances the ability of your application to be scaleable. In other words, you can much more easily expand your system by using a database server to store and retrieve your data. In fact, in larger systems, it is common to have a separate database server to store the data, with one or more I/O systems which populate the database, and one or more user interface systems, which are used to display the data to the users.

However, when using a file based application, (including the use of MS Access) it is much more difficult to expand to support multiple users. Even though MS Access "supports" multiple users, it really doesn't do so very well, and is subject to various problems, including database corruption and possible data loss. Therefore, in my opinion, a process i/o system should rarely, if ever, use data files or MS Access to store the process data. The database trend version that I've attached does include an Access datafile, but, remember - this is just a demo. I really don't recommend that you put your job on the line by trying to deploy a real-world, real-time application that uses Access. (But if you do, be sure to keep your resume up to date.)

*****

In both of the example apps I've attached, the application itself takes care of periodically generating dummy data and storing the data into a database, or into an array. This would be handled by a separate I/O loop process in a real-world app. Within the same timer event as the data generation/storage are calls to subs to display the data on a picturebox.

The code is fairly well commented, and is modular. If you have questions regarding it's use, please post them in the approriate forum.