The latest 32-bit release of StatusView is built with Microsoft Visual Basic version 6. It is fully compatible with current versions of Windows 2000, Windows NT, Windows 98 and Windows 95. Where possible, functionality is implemented with VB code and Windows API calls, rather than using custom OCX controls. Internal data and control structures are designed so that Windows resource consumption does NOT significantly depend on the number of StatusView users in the master database. As a result, the demands placed on a StatusView workstation remain relatively constant regardless of the total number of users in the StatusView database.
The legacy 16-bit version of StatusView is still available for those sites who continue to use earlier versions of Windows (prior to Windows 95). This version is built with Visual Basic 4.0, and is functionally identical to the 32-bit release in almost every way (some newer features of the 32-bit release are not available in 16-bit StatusView).
StatusView employs a Microsoft Access database which resides on the network server (or on the local hard disk of a standalone PC installation). The database is generated with Version 2.0 of Access, giving compatibility with both 32 and 16-bit JET engine code. This allows a mix of 32 and 16-bit StatusView client applications to concurrently connect to the same database, supporting all versions of Windows from 3.1 through the latest Windows 2000 on the same network. The StatusView database is both secure and encrypted, providing a good degree of protection against inadvertent or intentional tampering with the database. This also supplies the security mechanisms underlying the status-change and message-access restrictions offered in registered versions of StatusView. All information is stored in the database, including tables of users, workgroup names, status choices, messages, and other internal information.
Microsoft Access limits the maximum number of concurrent database connections to 255. However, in real-world environments this is a bit optimistic! In our experience, Access can handle at least 150 concurrent connections on a reliable local area network. That's why we sell licenses for up to 150 users. However, StatusView and Access can easily handle a database with several thousand users. In special situations, you may have a relatively small number of users who need to track a much larger number of personnel. For example, a small staff of dispatchers may need to monitor a much larger staff of field technicians. If you have such requirements, be sure to ask our sales department about special licensing.
StatusView includes a separate Administration Utility which provides administrative maintenance features. The Administration Utility can be used to customize the workgroup table, as well as the status choice table and its associated icons (registered version only). The Administration Utility also provides support for database optimization and repair, which can be scheduled for unattended operation on a regular basis. The Administration Utility is used to control certain StatusView features, such as disabling the integrated messaging system, for those sites who prefer to use an existing email system instead. Finally, the Administration Utility allows an administrator to shutdown all StatusView client programs on networked workstations without leaving their desk. This facilitates procedures such as shutting down the system server for maintenance purposes.
StatusView uses its own internal relative-time reference to monitor when change events occur. This allows behaviors such as automatic notification to be activated reliably, without relying on the time-of-day clock in each workstation. However, the proper operation of other features of StatusView require that all workstations have their clocks in reasonable synchronization. For example, if one user checks out to lunch "for one hour", StatusView will record a return time in the database which is exactly one hour from the current time on that particular workstation. If that particular user's system clock is significantly different from the actual time, then the recorded return time will also be in error.
StatusView provides a clock sync feature which can be used to address the time-sync issue in some network environments. For example, a Windows 2000/NT server or (Windows 98/95 workstation) can be designated as a time server. StatusView can then be configured to set each workstation's internal clock to match the time server. Once configured, this clock synchronization occurs automatically every 24 hours, keeping all workstations time-synchronized, even if some systems have drifting real-time clocks.
| Description | Requirements | Features | Technical Stuff |
| Description | Demo | Download | Registration | Comments | Support |
Copyright © 1996-2003 by IDP Corporation