Exploring the TimeCheck Application (Part 6)

Last week, we examined the last major user interface issue for this application, adding accessibility features so that someone using a keyboard could access all of the options simply by pressing Tab. I received some good feedback on that post. It’s important to me that applications work as well as possible for everyone. This week’s post will start to examine the underlying application source code—starting with the database used to manage the user time entries.

This application will have more database information than either of the two series presented so far (Exploring the GrabAPicture Application and Exploring the TypingBuddy Application). In fact, there are a number of different databases you need to consider before writing even a single line of code. Here are the basics—upcoming posts will examine each database in detail.


  • User Settings: Each user will have individual settings that are stored on the local system. For example, a user can choose to select a default project and a default task, making it easy to log into and out of the system each day. The local user settings also contain a pointer to the network drive used to store the group settings and also to store the user’s time entries. The time entries are actually the most important part of the application because they track the user’s daily activities.
  • Group Settings: The group settings control features that affect the group as a whole are are only accessible by the administrator for editing purposes. For example, you use these settings to control whether the group can use custom tasks or custom projects as part of a log entry. If not, the group is required to select one of the default projects and/or tasks. These settings appear in a central location on the network drive. In order to provide default projects and tasks for users, these settings control two sub-databases:
    • Default Projects: This is a list of the default projects that a user can select from.
    • Default Tasks: This is a list of the default tasks that the user can perform on a given project.
  • Individual Time Entries: Every time entry consists of a time, the project selected, and the task performed on that project. Every login and log out sequence comes as a pair of time entries. The first entry logs the user into the project to perform a given task, while the second entry logs the user out of the project. Each user has a single log file based on his or her name.

These databases are all implemented using XML files, as with the previous series examples, because none of them require true relational capabilities. The reports gather information from the various time logs to create an overview of how the individual or the organization as a whole is using the computer.

As part of figuring the databases out, you also need to consider the data storage requirements. Some of the data need not appear on the network drive. In fact, it has to appear on the local drive or the application won’t be able to find the network data location. Other data appears on the network to provide centralized access to it. Here are the storage locations used for the data in this application.


  • C:\Users\<User Name>\AppData\Roaming: Contains the user’s settings and the pointer to the network drive location.
  • \\<Server Name>\<Share Name>\TimeCheck\GroupData: Contains the group settings. Only the administrator can read and write this folder. Regular users can only read this folder.
  • \\<Server Name>\<Share Name>\TimeCheck\<Year>\LogFiles: Contains the individual log files. Administrators can read and write any file. However, regular users can only read and write a specific log file.

I had considered using separate files for each project, but this seems unnecessarily cumbersome. Obviously, you may prefer a different log file and folder setup than the one used in the example. The example is extensible so you can modify the locations as needed for your organization. The reason for using a year folder is to make it easier to archive a specific year’s entries when they’re no longer needed.

Now that you have a better idea of how the databases are arranged, we’ll begin looking at the code used to implement them starting with the next post. I’m going to be out of the office until July 17th, so we’ll talk about the next post in this series on the Friday that follows (July 20th). Until that time, please let me know if you have any questions about the databases or where they’re stored at John@JohnMuellerBooks.com. You can see the next post in this series at Exploring the TimeCheck Application (Part 7).