Hi, I'm Joseph Szabo. Until 2001 I worked as a programmer. Microsoft Visual Basic 6.0 was my primary programming tool, SQL Server and Access were the databases I used, and ActiveReports 2.0 was my favorite reporting tool. I owned copies of all of these products. Then in 2001 I switched careers from programming to teaching. I maintained an interest in programming, and in 2010 I began developing this project. Unfortunately, I had fallen far behind on the technology curve.
Public education requires extensive planning, organization, and record-keeping.
Software that helps teachers manage instructional units and state curriculum standards is limited in terms of availability and features.
Other computer systems for teachers either focus on different aspects of teaching, or address only one or two of the tasks I address in this project.
Budget limitations: Programming tools were expensive and difficult to afford on a teacher’s salary. Learning Visual Studio .NET became a priority, and over the years I was able to afford copies of Visual Studio 2005 and Visual Studio 2010. Unfortunately, upgrading from VB6 to .NET broke compatibility with my copy of ActiveReports 2.0. I could not afford to upgrade to ActiveReports .NET, so I had to rely on the MS Access report writer.
MS Access limitations: Access and its report writer are good tools for certain jobs, but they have limitations.
Background: Before Y2K, I worked for a large company that used SQL Server and Crystal Reports. We processed report data almost entirely on the server side via stored procedures.
After Y2K, I was hired by a smaller company that used SQL Server and ActiveReports. We processed more report data on the client side by writing code in report event handlers. In fact, nearly identical VB6 code could be used to process data in both forms and reports. This decreased the language learning curve and made project maintenance easier. Where client-side report processing was appropriate, ActiveReports provided a nice alternative to stored procedures.
Crystal Reports: In 2010, when I began working on this project, I briefly considered using Crystal Reports. I was using Visual Studio 2005 at the time, and it included Crystal. However, I was not familiar with writing code in Crystal, and I did not look forward to the learning curve. So I discarded this alternative.
MS Access report writer: I temporarily settled for the MS Access report writer for this project. Access was inexpensive and widely available, and I had gained lots of experience with it on small-scale projects over the years.
Visual Studio 2010 report writer: In 2014, I upgraded from Visual Studio 2005 to Visual Studio 2010. I considered using the VS 2010 report writer, but to me, the Microsoft approach was not as intuitive as the ActiveReports approach. So I discarded this alternative and continued using the Access report writer.
In 2015 the limitations of the Access report writer really began to show. While I was developing some relatively complex reports, I realized this project had outgrown the Access reporting tool. So I contacted GrapeCity to learn about my options.
Support and track record: The ActiveReports staff provided great technical support after Y2K when I used AR 2.0.
In 2015 the ActiveReports staff were every bit as enthusiastic and helpful as they were during Y2K. They provided .NET versions of ActiveReports and made it easy for me to pick up where I had left off many years earlier.
Features: To me, the single most important selection criterion was that you can include generic .NET code within report event handlers. Where data is concerned, I can use a similar coding approach for both reports and forms. For example, I can create and manipulate .NET DataTables and related objects within reports.
ActiveReports supports both MS Access and SQL Server directly or indirectly via .NET. As a result, future upsizing of this project from Access to SQL Server will be easier.
Creating the Unit Planner Application
I have been developing this project at home during my free time since 2010.
ActiveReports provides the flexibility to create any report I can imagine. This is important because the project’s goal is to provide all the reports teachers might need to manage instructional units. Here are a few examples.
At the beginning of the year, the Pacing Guide report provides a snapshot of a teacher’s plan for covering instructional units. It is a simple, 3-column report that groups data first by grading period and then by week.
During the year, the Unit Plan report provides a one- or two-page summary of important information associated with a unit. Among other things, it provides the teacher with a quick-reference guide during the instructional process. One of the more complex reports, it uses ten subreports to gather and display a wide range of data including genre, multicultural connections, cross-curriculum connections, themes, conflicts, terminology, vocabulary, teaching strategies, prerequisite units, and teaching activities.
At the end of each grading period, the Dates Assigned report provides a quick snapshot of completed instructional units. It is handy for record keeping. Another simple report, it groups data first by unit type and then by grade level.
ActiveReports allows this project to provide a consistent user interface across forms and reports. This is possible because the ActiveReports Viewer control is designed to work with a standard Visual Studio Windows form. Likewise, the Viewer’s own controls (Toolbar, ToolStrip, etc.) look like other standard controls provided with Visual Studio. The controls can even be customized programmatically. In this project, I added a PDF export button for easy creation of digital copies of reports.
Currently this is a single-user project, and I am the only one using it, but I estimate that the size of data for an average user would range from about 1 to 5 megabytes. For my own teaching purposes, I currently manage about 4.5 megabytes of data with this project.
This project’s use of ActiveReports is all about the basics. It uses fundamental features of AR and depends on them to work reliably. From my perspective, AR is unique and irreplaceable because of the way it integrates reports into a Visual Studio project. Specifically, I can treat an AR report much like a form. I can write identical .NET data-manipulation code in the event handlers of both objects. This approach creates consistency and encourages the KISS principle.
ActiveReports separates a project’s reporting from the database. Thus it paves the way for easier upsizing of this project from MS Access to SQL Server. Currently this project uses an MS Access database. When the project is upsized to SQL Server, the reports will require minimal changes.
The typical benefits of computerization are evident. Keep in mind that many teachers manage their instructional units with MS Word. Some even use paper-based processes. By comparison, this project offers automation of repetitive tasks, reduced paperwork, reduced clerical errors, and better organization.
Security is improved. When this project used MS Access reports, it had to instantiate and manipulate an Access object. There were ways to programmatically “lock down” the Access user interface and hide most controls, but security was still an issue. Ultimately the database was open to knowledgeable users.
The user interface is consistent. By comparison, when I used Access reports, the Access object’s interface style differed from the project’s interface style.
ActiveReports is a flexible reporting tool. It offers many options for specialized reports.
My long-term goals are to upsize this project from Access to SQL Server and provide multiuser capability. ActiveReports will ease the upsizing of this project.
NOTE: You can find a description of the benefits of upsizing at the following link. Move Access data to a SQL Server database by using the Upsizing Wizard