FAQ - General Issues

• STD*MIS Back-up Process
• Performance Issues

STD*MIS Back-up Process

Q1: What files should I include in a back-up of STD*MIS?

You really have three options for creating system back-ups for STD*MIS:

1. You can simply back-up all files in the STD*MIS directory. This is, of course, the safest way to accomplish the task. It, however, is the most time consuming and uses the most disk space.
2. The next option is to save three different file types (.DBF, .CDX, and .FPT).  This will provide you with a copy of all the data, index, and notes files you would need to restore STD*MIS.  You would have to first install a complete version of STD*MIS and then copy these files into the directory for your system to be completely restored.  
3. The final option is to save just two file types (.DBF and .FPT). Since you haven't saved the index files in this option, you will need to install a complete version of STD*MIS, copy these files into STD*MIS, and then reindex the entire system.

Any of the three options works fine, but you will need to make the decision locally to accommodate your particular program.  As always, your STD*MIS Support Person can assist you in making the most appropriate decision.

Q2: Can I compress the back-up to minimize the space it consumes on my computer, and what compression software do you suggest?

Yes; in fact, we suggest you do just that.  Actually compressing these files usually doesn't cause any problems.  However we suggest that you test your back-ups from time-to-time to assure that you haven't introduced any corruptions into the files.  We would like to add here, that you should consider placing you STD*MIS back-up in a place other than on the machine (server or desktop) where STD*MIS actually resides.  If your server or local hard drive fails, accessing both STD*MIS and the back-up may not be possible.  Assume that everything on the failed drive will be destroyed, so you will want to protect your system by having the back-up in a completely different location. 

We do not endorse the use of any one particular compression software.  However, many STD*MIS users have reported success with the use of WinZip and PKZIP.  Ultimately, it really depends on what you feel most comfortable with.

Q3: STD*MIS is on a server that is being backed-up every night, should I still make a copy of the system myself?

This is a local decision, but you should consider a couple of things before you make this decision:

1. How quickly can you have STD*MIS restored in the event of a non-network STD*MIS system failure?  In other words, if STD*MIS fails and is unrecoverable from a software standpoint, will the Network Administrator work quickly to get you a copy of STD*MIS from the last back-up?  If you can have the system restored in a reasonable amount of time (once again, your decision), then having the Network Administrator do the back-up may be a viable option.
2. Can you have the Network Administrator test the accurateness of the back-up on a regular basis?  It is recommended that you check the validity of your back-up on occasion to assure that minimal data loss occurs in the event of system failure. 

Back to Top

Performance Issues

Q1: What is the most common problem users have with STD*MIS?

Because of the complex relational database design in STD*MIS, satisfactory system performance relies on the use of many indexes of the data that are created by the application.  These indexes (there are 79 indexes in version 3.2) are sometimes susceptible to corruption.  The causes of these corruptions are difficult to diagnose and even more difficult to predict.  However, sometimes these corruptions are linked to computer hardware problems that result in the need to "re-boot" the system.  When indexes are not correct, the system may experience a number of unusual things, ranging from the inability of STD*MIS to run at all to an apparently functional system that seems to have incorrect event data for one or more patients.

To solve these corruption problems, CDC recommends that users re-index all data files on a regular basis.  The schedule for this will vary for each location, based on issues such as the number of users and the size of the databases, but a reasonable starting point should be once per week.  There are two ways in which you can re-index your data files. In the System Utilities menu you should select Re-index Data Files.  From here you should choose the data files you wish to re-index or depress CTRL-T to select all data files.  Alternatively, by going to a DOS prompt, accessing the directory where STD*MIS is installed and then typing "newcdx a", all files will be re-indexed automatically.

Q2: Why does it take STD*MIS so long to load the data files?

The basis of this question implies that you are running STD*MIS on a network. If you are not running STD*MIS on a network and you are experiencing long load times on a stand-alone system, contact your STD*MIS Support person for assistance.

If STD*MIS is running on a network and you feel that the load time is too slow, you should consider a few of possibilities that can speed up this load.  First, in a network environment, STD*MIS is having to struggle with other programs for limited network resources.  The files in STD*MIS are having to actually load onto a network client/remote machine from the server.  A product called Advantage Database Server will help alleviate this problem by allowing the application to run directly from the server.

A second reason for a slow STD*MIS load is in that your version of STD*MIS.EXE includes a line to look for the Advantage Database Server Software, but your network does not have Advantage loaded. The fix here is to download a file entitled SKIPADS.TXT into the subdirectory where STD*MIS is installed.

A third reason for slow performance in STD*MIS is related to the size of your reference files.  If you have thousands of Providers, Treatment options, Laboratories, etc. in your database, the download of these large files onto the remote machine could be the culprit.  A possible fix here is to allow STD*MIS remote sites to load the reference files directly from their machines.  See the user manual for instructions on how to do this.

Back to Top