Listed below are some common problems and their solutions. You can click on an item in the Contents to go directly to the related Article, or you can scroll down through all Articles.
For best results, allow this page to load completely before using the links in the Contents.
This list was last updated on Tuesday, 04-Feb-2003 22:31:36 EST.
Back to Troubleshooting ContentsIf you are having problems installing or using StatusView, you may be able to identify a particular remedy based on matching your problem to a specific article in this troubleshooting document. However, if you do not find a reference to your particular problem, you should consider the suggestions in the "General Troubleshooting" articles immediately following this one, which can be helpful in eliminating various potential problems. Note that most of these suggestions would be considered appropriate for troubleshooting almost any Windows application.
Use the "General Troubleshooting" suggestions and techniques to reduce the number of factors which may be causing problems. Implementing these recommendations may temporarily impact other applications you are using. However, once you have identified the specific cause of a problem, you can then restore your configuration to "normal", and proceed to rectify the problem in an appropriate manner, with minimal affect on other applications.
Back to Troubleshooting ContentsMake sure that you have done a clean install of StatusView, followed by a system reboot. Although a reboot is often not necessary, it is one of the easiest things to do when you are having unexplained problems.
To insure a "clean" install, begin by shutting down all other Windows applications, before starting the StatusView Server Setup. While this is often unnecessary, it is easy to do, and eliminates many potential problems. This is always good advice when installing any Windows application!
When the server setup is complete, shut Windows down and reboot your system. Again; this may not be necessary, but it certainly won't create a problem, and it may solve one.Follow the Server Setup with a Workstation Setup from the same machine. Before beginning, once again shut down any other Windows applications which may have automatically started with your system. Finally, when the Workstation Setup is complete, shut down and reboot the system one more time.
Once the system has restarted, proceed to run StatusView, and continue normally, if possible (i.e. do not shut down any other applications at this point). If you are able to do so, then you have verified that application-interaction was a problem only during software installation. When you go to run the StatusView Workstation Setup on other PC's in your office, be sure to shutdown all other applications first, to avoid further trouble.
Run StatusView by itself, to rule out any possible incompatibility with existing applications you may be running. In some situations, there may be a specific conflict with another program, while in others, excessive competition for inadequate Windows resources may be the culprit.Back to Troubleshooting ContentsTo do this, you can first try manually closing all running applications, and then starting StatusView. However, if the problem is one of incompatibility or limited resources, this technique may not improve the situation. For a more complete method of verifying this possibility, you must prevent other applications from starting with Windows.
Caution: The following techniques are intended to temporarily disable non-critical software components of a system, for the purposes of troubleshooting. Under normal circumstances, these changes should be fully reversible. However, if you are not familiar with the procedures described, and are not comfortable with the idea of reconfiguring your computer, we recommend that you enlist the assistance of someone who is more experienced. Improper maintenance of the system files described below may render a system unusable!
To prevent applications from starting automatically when Windows loads, use the following techniques:
- Remove all programs from your Startup Folder/Group:
For Windows 2000/NT4/98/95, right-click the Start button, then "Open" to display the "Programs" folder. Double- click on "Programs", which should show a list of folders, including the "StartUp" folder. To avoid losing your StartUp folder shortcuts, create a new folder called "Startup (inactive)" by using the "File" - "New" menu, then typing in the new folder name. Next, double-click on the original "StartUp" folder. Now drag each shortcut (including StatusView, if present) from the "StartUp" folder and drop it on the new folder you just created called "Startup (inactive)".
For other versions of Windows, open Program Manager, and use the "File" - "New" menu to create a new program group called "Startup (Inactive)". Next, double-click on the existing "Startup" group. Now drag each application icon (including StatusView, if present) from the "Startup" group and drop it on the new group you just created called "Startup (inactive)".
- Disable the "load" and "run" lines in your "WIN.INI" file:
Locate the file "WIN.INI" in Windows directory (this is usually C:\WINDOWS) using either Windows Explorer (Windows 95), or File Manager (other versions of Windows). Double- click on the file to open it in NOTEPAD, and look for the section titled "[Windows]". Under this section, look for lines beginning with either "load=" or "run=". If either is present, and one or more application files appear to the right of the "=" character, comment out that line by inserting a semicolon character at the beginning of the line. For example, here the "load" line has been commented out:
[Windows]
;load=c:\mouse\wbuttons.exe
run=
NullPort=None
.
.
.
- Check for non-critical device drivers or programs in the files CONFIG.SYS and AUTOEXEC.BAT:
Locate the files "CONFIG.SYS" and "AUTOEXEC.BAT" in the root directory of your boot drive (this is usually C:\) using either Windows Explorer (Windows 95), or File Manager (other versions of Windows). Double-click on the file (do one at a time!) to open it in NOTEPAD, and look for any non-essential drivers or applications which can be temporarily disabled. Comment out such items by inserting the text "REM" at the beginning of the line. You may wish to annotate these changes to make them easier to find later on when you wish to restore the system to the original configuration. For example, here is a part of an AUTOEXEC.BAT file with the SCANDISK utility disabled, and the change annotated with the text "SV TESTING":
@ECHO OFF
PROMPT $P$G
SET TEMP=C:\TMP
PATH C:\WINDOWS;C:\WINDOWS\COMMAND;C:\
REM (SV TESTING) SCANDISK /ALL /AUTO /NOSUMMARY
SET SOUND=C:\SB16
SET BLASTER=A220 I7 D1 H5 P330 T6
.
.
.
Finally, reboot the system, and verify that no applications are starting automatically. Now you can start StatusView manually by opening the "Startup (inactive)" folder or Program Manager group which you previously created, and choosing StatusView.
If StatusView works when no other applications are running, you can reverse the previous steps, one application at a time, until you determine where the conflict is. Note that in some cases, an application conflict can be resolved by changing the order in which applications are started.
Back to Troubleshooting ContentsUse the standard VGA video driver for whatever version of Windows you are running. To enhance video performance, resolution, etc., many systems are configured to run manufacturer-specific video drivers. In most cases, this does not cause problems. However, the are some situations where this does cause trouble. By using the standard Microsoft-supplied VGA driver, you virtually eliminate this possibility.
The specific steps required to change video drivers vary, depending on your Windows version. For most current Windows versions you access the "Display Properties" by right-clicking on the open Windows Desktop. For older versions of Windows, the video driver is usually configured by running the "Setup" icon, located in the "Main" Program Manager group. For troubleshooting purposes, be sure to select the standard VGA driver supplied by Microsoft with your Windows distribution, not a VGA driver supplied by your video card manufacturer.
Caution: Improper configuration of the video driver can disable your system. If you are uncertain about how to configure video drivers for your system, consult your Windows setup documentation, or contact your system supplier or video card manufacturer.
If using the standard VGA video driver fixes your StatusView problems, then you should contact the manufacturer of your video hardware to see if a newer version of your hardware-specific driver is available. Alternatively, you may wish to try other drivers which you may already have that may be compatible with your video hardware.
Back to Troubleshooting ContentsIf you are installing StatusView to a network server, and you suspect your problems may be network-related, run a new Server Setup and install it to your local hard drive. For example, the default directory offered by the installation program is "C:\SVServer". Next, run a Workstation Setup on the same system, and install the StatusView program itself onto the same local hard disk. The default directory for a Workstation Setup is: "C:\Program Files\IDP Corporation\StatusView" (for earlier releases of StatusView the default is "C:\SVClient").
Note: A local server installation of StatusView can also be helpful as an ongoing aid to StatusView administration. For more information, see article TRS00060.If you are able to run StatusView and setup the database on the local drive, you have verified that this machine can be used as a StatusView workstation. This should enable you to troubleshoot your network problems with greater confidence. The most common network problem is that users do not have full read and write permission for the StatusView server path directory.
Checking server path permissions:
You can check for the needed write access by opening Notepad, Word For Windows, or any other document editing program; and creating a new document. Just type in a few words, and they try to save the new file to the directory on the network server where you installed StatusView during the initial Server Setup. If you cannot save the file to this location, this indicates that you do not have the necessary write access to this directory.
Once you have StatusView working properly, you may still wish to retain a local copy of the server files. This can be a useful tool should you have
Back to Troubleshooting ContentsUse the standard network client driver for whatever version of Windows you are running. Some network operating system vendors supply client software to use when connecting to a server running their NOS. For example, Novell provides 32-bit client drivers for Windows 95 systems to connect to a Netware server. However, Microsoft includes its own drivers for connecting to Netware servers, bundled with the standard Windows 95 distribution. In some cases, the NOS-specific drivers supplied by the NOS vendor are not compatible with internal software features required by StatusView.
To rule out this incompatibility as a potential problem, remove the NOS-specific drivers and replace them by installing the standard Windows network drivers supplied with whatever version of Windows you are running. The exact technique for doing this varies, depending on which version of Windows you are using:
- For most current Windows versions, changes are made using the "Network" applet found under "Settings..." on the Start Menu.
- For older versions of Windows, the "Network" applet is found in "Control Panel", located in the "Main" Program Manager group by default.
See also: TRS00301
A corrupted single-file installation executable for StatusView can cause unpredictable and/or illogical errors during either the initial server setup, or following workstation setups. Unfortunately, InstallShield does not perform a complete integrity check on the installation file.Back to Troubleshooting ContentsThe CHECKSUM utility can be used to verify the integrity of your StatusView installation file.
If you would like to use the CHECKSUM utility, download the file TROUBLE.ZIP, which contains the utility, along with instructions.
Like all Windows applications, StatusView requires DLL's and other support files to operate. The InstallShield workstation setup program should place the needed files in the required locations on your local hard drive. However, if you are having problems with the workstation setup, you may wish to investigate the status of these support files manually.Back to Troubleshooting ContentsThe FILESCAN utility can be used to inventory the StatusView support files on your local hard disk.
If you would like to use the FILESCAN utility, download the file TROUBLE.ZIP, which contains the utility, along with instructions.
In a "live" StatusView installation, all workstations access and share the common database and other files located in the StatusView server path. Administrative operations (such as database optimization or maintenance of workgroups or status choices) can be performed only if the StatusView database is taken offline by performing a Global Shutdown. A shutdown may also be required at other times when troubleshooting.Back to Troubleshooting ContentsOccasionally, the StatusView administrator may wish to perform one or more such operations without inconveniencing (or interacting with) everyone else in the office. For example, the administrator may wish to investigate possible database corruption, view the contents of a StatusView database restored from backup, or create a new database from scratch.
While these operations can be performed against the live server path, doing so will require one or more office-wide StatusView shutdown/restart cycles. Doing so may cause confusion among the user community. If the issue is one of database corruption, it may be difficult or impossible to accomplish a StatusView shutdown normally.
As an aid to performing such procedures, the StatusView administrator may benefit by creating an offline server path which can be used without interacting with other "live" StatusView users. As the sole "user" connected to such an offline server path, administrative procedures can be performed without interacting with other users.
To create an offline server path, run the standard StatusView server setup and direct it to a suitable location. For example, the default installation path for a server setup is "C:\SVServer". By placing the server files on the administrator's local hard disk, procedures can be performed without depending upon the network or file server. As an alternate choice, the server setup could be directed to a location on the file server (other than the current, live StatusView server path, of course!).
Follow this server setup with a new workstation setup. Here again, direct it to install to an alternate location. For example, you might specify "C:\SVLocal". After the workstation setup is complete, you have several options:
- If you wish to troubleshoot your live database file for corruption, copy the file (svusers.mdb) from the live server path into the newly-created alternate server path. Then, run the alternate workstation program which will interact with the database file in this alternate server path.
- If you wish to view an alternate database file (perhaps from a tape backup), simply copy the file into the alternate server path and then run the alternate workstation program.
- If you wish to create a new database file from scratch, simply run the alternate workstation program and use the Configuration Assistant as instructed. If you already have a database file in the alternate server path but wish to create a completely new database file from scratch, simply remove the existing database file (svusers.mdb) by moving it to another folder, renaming it in place or deleting it. Then run the alternate StatusView workstation program and the Configuration Assistant will allow you to populate a new database file.
If you utilize the alternate server path to create or restore a database file which you wish to use in your live StatusView installation, perform the following steps:
- Shutdown the live StatusView installation
- Rename or move the existing database file (svusers.mdb) from the live server path
- Copy the alternate database file to the live server path
- Restart the live instance of StatusView
As suggested in this article, keeping this alternate set of workstation and server files on the administrator's workstation will provide a readily accessible environment in which to perform future testing and troubleshooting at a moment's notice.
Back to Troubleshooting Contents
International date format support has been added in the latest 32-bit release "C" of StatusView. This update is available to all registered and unregistered users at no charge.
StatusView versions prior to 2.305.6xxx do not support alternate date formats. Please see the information above about the new release "C".
This capability was considered during the design process, but the extra coding necessary to support alternate date and time formats was not added to the initial release in an attempt to keep costs down for the free Unregistered version of StatusView.
If the StatusView server path (and the database SVUSERS.MDB) is located on a Windows 3.1 system and StatusView reports problems with SHARE.EXE, note that SHARE must be properly loaded and configured to support file locking:Back to Troubleshooting Contents
- SHARE.EXE must be loaded when your system boots. One way to do this is to insert the following line in your AUTOEXEC.BAT file:
C:\DOS\SHARE.EXE /F:100
(This example assumes that SHARE.EXE is located in C:\DOS.)
If you are running 6.0 or above, you can load SHARE.EXE in your CONFIG.SYS file instead with a line like this:
INSTALL=C:\DOS\SHARE /F:100- The /F:## parameter specifies the number of concurrent locks. Start with /F:100. If necessary, keep increasing the value by 100 until StatusView no longer reports an error.
This problem has been traced to an error in Windows 95. Microsoft provides a detailed description and a fix for this bug. Refer to article Q139432 from the Microsoft Knowledge Base. Note that this problem is not corrected by the Windows 95 Service Pack 1.Back to Troubleshooting Contents
If you are running a Novell network and are having problems please refer to article Q109400 from the Microsoft Knowledge Base.Back to Troubleshooting Contents
This error occurs when running outdated 32-bit Novell Netware Client software under Windows 95. The error may not occur when only one copy of the StatusView program is running, but will prevent multiple users from connecting to the database at the same time. This error will also prevent the Administration Utility from loading when invoked from the "Office" menu of StatusView. There are two ways to correct this problem. Choose either one of the following methods:Back to Troubleshooting Contents
- Replace the Novell Client drivers with the standard Microsoft Windows 95 Network Client drivers:
- Under the Windows 95 Control Panel "Network" applet, remove the existing 32-bit Novell Netware client driver.
- Shutdown and restart the system.
- Under the Windows 95 Control Panel "Network" applet, add the Microsoft Client For Network driver. You must have your Windows 95 distribution (floppy disk or CDROM) available.
- Complete the procedure by rebooting the system.
- Update the Novell Client drivers with the latest version, available for download from Novell's web site at: http://www.novell.com.
Microsoft has tested and verified that Microsoft Access 2.0 can be supported under the NOS's listed above. (Note that Access version 7 for Windows 95 has only been tested under Microsoft networks and Novell, however, StatusView uses the Access 2.0 database engine for full 32 and 16-bit compatibility.) If you are using StatusView with any other NOS, including DEC Pathworks, Sun PC-NFS, IBM PC-LAN Server, or any other network not currently supported by Access 2.0, please read article Q109739 from the Microsoft Knowledge Base for details on how this could affect Microsoft Access databases.Back to Troubleshooting Contents
Back to Troubleshooting Contents
This problem has been corrected in the latest 32-bit release "C" of StatusView. This update is available to all registered and unregistered users at no charge.
These symptoms most often occur on systems which have Internet Explorer version 4 or above installed, or other recent Microsoft software titles such as Office 2000. In all reported cases, StatusView was stable on such systems prior to the installation of these Microsoft newer applications.
The two most common indications of the problem are:
- StatusView displays an error dialog (usually referring to a memory addressing error) and then shuts down. StatusView can be re-run and will usually work properly until a similar error occurs after minutes, hours or days.
- StatusView becomes unresponsive, and is in a state where it is consuming all of the available idle CPU resources as shown by the appropriate monitor utility. The user must use the Task Manager to "End Task" StatusView, after which the program can be re-run successfully.
This problem has been addressed in a new release of StatusView which is built with Visual Basic version 6. (The previous release was built with VB4.) This release also incorporates a few minor improvements related to date formatting (for international users) and optimization warning behaviors.
Back to Troubleshooting ContentsThis occurs when non-standard font sizes are selected as part of your system's Display Properties. In addition to distortion of the splash/About form, other effects can include displacement of toolbar buttons and truncation of some text items. In some cases StatusView may generate a runtime error "5" - invalid procedure call error.
To verify that you are experiencing this problem, right-click in an empty spot on the open Windows 95 desktop, then select "Properties" from the popup menu. This opens the "Display Properties" dialog. Select the "Settings" tab. View the setting under "Font size". The standard choice is "Small fonts" when running the standard VGA driver. If you are experiencing this problem, your system is most likely set to use "Large fonts".
You can choose to restore the "Small fonts" setting, or leave it unchanged. In most cases, the distortion caused by the non-standard fonts is cosmetic only, and does not diminish the functionality of StatusView. Note that this setting causes similar distortions to other Windows 95 applications.
See also: TRS00601 and TRS00610Back to Troubleshooting ContentsThe bandwidth (speed) of a dialup connection is insufficient to support a multi-user application like StatusView which uses an Access database. As a result, the use of StatusView over a dialup RAS connection is neither recommended nor supported.
For example, when a user on a remotely-connected StatusView workstation attempts to change their status, the database code running on the workstation begins to modify the contents of the database on the (host) server. While this operation is in progress, no other workstations can access the affected portions of the database. Since the remote workstation is connected at a (relatively) slow speed, the update operation ties up the database for an excessively long time. After waiting an appropriate interval to gain database access without success, local workstations begin reporting errors, since they believe that one or more workstations on the network are refusing to release locks on the database, and may be hung.
See also: TRS00600 and TRS00610Back to Troubleshooting ContentsThis problem can occur when one or more workstations running StatusView become hung or unresponsive.
StatusView is a client-side application, where the database code which connects to the shared database on the network server is actually running on each individual workstation. Each workstation is responsible for reading from and writing to the database file. StatusView uses a Access database, which is designed for this type of multi-user application. The database code which runs as part of StatusView is referred to as the "JET" engine.
As long as a workstation is running properly, the JET engine locks and unlocks the database as needed. However, if a particular workstation "hangs" due to an unexpected error in any application, or an error in Windows itself, the JET engine code may stop running. When this happens, the StatusView database can remain in a locked state indefinitely, preventing other workstations from accessing locked portions of the database.
There are several steps to try in recovering from such a situation:
- Locate the offending workstation(s), and manually restart it/them. For example, under Windows 95, try pressing <CTRL/ALT/DEL> to bring up the task list. You may be able to terminate an individual task which has become unresponsive. If so, we still recommend that you completely shutdown and restart the system. If you are unable to gain control with the <CTRL/ALT/DEL> method, then use the "reset" button or simply turn the power off, then back on, in order to restart the computer. Pressing the "reset" button or turning the power off can cause file and/or disk corruption. Before using either of these techniques, you should first make every effort to insure that all open files have been closed in any running applications. In addition, you should always use SCANDISK or CHKDSK to verify the integrity of your disk(s) after restarting the system.
- If the previous method does not restore normal StatusView operation, or if you can not use it (for example, the workstation which is hung is in a locked office to which you do not have access), then you can use a network administration command to disconnect the offending workstation(s) from the server. As an alternative, you can reboot the server. Before rebooting a server, you should make every effort to insure that all users have closed any open files in any application using the server. CAUTION: Operations such as disconnecting a logical network connection and/or rebooting a server can cause file corruption and permanent data loss. Do not use these techniques unless you know what you are doing, or unless you have no other option.
See also: TRS00600 and TRS00601Back to Troubleshooting ContentsStatusView database optimization is performed by the Administration Utility, which requires exclusive access to the database file (SVUSERS.MDB). Therefore, before an optimization can begin, all instances of StatusView which are active and have an open connection to the database file must first be closed. This is the purpose of a StatusView Global Shutdown.
Both manual and automatic (scheduled) optimizations begin with a Global Shutdown, which is asserted from the Administration Utility. The Administration Utility sets a flag in the database file (SVUSERS.MDB) which informs all running instances of StatusView of the need to close their open database connections. Within approximately five minutes, each working instance of StatusView should detect this flag and then release the database. StatusView then reverts into an offline "polling" state, showing the splash screen and a brief explanatory message about the reason for the shutdown.
This process requires that each and every instance of StatusView close its database connection. If any system does not do so, the Global Shutdown will fail. If the shutdown is being performed in preparation for a database optimization, then the optimization will also fail.
The most common cause of a shutdown failure is an "ill-behaved" workstation which is not allowing StatusView to run normally. This can be caused by a "frozen" system (corrupted or unstable Windows environment) or one which has become extremely sluggish.
Some possible causes of an "ill-behaved" workstation:
- A graphically-active screen saver which blocks all background tasks from running when it is active.
- An older DOS application running in a command window which, when active, severely impacts all running Windows applications.
- Unusual hardware activity which causes the system to be sluggish (example: printing to an LPT port can cause such problems with certain printer drivers).
- Leaving a system in an unusual "modal" state where background tasks are not allowed to run normally (example: when the gray "shutdown screen" is visible while Windows 95/98 waits for the user to confirm a system shutdown).
For more information, please search the StatusView help file for "shutdown failures". If you experience repeated shutdown failures, we recommend that you use the appropriate utility for your network server to identify the system(s) which are causing the problem, and attempt to identify and rectify the condition which is preventing the StatusView application from executing normally on that system.
Back to Troubleshooting ContentsTo prevent unnecessary optimization runs, StatusView will not perform a scheduled optimization if it has been less than 24 hours since the last optimization. In addition, a scheduled optimization will not be performed if the last optimization was run at a date in the future. Under normal circumstances this should never be the case. However, if the system clock on the designated (scheduled optimization) workstation is set to a future date, this will cause any optimizations performed to be date-stamped with that future date. As long as the clock on this system is allowed to advance "normally" through successive future dates, it will continue to initiate optimization runs every 24 hours. However, if the system clock on this system is reset to the correct date, no further optimizations will be initiated until the "future" date on which the last scheduled optimization was performed has been passed. This behavior can not be altered by initiating a manual optimization with the clock properly set, because the optimization date is recorded differently for automatic vs. manual optimizations.
To restore normal scheduled optimizations, use either one of the strategies described following. In either case, to prevent possible reoccurrence of the same problem, be sure that all system clocks are set to the current date before proceeding:
- Create a new StatusView database using the following procedure. Note, however, that all existing information will be lost, including user names, passwords (if security features are enabled), preferences and messages (if message features are enabled); workgroup names; system settings; and status choice customizations (if any).
- Perform a StatusView Global Shutdown using the Administration Utility.
- Close the Administration Utility, but do not restart StatusView. You can leave shutdown copies of StatusView running, including the one on your own desktop.
- Using Windows Explorer, take the existing StatusView database (SVUSERS.MDB, located on the file server in the StatusView Server Path) out-of-service by renaming it. For example, rename the file to "SVUser.old".
- Restart StatusView by clicking the "Start" button in the StatusView shutdown "splash" screen. If you have already closed the StatusView program itself, re-run it from your Start Menu.
- The Administration Utility should load automatically in the "Configuration Assistant" mode, prompting you to create a new StatusView database. Enter your license information, workgroups, users, desired optimization schedule, etc. as prompted.
- When you "Finish" the Configuration Assistant procedure, you will have a new database which no longer remembers the original (future) optimization date. Automatic optimization should once again run normally at the designated time.
- Send your StatusView database to IDP Corporation for repair. You can submit your database file (SVUSERS.MDB) via email to:
repair@idpcorp.comBe sure to indicate the reason that you are returning your database. Note that once you receive your returned database from IDP Corporation, you will need to perform a StatusView Global Shutdown and then replace your existing "live" database with the copy returned to you. This will cause all status changes, messages, user preference settings, etc., which were entered since the database was sent to IDP Corporation to be lost. In most cases we will return your database within one business day.
To prevent errors which result from incorrectly set system clocks you may be able to use StatusView's clock synchronization feature. Search the StatusView online help for "clock synchronization" for more information.
Back to Troubleshooting ContentsStatusView issues a warning if the database file has not been optimized within the past 10 days. This message will remain until you delete it.
Please see this FAQ article: FAQ00700
Back to Troubleshooting Contents
This problem has been corrected in release "B" of StatusView, which is now available for download. Consult the updated README.TXT for update installation instructions.
This error occurs when the affected workstation sees the StatusView server path as a "root" directory. This problem exists in 16-bit StatusView 2.3, build 1050 and earlier. Note that the 32-bit version of StatusView does not have this problem.
This problem will be corrected in the next production build. (ETA for this new build is projected to be the week of 2/10/97.) Current users can work around this problem by making a simple directory - share change so that the server path as defined in the StatusView Workstation Preferences dialog includes a directory name.
For example, suppose you performed the StatusView server setup to the directory "C:\SVSERVER" on your network server. You then created a share name for this specific directory called "SVSERVER", so that workstations could map a drive letter to this shared directory.
Next, you configured one or more workstations to map the drive letter "S:" to the resource name "SVSERVER" on the server machine. This would result in a StatusView server path (seen in the Workstation Preferences dialog under the Office menu) of "S:" or "S:\". The 16-bit version of StatusView will fail with this server path.
To correct this problem, create a new directory on the server, and move the existing StatusView directory and all of its contents into it. Reconfigure the server to share the new directory. Finally, redefine the server path on each workstation to include the drive letter and the directory name.
In the case of the example given above, here is a step-by-step procedure:
- Shut down any running instances of StatusView. Disconnect the "S:" mapped connection to the server's "SVSERVER" resource.
- On the server, un-share the current "SVSERVER" directory.
- On the server, create a new directory called "SVSHARED".
- Share the new directory "SVSHARED" with the resource name "SVSHARED".
- Move the original directory "SVSERVER" and all of its contents into "SVSHARED".
- Go to each workstation and do the following:
- Map the "S:" drive to the "SVSHARED" resource on the network server.
- Run StatusView. The splash screen will indicate that StatusView is unable to connect to the database.
- Click the "Configure" button, which opens the Workstation Preferences dialog.
- Enter the new server path, which is "S:\SVSERVER". Note that you must un-check the locked setting to change the server path.
- Select "OK", and StatusView should restart successfully.
Back to Troubleshooting Contents
This problem has been corrected in release "B" of StatusView, which is now available for download. Consult the updated README.TXT for update installation instructions. Note that to correct this specific problem, you must run a new Workstation Setup on any affected systems. This is not normally required for StatusView updates.If you are experiencing this problem, and performing a Workstation Setup from the "B" release does not correct it, please notify us via email to support@idpcorp.com, even if you are not a registered StatusView user.
Some sites have reported this error, which appears to occur when certain combinations of software have been installed on the affected workstation in addition to StatusView. Most such sites report StatusView working properly on other workstations. This problem appears to exist only in 32-bit StatusView 2.3, builds 1040 and 1050.
We have been unable to recreate this problem on any test system. However, we are analyzing system configuration information from several customer sites. Based on the information gathered, we believe we are close to a permanent solution, and anticipate correcting this problem in the next production build. (ETA for this new build is projected to be the week of 2/10/97.)
Based on reports from sites experiencing this error, current users can work around this problem by installing Access for Windows 95. In some cases, removing and then re-installing Access for Windows 95 has been done. However, please note the following:
- Although StatusView uses an Access database for data storage, Access is not required in order to use StatusView.
- Installing Access for Windows 95 has been reported as a work around to this specific problem. If you have this software available, you may choose to install it for this purpose.
- Since we have not been able to recreate this problem on any of our test systems, we are unable to verify the described work around ourselves! However, the few sites reporting installation of the versions of Access described above all report success in running StatusView on the affected workstation.
Once the production build of 32-bit StatusView is available with this specific error corrected, we will contact all users who have reported this problem. In addition, we will attempt to notify all users (including unregistered users) who have downloaded the affected builds of StatusView, even if we have not heard from you.
If you are experiencing this problem, and would like to receive notification of the permanent solution as soon as possible, please send email to support@idpcorp.com with a subject of "32-bit Access Error", requesting notification of the next production build of StatusView. Be sure to include your contact information (email address, phone, and fax), as well as any comments you would like to add.
Back to Troubleshooting ContentsThis error indicates that the StatusView database file (SVUSERS.MDB) has become corrupted. Note that some types of database corruption may be corrected automatically by StatusView's built-in optimization and repair capability. However, error 3343 indicates a more severe level of corruption which cannot be repaired by StatusView. Some of the most common causes of database corruption are:
- Improper workstation shutdown - Turning the power off on a workstation before closing the StatusView application can cause database corruption. One example of how this might happen under Windows 95 and Windows NT involves the Windows "shutdown" option under the Start Menu. When "shutdown" is chosen, Windows displays a final confirmation dialog. If a user is in a hurry and forgets to answer "Yes" to this confirmation dialog, the orderly shutdown will not proceed. If the user then turns off the power, it is likely that open files may be corrupted.
- Corrupted Windows environment - Occasionally a Windows system will cease to function normally. In some cases the Windows environment will become extremely sluggish, while in other cases it will become completely frozen. In such cases, Windows applications are unable to run normally (or at all). If StatusView is running on such a system, it can corrupt the database.
- "Poorly behaved" screen saver - This is a special (but all-too-common) case. When a screen saver becomes active (after a workstation has been idle), it runs just like any other Windows application. However, some screen savers (particularly ones which are graphically-active, but sometimes even those which are not) are written in such a way that they assume that no other applications will need to run while the saver itself is active. These screen savers can take up to 100% of the systems CPU resources, giving little or no CPU time to any of the other Windows applications which are now running in the "background".
If StatusView is one of the background applications in such a scenario, then it will be unable to interact properly with the shared database file. This instance of StatusView will be unable to assert and release database locks in a timely manner. In turn, this can cause other StatusView workstations to wait an excessive time to gain database access, and appear to be sluggish. Eventually, a user may choose to "End Task" on an instance of StatusView which appears to be not responding properly. This can corrupt the database file.
- Improper server shutdown - Shutting down and/or rebooting a network server on which the StatusView database resides while one or more workstations are still running StatusView can cause database corruption. All instances of StatusView running on workstations must be shutdown before the network server is taken offline. This can be done centrally by an administrator using StatusView's built-in Global Shutdown.
If you have a corrupted database there are several recovery methods from which to choose depending upon the particulars of your situation:
- If you have version 2.305.6054 of StatusView, you may be able to use the StatusView Administration Utility to repair the database automatically. See this page for a description of the automated repair procedure.
- If you have an earlier version of StatusView, you may be able to repair the database using Microsoft Access, if available. Note that the StatusView database file (SVUSERS.MDB) is both secure and encrypted, so it cannot be opened and maintained directly with Access. However, Access can be used to repair such a database in some circumstances.
- The actual repair procedure with MS Access is quite simple. Do not attempt to open the database file. Instead, look for the "repair" option, located under the Access "File" or "Tools" menu, depending on which version of Access you have. Note that Access 2.0 or higher is required to repair the standard format database which is compatible with both 32 and 16-bit versions of the StatusView application. If you are using the newer JET 3.0-format StatusView database, Access 7.0 for Windows 95 or above is required.
- If the repair is successful, you should once again be able to run StatusView with the repaired database. Caution: In some circumstances, even though repairs appear to have been successful, it is possible that the database may have become permanently damaged. If you no longer receive the "Error 3343", but are still experiencing unexpected or erratic behavior with the repaired database, then the repairs were not completely successful.
If repairs are not successful or you do not have MS Access, there are three remaining recovery options:
- Restore the online backup copy of the StatusView database. This file is named "SVUSERS.BAK", and is located in the server directory along with the primary database file "SVUSERS.MDB". The backup file is recreated every time that a StatusView optimization is performed, whether manually or automatically. To use the backup file, perform the following steps:
- Insure that there are no running instances of StatusView on any workstations.
- Rename the corrupted file "SVUSERS.MDB" to an unused name such as "SVUSERS.BAD". Although this file appears to be unusable, you should save it as a precaution.
- Make a copy of the backup file "SVUSERS.BAK", and name it "SVUSERS.MDB".
- Restart the StatusView application.
Note that any user, status or message entries or changes made since the backup database file was created will be lost.
- Restore an offline copy of the StatusView database. If you perform regular server backups to tape or other media, then you may have a backup copy of the database that you can restore. However, note that in most circumstances, the StatusView database is opened by at least one workstation at all times. Therefore, it is likely that your regular server backup is NOT copying the live database "SVUSERS.MDB". However, the online backup file "SVUSERS.BAK" should always be available for backup. Use a procedure similar to that suggested above, but substitute a backup database file which you restore from your backup media.
- Reinitialize the StatusView database. If you are unable to recover the StatusView database by any other method, you can create a new database from scratch. Obviously, no user, status or message information will be retained in this case. To initialize a new database, perform the following steps:
- Insure that there are no running instances of StatusView on any workstations.
- Rename the corrupted file "SVUSERS.MDB" to an unused name such as "SVUSERS.BAD". Although this file appears to be unusable, you should save it as a precaution.
- Check for the existence of the file "SHUTDOWN.NET" in the StatusView server directory, and delete it if it does exist.
- Start the StatusView application. The Administration Utility should load with the Configuration Assistant visible, just as it did when you first installed StatusView.
- Proceed to enter the required information, including your Licensee Name and Product ID if you have a Registered StatusView license.
Once you have successfully created a new database, you should inform users that they will need to re-specify their personal settings under "User Preferences". You may wish to use the System Message feature of StatusView to do so.
Back to Troubleshooting ContentsThis error indicates that the security database file "SV.MDA" is corrupted. This file is located in the StatusView server path and must be present for StatusView to function.
To recover this file, perform the following steps:
- Make sure that there are no running instances of StatusView on any workstations.
- Using Windows Explorer (or File Manager for older versions of Windows), remove the existing (corrupted) "SV.MDA" file from the StatusView server path. If the file "SV.LDB" is present, you should remove it as well. This "lock database" file will be recreated automatically by Access when you next run StatusView.
- Re-run the StatusView Server Setup, directing it to the existing server path location. This will create a fresh copy of the "SV.MDA" file.
You should now be able to run StatusView normally.
Back to Troubleshooting ContentsThis error can be caused by employing either long filenames or UNC path names (Universal Naming Convention) in your StatusView installation:
- Long filenames - Under Windows 95 and later versions of Windows you can specify file or path names which do not conform to the older "8.3" file name standards. Versions of StatusView prior to Release "C" (version 2.305.6054) do not fully support these long file/folder names - this limitation does NOT apply to the current Release "C" (version 2.305.6054) or any later releases.
Some examples:
"C:\Program Files\SVClient" is a long filename path (do NOT use)
"C:\Programs\SVClient" is an "8.3"-compliant path (DO use!)
"C:\SVClient" is another "8.3"-compliant path which can be used
- UNC path names - When accessing a network drive from a workstation, it is possible to specify the desired shared directory on the server by using both the machine name and the resource name. This way of specifying a directory on a remote server is called "Universal Naming Convention". StatusView does NOT support UNC path names.
Some examples:
"\\MyServer\Public\SVServer" is a UNC-format path (do NOT use)
"S:\SVServer" is a drive-mapped path (DO use!)
Back to Troubleshooting ContentsThis message normally indicates that the file server which is referenced by the StatusView server path is not online. You may also receive this error if the drive letter mapping to the server path has been lost or the server path has been defined as a UNC path name, or if file/network security permission settings do not permit full read/write/delete access to the server path from your workstation. However, if you receive this message when the server is known to be online and the drive letter mapping is valid with the required permissions, then there may be an alternate explanation.
For more information about drive letter mapping and UNC path names see this paragraph in the article TRS01000.
For more information about checking permissions see this paragraph in the article TRS00014.
StatusView identifies the proper server path location by looking for the file "SVUSERS.NEW". This file must be present at all times for StatusView to function properly. If this file is deleted from the server path, the error message described in this article will appear, even if the server path is, in fact, accessible.
If you have inadvertently deleted this file it can be restored by re-running the StatusView Server Setup and directing it to the existing server path. Before doing so you should make sure that users are not running StatusView.
Note to registered users: If you have previously installed the JET 3.0 database upgrade according to the supplied instructions, you should use an alternate procedure to recover the "SVUSERS.NEW" file. Re-running the StatusView Server Setup will NOT restore the required version of this file. (It will restore the original JET 2.5 version). If the file "SVUSERS.J30" is present in the server path, you can simply copy this file and rename the copy to "SVUSERS.NEW". Unlike the running of a Server Setup, this can be done without affecting any instances of StatusView which may already be running. If you do not have the "J30" file, please contact technical support for a replacement file.
Back to Troubleshooting ContentsThis message indicates that StatusView does not have the required access permissions to the StatusView server path and the files it contains.
StatusView must have full read/write/delete access to the server path folder and its contents.
The method used to control this access varies depending upon the type of file server used, as well as how it is configured. For example, if you are using a Windows 2000 or Windows NT file server with NFS disk partitions, then access is controlled by two mechanisms:
- User and/or group-based access permissions defined for the files and folders on the server itself.
- User and/or group-based access permissions defined for the shared resource name by which remote workstations make their mapped drive-letter connection to the file server.
In the case of the example above, both sets of permissions must be properly configured or StatusView will not connect to its database successfully.
You can check for the needed write access by opening Notepad, MS Word, or any other document editing program and creating a new document. Just type in a few words, and they try to save the new document file to the StatusView server path directory. After saving the file, you should then deleted it. If you cannot both save and delete the file to/from the server path, this confirms that you do not have the permissions that StatusView requires to operate properly.
Back to Troubleshooting ContentsEach time StatusView loads on a client workstation, a check is performed to determine if a newer version of StatusView executable file is available. If so, this new file is copied down to the workstation, replacing the previous one. Upon completion of the copy operation, the new executable file is loaded and StatusView operation continues normally.
Under some conditions this automated feature may either:
- Attempt to perform a legitimate update but fail to do so.
- Indicate that an update is needed when, in fact, it is not.
The automated update feature works by comparing the executable file on the user's workstation to a master reference file on the file server (located in the StatusView server path). These files are named as follows:
Version Executable File
(on workstation)Reference File(on server) 2.3c StatusView.exe StatusView.new 32-bit versions prior to 2.3c SV32.exe SV32.new 16-bit versions SV16.exe SV16.new If you are experiencing problems related to the automated update feature of StatusView, please check for the following possible causes:
- StatusView may fail to update the local workstation's executable file if it has been given the read only file attribute. Use Windows Explorer to view the properties for this file - if Read Only is checked, un-check it.
- StatusView may attempt to perform an update when no new version is available and may also repeatedly attempt to perform this "phantom" update without ever allowing the program to load properly. This may indicate that the reference file on the server has been tampered with or is in use by some (improper) application. Check to see if the reference file is in use by viewing open files using the appropriate utility on your file server. As an alternative, temporarily rename the reference file (be sure to restore the original file name promptly if you are successful). If you are unable to do so, this indicates that the file is in use and locked by another user/system. This lock must be released to restore proper operation.
Back to Troubleshooting ContentsThis error may indicate that you have one or more empty workgroups.
To avoid this error, make sure that each workgroup has at least one user defined in it. Workgroups can be added and removed only from within the Administration Utility, and only while StatusView is in a shutdown state. We recommend that you make at least one user a member of each new workgroup as you add workgroups in the Administration Utility. This will prevent any users from receiving the aforementioned error when StatusView is started.
Back to Troubleshooting ContentsThis error usually indicates that the Administration Utility executable file itself has become corrupted. A single copy of the file "svadmin.exe" is located on the server in the StatusView server path, and is shared by all StatusView administrators, regardless of which workstation they are using.
To recover this file, use the following procedure:
- Run the original StatusView Server Setup, but direct it to an location other than the current server path. For example, you might accept the default of "C:\SVServer".
- Locate the "svadmin.exe" file in this newly-created folder and copy it to the "live" server path location, overwriting the existing file.
Once you have successfully replaced the bad file, the Administration Utility should once again function normally.
Back to Troubleshooting ContentsThis error can be caused by an incompatible date format setting as defined in the "Regional" applet under the Windows Control Panel. StatusView supports numerous common date formats, allowing international users to view dates within StatusView in formats other than the US standard "mm/dd/yy" format. However. some unusual date formats can cause this error.
If you are experiencing this error, open the "Regional" applet in Control Panel and review your date format setting. (If you have some workstations that are not experiencing this error, compare date formats on these systems with the system(s) that are experiencing this error.) You should be able to switch to an alternate format that will correct the error.
| Description | Demo | Download | Registration | Comments | Support |
Copyright © 1996-2002 by IDP Corporation