 |
 |
 | |
 | |
 | |
 |
|
|
| |
| |
| |
|
Last updated: 3 Mar 2007 by XpertSS.com
MGood practices to reduce that chances of encountering problems
Last updated: 23 February 2007 by XpertSS.com
I. BACK UP YOUR FILES
Make backups of all of your application's files (.APR, .DBF, .ADX and .DBT and other types of database files you may use) regularly. How often you do this depends on how much work you want to do in reentering data that is not backed up. For some applications, once a week may be sufficient. For other applications, daily may be OK. For "critical" applications, you may want to consider a "mirror" backup method that some server software offers where files are continually backed up as changes are made.
Make sure your backup is "good". No one should be using your application during backup operations because the files that are "in use" may not be backed up, depending on your backup method or software. Check the backup to see if it will restore OK by restoring it to another computer or location and opening the APR files.
Make sure you have multiple "generations" of backups in case your most recent backup contains a problem you cannot fix. For example, for a daily backup situation, you could have backups for each day of the week and reuse them over the period of a week. At least one backup should be stored off-site just in case your office suffers a disaster and you need to continue operations elsewhere. Online storage facilities are also available that offer security and ease of access to backups.
Specific backup and online storage solutions will not be offered in this FAQ.
II. CLEAN UP YOUR HARD DRIVES
Most Windows applications, like Approach, create temporary work files in your designated temporary file folder. These files are usually of type .TMP or .~MP with a random name. When an application is closed, it should delete all of its temporary files, but this does not happen when the application does not close normally, when Windows itself crashes, or other interruptions occur. The problem is that a folder on your hard drive cannot contain an unlimited number of files. If this limit is reached, things do not work very well. Another problem specific to Approach is that those temporary files may be misinterpreted as current data files, causing various operational errors.
So you should regularly go into your systems (all user computers will have these) with all applications closed, find those files and delete them all. Note that holding down the Shift key when you press the Delete key bypasses the recycle bin!
o In older versions of Windows, these temporary files were usually in C:\TEMP or C:\WINDOWS\TEMP.
o In newer versions of Windows, these temporary files are stored in C:\Documents and Settings\username\Local Settings\Temp
Regular use of Scandisk and Defrag utilities will also make sure your hard drives are in good condition.
There are software packages that will clean up temporary files and perhaps even keep your "registry" clean, but those will not be offered in this FAQ.
III. SAVE YOUR WORK OFTEN WHEN DOING DESIGN WORK
When switching between design and browse frequently, get into the habit of periodically saving your work, then closing and reopening your application. This is especially important when modifying field definitions or joins, and when working with macros and scripts. Doing this will ensure that if something does go wrong you will lose the minimal amount of your work, and it also give Approach a chance to release system resources and refresh its links, indexes and graphics and start afresh.
Develop a practice of saving your APR file(s) such that you have at least 2-3 copies of the file saved with different names. I use something like Ordersdev001.apr, Orderdev002.apr, etc. for an APR that in production is named simply Orders.apr. During each restart of development per the above paragraph, copy the just closed APR file into another folder and rename the one you are working on. Keeping a log book of changes you are making is also a good practice, and you can note the APR names at the points in which you create them.
If you are a bit forgetful about periodically saving your work, then you may want to consider adding the following line to the current script you are working on so that your changes will be automatically saved each time you run the script (don't forget to remove it once you finished developing that script):
Current.Window.SaveChanges
The only caution about the above is that sometimes Approach appears to delete all of its scripts during testing them. And if you script does not run to completion, this statement will not be run. Therefore it is recommended that you not do this and instead merely use the script editor's File, Save Scripts after each change in them. This has the added advantage of recompiling your scripts and telling you if there are errors in them before you try another run.
IV. MINIMIZE PROBLEMS IF YOUR INDEXES ARE CORRUPTED NEED TO BE DELETED
When naming fields, long field names are easy to read, but if you ever need to delete your index files (.ADX) you will have a lot of work to do to update all of those names. Deleting the index reverts your field names to the dBase standard which is:
o Maximum of 10 characters
o Underscore, alphabetic and numeric characters only (no spaces)
o Must start with an alphabetic character
Therefore if you ever need to re-map the fields names after deleting your .ADX file, they will all match except for "time" type fields. Approach modifies the stored field name for this type so it can distinguish them from "text" fields because there is no "time" field type in dBase. For example, you have a time field named ORDERTIME which will be modified to ORDERTITM9 where the "TM9" tells Approach it is a "time" field. This is also a good reason to not use a field name that ends with "TM9".
Instead of deleting index files, it is recommended that you keep a set of those .ADX files that are current to the field definitions in use. Then if your .ADX is corrupted, you merely replace the bad one with your copy and update any serial numbered fields next number value. This will preserve your long field names too!
V. BATTERY BACKUP FOR YOUR USER COMPUTERS AND/OR SERVER
It is a good idea to have battery backup devices on the power for all of your computers (and monitors) that use Approach as well as your server, if any. This is good for your computer because it is protected from power surges and you will have some time to shut down the computers normally. The main problem with power failures is that any write operation in progress to the hard drive may end badly -- writing out only part of a file or writing over other files!
VI. MISCELLANEOUS
Never delete a macro or global script. Just rename ones you no longer need to something like zobs1, zobs2, etc and reuse them for new macros or scripts. Deleting them in most releases of Approach will modify the macro/script used in MESSAGE and RUN commands!
Don't type field or database names into formulas or text blocks. It is far more reliable to select them from the field name lists provided in field properties or in the Text Object, Insert, Field Value dialog. Apart from the possibility of making spelling mistakes, typing in field names can cause Approach odd behavior. For example, in a text block, a field may suddenly switch to a time format! (which may cause you to behave oddly...!)
If Approach starts "acting strange" when in Design mode, you may be experiencing a resource shortage. You should then exit all other Windows applications to free up memory and resources to stabilize things while you save your work. You can use the Windows Explorer to copy the APR file you are working on to another folder before you save the current version, just in case the current version is damaged in some way. Then restart the computer before continuing your development work.