@ME.FORMAT                                                             R                                                   
ASCII FILE WITH cr/lfs included.

     ********************************************************************
     *                                                                  *
     *   CONDITIONS FOR THE USE AND DISTRIBUTION OF THE DISCUSSION ON   *
     *   PROCEDURES TO HANDLE CORRUPTED TABLES AND THEIR FAMILIES IN    *
     *   PARADOX : CONTAINED IN THE FILE DISTRIBUTED AS CORFIX.TXT BY   *
     *   THE AUTHOR N F WHITE.                                          *
     *                                                                  *
     *   The discussion on the above subject, contained in the file     *
     *   called CORFIX.TXT as supplied by the author, and referred to   *
     *   as the article from hereon, is written and provided for use    *
     *   with the following provisions:                                 *
     *                                                                  *
     *   (1) Anything written in the article is provided on the basis   *
     *   that no responsibility is taken by the author for any          *
     *   consequences that may arise from the use of the advice that is *
     *   given.                                                         *
     *                                                                  *
     *   (2) The article may be copied for distribution to others, with *
     *   alterations if it is felt necessary.  However, if the author's *
     *   connection to the copied material is in any way made apparent  *
     *   to anyone who receives or is likely to receive any part of the *
     *   article, it must be copied in full and distributed with these  *
     *   conditions including waiver of responsibility by the author.   *
     *                                                                  *
     *   (3) If the article is quoted, in full or in part, with or      *
     *   without alterations, such that any responsibility could be     *
     *   attached to the author for the results of the use of the       *
     *   article, then the statement shown in part (1) of these         *
     *   conditions, voiding any responsibility on the part of the      *
     *   author, should be made clear to any person who may have the    *
     *   article quoted to them.                                        *
     *                                                                  *
     *   (4) The material in the article may be freely used, and        *
     *   distributed or quoted in accordance with the above provisions. *
     *                                                                  *
     *                                                                  *
     *  N.F.White                                                       *
     *  8.October1993                                                   *
     ********************************************************************


	PROCEDURES TO PREVENT AND HANDLE CORRUPTED TABLES IN PARADOX

	This discussion is an attempt to organise the things that I
	have picked up during my experiences with corrupted tables,
	and from correspondence between myself and others with helpers
	on Compuserve\PDOXWIN, into a single statement.

	I have been driven almost to distraction by data corruption
	problems on a couple of systems, especially where a lot of
	query/add was used for data transfer, and my image of myself
	as a developer, and that of Paradox, has been severely
	tarnished, whether this is justified or not in either case.

        When I have had these problems, it was a such slow and painful
	process to find out all the possibilities, by experiment and
        asking, that this in one case overshadowed the writing of the
        actual application. So I am trying to point everywhere at
        once, in the hope that it may help someone else.

	My qualifications to write this article are only bitter
	experience. I had no part in designing any of the proprietary
	software named here, and I have put this information together
	only by asking and observing.

	Quote me, and use the ideas, at your own risk.

	The article should only be distributed under the conditions
	stated at the beginning of this document as it was distributed
	by the author.

	I apologise for the heavy "no responsibility" approach, but I
	have found that this area is muddy of water and quick of sand,
	and I cannot guarantee that anything I say will work.

	Sounds encouraging? It's part of the advice for the article.

	The article is long. There's a lot to discuss. Please read it
	all before you try any of it, or we'll both be wasting our
	time.

	Please also read carefully all documentation for TUTILITY and
	any other repair etc utilities that you may use during the
	fixup.

	If you try any of it and it doesn't work, or you disagree with
	any of the techniques presnted, please let me know, as I am
	wanting to learn, and do not want to mislead other more than
	is necessary.

	The article is not indexed or laid out book form, but the
	following braod categories have been used, in order as shown.

        PROBLEMS WITH CORRUPTION.

	SIGNS OF TABLE CORRUPTION

	REASONS FOR TABLE CORRUPTION.
		PREVENTING RECURRENCE.
                    - VIRUSES
                    - EXISTING CORRUPTION
                    - SOFTWARE CONFLICTS AND MISBEHAVIOUR
                    - FIXES
                    - POWER SUPPLY (MAINS) GLITCHES
                        Spikes
                        Surges
                        Brownouts
                        Blackouts
                    - EFFECTS OF THE ABOVE POWER PROBLEMS
                    - FIXES FOR THESE
                    - MACHINE PROBLEMS
                        - Hardware/File Condition
                        - Hardware/File Condition
                        - Actual Hardware Collapse
                    - FIXES

	REMOVING TABLE CORRUPTION
		(1) RESTRUCTURE
		(2) TUTILITY
		(2) EXPORT TO ASCII AND REIMPORT
		(3) SIMPLY RECALL THE TABLE(S) FROM A BACKUP, AND HOPE
		YOU'VE GOT A CLEAN VERSION.
		TO SUMMARISE corruption fixes:

                TO SUMMARISE THE WHOLE OPERATION:





        +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

        PART 1
        PROBLEMS WITH CORRUPTION.

	The problem with table corruption is you can NEVER prove that
	you've fixed it, only demonstrate that you haven't.

	Corruption in data within Paradox can have repercussions
	depending upon the nature of your application.

	If you have a flat file system (one wide file with no links or
	lookups etc) then you will not damage any other data, as long
	as you have NEVER copied (either as a table or at record
	level), added or created/borrowed structure with the suspect
	table as a source. You have of course got damaged data in the
	flat file.

	In a linked or "relational" system, you can spread the problem
	all over the place, again by copying, adding or creating new
	records by array copy etc. The use of linked forms may
	transfer corruption, because the linked table is automatically
	updated by the parent table with each new record. I am not
	sure of the mechanism here.

	So corruption can spread throughout an active system,
	gradually growing like a virus.

	Like a virus, corruption may not show itself until it is very
	advanced and entrenched. The problem is, by this time, all
	your backups may also be corrupted, no matter how careful you
	may have been.

	The further it gets, the harder it is to get rid of, and the
	more data you could lose.


        +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

        PART 2
	SIGNS OF TABLE CORRUPTION

	The signs that I have seen of data corruption are:

            - system locks up during a query, locate or zoom

            - scrolling or paging down through the table produces
            results that are unexpected

                    - records disappearing or out of order

            - a table will lose its key(s), or lose the links with
            these

                    - they may still exist in DOS, but Paradox has
                    spat the dummy

                    - this can also result in linked forms falling
                    to pieces, due to the links being broken

                            - "linked table XXXX is expected to be
                            keyed on Y fields"

            - a table will lose its family item(s), or lose the
            links with these

                    - they may still exist in DOS, but Paradox has
                    spat the dummy

            - strange things start happening to links between
            master and child tables on forms

                    - non-matching records appearing on child

            - queries present strange results

                    - data that was put in to a record does not
                    reappear at next viewing.

                            - may also be caused by loss of table
                            keys, so that another record is
                            created, leaving two in the table

            - table cannot be viewed

                    - either a script crash or
                    error message interactive

                    - this is pretty
                    extreme

            - TUTILITY indicates a corrupted table

                    - {Verify} apparently misses quite a bit of
                    corruption. I have both experinced and been
                    told of this.

            - This list is probably not exhaustive. ANY strange
            behaviour should result in IMMEDIATE diagnosis and
            repair. The quicker you get it, the better. If anyone
            knows any others, please tell me.


        +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

	PART 3

	REASONS FOR TABLE CORRUPTION.

		PREVENTING RECURRENCE.

	The two steps to eliminating data corruption are :

            (1) Get rid of the cause

            (2) Get rid of the corruption

                    See PART 4 REMOVING DATA CORRUPTION

            Note: It is arguable whether you should get rid of the
            corruption, and hope the cause was a "once-off", or
            try to ascertain the cause immediately, fix it , and
            then fix the corruption. This depends entirely on how
            much disruption you can allow now, against how much
            disruption you may have to allow later.

            -The main causes of data corruption are:

            - VIRUSES

                    - Run a virus checker over the machine

            - EXISTING CORRUPTION

                    - Sometimes (I dare to say often, from my
                    experience) the repeated corruption can be
                    caused by existing corruption. In the case of
                    Paradox, TUTILITY, that much-touted (very
                    useful) cleanup utility, is acknowledged to be
                    only medium-reliable in picking up corruption.
                    In the 4.0 version it is very good (but not
                    perfect) at repairing data that has been
                    damaged. The point here is that even though
                    you may have cleaned up the data, it may not
                    be clean. You may have to end up recalling
                    from backup (WHICH OF COURSE YOU HAVE
                    METICULOUSLY KEPT!) and it may require that
                    you go back some way to get truly clean data.
                    Your backups may not be clean, as the
                    corruption may have been there for a while.

                            - As far as I can tell, this is
                            running at about 5% of corruption
                            cases with PDOX4.0 TUTILITY.

                    - Remember that if you import data to, say
                    Paradox from an ASCII file or from someone
                    else's system, you MAY import corruption, so
                    bear this in mind when diagnosing.


            SOFTWARE CONFLICTS AND MISBEHAVIOUR

                    - Here we have some real quagmire material.

                    - Again, with Windows being used more and
                    more, either for Windows programmes, or as a
                    DOS multi-tasker, and with more and more
                    networking and other memory-resident software
                    being held in memory and vying for memory
                    allocation, with minimal standards, we quite
                    often strike problems. These can be subtle or
                    dramatic. Some will just damage your data, and
                    some will lock your computer, causing you to
                    hit the reset button.

                    FIXES

                    - To check for software conflicts, the only
                    way is to:

                            - gradually remove TSR's etc until the
                            problem goes away

                                    - less inconvenient, but
                                    riskier. You'll maybe keep
                                    losing data.

                            - remove all TSR's etc that you can do
                            without (be harsh here) and when you
                            THINK the problem has not recurred
                            (for twice as long as your best
                            problem-free time since it started)
                            start putting them back again, one at
                            a time, and testing again. This one
                            includes not using Windows as a DOS
                            task swapper.

                    - If one particular piece of software keeps
                    corrupting data which you are sure is ok in
                    the first place, then try reinstalling the
                    software. It may well be corrupt itself. If it
                    keeps doing it, change brands!

                    - If you have an upper memory or EMS manager,
                    exclude the video range (usually B000-C7FF
                    takes care of it (quote)).

                    - If you find that a particular piece of
                    software causes problems, (such as a TSR that
                    always clashes with other programmes) and you
                    have to have it, tell the software
                    manufacturer(s) concerned (and they're often
                    not very), and good luck to you.


            POWER SUPPLY (MAINS) GLITCHES

                    - spikes, surges, brownouts, dropouts,
                    blackouts, surges

                    - These may sound dangerous, sexy, unpleasant,
                    derogatory, or medical depending on your mood
                    at the time, but they are real terms. They may
                    well cause the initial corruption, but sincce
                    they are expensive to fix, treat repetitive
                    problems carefully. However, for data-critical
                    applications, power smoothing/UPS is probably
                    the way to go.

                    Spikes
                    - These are very rapid (< 1ms) and sometimes
                    quite large increases in mains voltage. They
                    can be many hundreds of volts above the normal
                    mains.

                    - Causes can be such things as large motors
                    stopping, (airconditioners, large fridges,
                    elevators etc) lightning in or near power
                    lines, possibly some electronic equipment, or
                    switching of large transformers and/or
                    capacitors. Anything that causes a sudden
                    change in mains voltage or current, in either
                    direction, can in the right circumstances
                    produce a spike much larger than the original
                    voltage or current change.

                    - These causes do not have to be in your
                    building or in your immediate vicinity. They
                    can be passed along quite a bit of power line.
                    (Sounds like an infectious disease or reds
                    under the bed).

                    - You will most likely never see the direct
                    effects of these, as they are so fast that
                    nothing is visibly affected by them (at the
                    time).

                    - These are less likely to be caused by the
                    power supply authority.

                    Surges
                    - The power surge is a slower (sometimes
                    several seconds or even minutes) increase in
                    power voltage. It will not be hundreds of
                    volts, but could easily take the supply up
                    over the 300 volt mark.

                    - It may be noticeable if rapid enough, by
                    brightening of the lights, or speeding up of
                    motors, but if it is very slow, or fast, you
                    may not pick this up.

                    - The Supply Authority can be to blame here
                    (and is often blamed). If the supply equipment
                    is not regulated sufficiently, it can produce
                    changes in voltage as loads change due to peak
                    time usage etc.  Again, local starting and
                    stopping of motors and other large loads can
                    produce surges. Even though these will not
                    affect the Supply Authority generating
                    equipment (we hope), the local transformers
                    may be affected.


                    Brownouts
                    - These are drops in voltage, usually slow,
                    and they are often noticeable as dimming of
                    lights, slowing of motors, etc.  However they
                    may not be noticed, depending upon the
                    severity and length. They may cause the
                    voltage to drop to less than half what it
                    should be.

                    - They are caused by such things as the
                    starting of large motors, temporary
                    shorts/partial open circuits in the wiring
                    system, caused by bad wiring or connections or
                    perhaps dust, moisture or something across the
                    lines. Again, any heavy load being applied to
                    the system can produce a brownout.

                    - Brownouts can (rarely) be caused by a
                    problem in the actual power generation
                    station, but if they are repeating, then the
                    cause is more likely local.

                    - A really bad brownout turns into a...


                    Blackout or Dropout

                    - These are total cessation of supply voltage.
                    They ARE usually noticeable!

                    - Causes are such things as power lines down,
                    blown fuses (either in your building or on
                    your pole transformer) or Supply Authority
                    equipment failure.  Another possibility is
                    that the plug has fallen out, or someone has
                    thrown the mains switch.

          EFFECTS OF THE ABOVE POWER PROBLEMS
                    - The effects of the above on your computer
                    are totally unpredictable. Each computer model
                    has a better or worse power supply, with the
                    capability to handle and smooth all of the
                    above.

                    - However, all of the power supply glitches can
                    affect any computer, if bad enough.

                    FIXES FOR THESE
                    - You can buy spike suppressors and surge
                    suppressors quite cheaply, or you can pay a
                    bit more. They vary in quality. Be warned! You
                    will PROBABLY get what you pay for, but if you
                    value your data, and don't want to waste $50,
                    then go to someone who knows what they are
                    talking about and isn't trying to sell
                    anything, and ask them for advice. You may end
                    up spending a lot more, but if you have a
                    problem, then it's worth it.

                    - Remember that in many cases, a spike
                    suppressor will not handle surges, and a surge
                    suppressor will not handle spikes. Even
                    expensive power supply smoothers have their
                    limits.

                    - Be wary of small cheap surge "suppressors".
                    Many of them simply switch off the supply when
                    it exceeds a voltage. This may protect your
                    equipment, but often not your data. Paradox
                    has just suffered an abnormal exit!

                    - The ultimate protection, you may think, is
                    the UPS (uninterruptable power supply). This
                    will keep your machine going long enough to
                    allow you to shut down with dignity, if the
                    power fails. However, many of them have no
                    power smoothing capacity, and thus will still
                    not protect you from surges and spikes, or
                    even damaging brownouts.

                    - The computer's own power supply has quite a
                    bit of capacity to absorb shocks, depending on
                    its quality.  However, if you are having
                    trouble, it may not be enough

                    THERE IS A MAINS GLITCH AGAINST WHICH THERE IS
                    NO PROTECTION BUT EDUCATION. NEVER HIT HIT THE
                    RESET BUTTON OR TURN THE POWER OFF WHEN YOU
                    ARE IN A PROGRAMME. ANY PROGRAMME. THE RESET
                    BUTTON SHOULD BE HIDDEN SHAMEFULLY AROUND THE
                    BACK OF COMPUTERS, IN MY OPINION. IT SHOULD BE
                    A LAST RESORT, WHEN THE MACHINE HAS SAT AND
                    LOOKED AT YOU FOR SEVERAL MINUTES, AND NO KEYS
                    WILL WORK.

                            - This applies particularly to
                            databases, which may have many files
                            open and thus vulnerable to damage,
                            and particularly to Paradox, which is
                            very particular about file structures
                            and their relationships to each other.



            MACHINE PROBLEMS

            This are takes two forms:

                    - Hardware/File Condition

                            - Cross-linking of files on the hard
                            disk, where two or more files are seen
                            as being in the same place on the disk
                            by DOS, is a serious cause of
                            corruption of data.

                                    - GPFs and exit from Windows
                                    is a notorious cause of these

                                    - check your computer out
                                    frequently

                            - temporary problems with the
                            hardware, such as the above memory
                            conflicts, etc

                            - mice in the computer (this is
                            perhaps a little extreme, but insects
                            or dust can be the cause)

                            - loose connections etc

                            FIXES
                            - Disk file handling problems

                                    - This can be fixed by Norton
                                    Utilities etc, or cheaper but
                                    not as prettily or as
                                    thoroughly, by chkdsk, and
                                    other DOS utilities.

                                            - if it keeps
                                            recurring, do a
                                            physical check of the
                                            disk (Norton again),
                                            and look at actual
                                            hardware problems.

                                                    - Windows has had
                                                    a few fingers
                                                    pointed here too.
                                                    GPF's and the
                                                    subsequent user
                                                    exit have been
                                                    know to leave
                                                    crosslinks etc.

                                            - Make sure you
                                            understand the
                                            ramifications of what
                                            these tests and fixes
                                            do before you use
                                            them.

                            Memory conflicts

                                    - see SOFTWARE CONFLICTS AND
                                    MISBEHAVIOUR

                            - Mice etc

                                    - have the machine cleaned

                            - Loose connections

                                    - have the machine overhauled


                    Actual Hardware Collapse

                            - the hardware is faulty, and needs
                            repairing

                            - These problems can be in any part of
                            the machine, be it disk(s) and control
                            cards, memory (particularly these days
                            with many programmes, and particularly
                            pARADOX AND Windows, using memory to
                            the MAX), mother board, buses and
                            connectors or power supply (internal).

                            - The problem is that any testing
                            software has its limits. I don't know
                            of one that can pound memory as hard
                            as Windows does, and probably not as
                            hard as Paradox. Many hardware faults
                            are intermittent, or you would not be
                            using the machine. Even a burnin test,
                            over many hours, may not pick up a
                            fault tha may happen only once, and
                            never again.

                            - This software is also hard put to it
                            to test the power supply.

                            - Such programmes as Windows and
                            Paradox are continually seeking out
                            every last bit of memory, and using
                            it, and one byte going wrong, just
                            once, can be enough. Memory is
                            particularly susceptible to power
                            spikes etc.

                            - Programmes are now often also
                            pounding away at the hard disk, using
                            it for both data work and for virtual
                            memory, with a resultant almost
                            continual transfer of data from memory
                            to disk and back, even when you may
                            not think that there is much data
                            transfer going on. Watch your HDD
                            light some time.  Again, any small
                            fault in any part of the storage or
                            transfer can be enough, even if it
                            only happens once.

                            - Unfortunately, sometimes it's the
                            hardware and the software that are not
                            working together, so you can put the
                            same setup on another machine, and
                            it'll work perfectly. On the positive
                            side, this is another method of
                            diagnosis, if you have the luxury of
                            another machine.

                            FIXES

                            - Try running the same setup in
                            another machine for some considerable
                            time, and see if this helps.

                            - The only fix is to have it fixed or
                            replaced

                NOTE: It is an arguable point, but from my experiences with my
                and other systems, I have noticed that most corruption comes
                to light during massive data transfer, particularly when
                Query/Add is being used, with Add seeming to be the "prime
                suspect". This, in my opinion, is because QUERY/ADD strains a
                system fairly hard, in the interests of speed, and will thus
                either find any small problem that exists with the system and
                aid in the causing of corruption, or cause what would normally
                be insignificant data problems to become serious, because of
                the "fine tuning" required by the performance.

        ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

	PART 4
	REMOVING TABLE CORRUPTION

		RULE #1 : BACKUP
		RULE #2 : BACKUP
		For all other preliminary rules: see rules 1 and 2

			- Some of the things you are going to try can
			completely wipe all data from the subject
			table(s).  Even a corrupt table is better than
			nothing.

		- It's safest to carry out the following on ALL tables
		in a system. I leave it up to you to decide between
		thoroughness and risk-management.

		DATA

		- There are various ways to remove data corruption.
		They are presented here in the order that I consider
		you should try them. Others have disagreed. I work on
		the basis of easiest first. Remember, it's ALWAYS the
		last one you try that works!

		(1) RESTRUCTURE

		(1) Find out the structure of the table, exit Paradox,
		delete the .px file(s) for the offending table(s) to
		remove the keys, and then interactively restructure
		them, re-entering the keys.

		- Do NOT delete these files by shelling to DOS from
		Paradox.  Paradox doesn't like it and results are
		unpredictable.

			PROS AND CONS

			(1) Easy, if you know the table structure.
				- with some corrupt tables, you may
				not be able to see the structure until
				it's fixed. Documentation required.

			(2) Often doesn't work, the corruption is
			deeper than this. This only fixes tables that
			are out of sync with their keys.

		(2) TUTILITY

		- This is provided by BORLAND, for just this purpose.
		It has various options, from verify to complete manual
		(in version 4.0) rebuild. V3.5 was sometimes useful,
		but questionable.

		- These go, in order of effect and difficulty:

			- Verify: Which simply tells you if it finds
			corruption

			- Rebuild : Which attempts to remove the
			corruption by actually processing the table. I
			have my guesses as to what it does, but
			Borland don't talk about it much.

			- Manual Rebuild: Which actually asks you to
			tell it what structure the table had. It is a
			complete reconstruction (NOT just a
			restructure, although that is probably
			involved) of the table.

			- I am not going into how to do all these
			things, but I will state the following points
			that I have picked up:

			- NEVER run TUTILITY Rebuild from within
			Paradox. The .doc files say you can run
			TUTILITY from within Paradox, but v4.0 is so
			fat, it keeps running out of memory in a
			shell. This can cause worse problems than you
			had in the first place.

			- ALWAYS back up your table before you do
			anything. Even though it's damaged, it's still
			better than nothing.  I've been there.

				- You may need to DOS copy tabname.*
				to do this, as Paradox may not allow a
				copy of a damaged table.

			- always use a new file name for backup in
			tutility during {Rebuild}, never overwrite one
			that you've just used, when asked. (V4.0)

			- always check that the table that you are
			cleaning has not been emptied by a previous
			attempt.

			- It has been suggested that you always run
			CHKDSK, and then CHKDSK /f before you run
			TUTILITY, or it will not have the desired
			effect. Bear in mind the data effects of
			CHKDSK, or any other utility like it.


			PROS AND CONS OF TUTILITY

			(1) TUTILITY rebuild will lose secondary
			indexes.
				- need to rebuild these

			(2) Verify is only fairly reliable

			(3) TUTILITY is easy

				- although 3.5 version was much easier
				to automate
					- but cannot be used for 4.0 +
					tables

				- V4.0 is more "interactive", and not
				so good for the user who wants to scan
				a whole directory

				- I now have a DOS automation
				for V4.0 that produces a report to an
				ascii file at the end, automatically
				scanning all tables in a named
				directory, (3.5 used to do this for
				you using *.db, but 4.0 will not).


			(4) TUTILITY is cumbersome if you are doing a
			heap of tables interactively , and are a user,
			not a computerer. Its interface is OK, but
			slow to use over a whole system.

			- Bear in mind that I feel that at least
			TUTILITY {Verify} should be run after ANY
			abnormal exit from Paradox. On ALL tables that
			are involved in the system. I take this
			seriously enough to not allow a user back in
			unless a normal exit was flagged at last exit.

			(5) TUTILITY may lose records, if it can't fix
			them.  Remember that this could destroy the
			referential integrity of your database, and
			this should be allowed for, perhaps with
			checks of all related data. A backup may be
			safer and easier.

			(6) Will not capture all corruption

				- although reputedly 4.0 version will
				do over 95% on a rebuild

			(7) To quote the documentation from TUTILITY:
			"When TUTILITY rebuilds a table, it doesn't
			preserve existing Image Settings (.SET files
			in Paradox for DOS) or Table Views (.TV files
			in Paradox for Windows). TUTILITY copies these
			files to the same name as the backup table
			(with the appropriate extension) prior to
			rebuilding the table. If you want to restore
			Image Settings or Table Views on a table, you
			must use Tools|Copy|JustFamily in Paradox (or
			the DOS COPY command) to copy the files to the
			same directory and name as the table. Then you
			must restructure the table in Paradox to force
			Paradox to recognize the .SET or .TV file."



                (3) EXPORT TO ASCII AND REIMPORT

			- I have written a (partially successful)
			automated version of this, because it's
			cumbersome.

			The steps are:

				- run CHKDSK/f as mentioned above

				- run TUTILITY and restore/rebuild any
				corrupt table(s) reported

					- sounds silly, but the ASCII
					export/import is reputedly
					more thorough than TUTILITY,
					but can get upset if the table
					is badly corrupted. (see Pros
					and CONS for this section).
					Therefore preliminary fix with
					TUTILITY, then "4 by 2" treat
					with export/import

				- Dump every MEMO and BLOB
				record/field to an individual file
				before you start, (and hope it's not
				part of the corruption when you bring
				it back).

					- see MEMOSCAN.ZIP in this lib

					- Export/Import does not
					include these.

					- TUTILITY will have fixed the
					table sufficiently to allow
					this now.

					- Use filewrite/fileread

				- export the data to ASCII delimited

				- export the structure to ASCII
				delimited (different file) (optional,
				for the auto system)

				- {create} and {borrow} to another
				table, then copy {justfamily}

					- call the result "MIRTAB" for
					argument's sake

					- remember this table is as
					corrupt as the other one,
					probably

				- reimport the data to another table

					- this will now have wrong
					field names and sizes, and
					will be keyless

				EITHER
					- manually restructure the
					imported table to give the
					right field structures and
					keys

				OR

					- if you have
					exported/imported the
					structure, and want to do some
					coding, use dynarrays to scan
					and store the reimported
					structure table, then use the
					dynarray to "type in" the
					correct names, sizes, keys etc
					to the imported data table.

				- Copy the family from "MIRTAB" back
				to your suspect table.

					- if the family is corrupt,
					you have a problem. But that's
					a topic for further
					discussion.

				- You now, hopefully, have a clean
				table

				- DISCARD "MIRTAB"


			PROS AND CONS of ASCII EXPORT/IMPORT

			- To be honest, I developed this idea to
			overcome the shortcomings of 3.5 TUTILITY, and
			I get the impression that it's not so very
			different from what V4.0 does.  It has saved
			my hash a couple of times, when TUTILITY has
			let me down because corruption was so subtle
			as to be undetectable. Its advantages over
			version 4.0 are therefore yet to be tested,
			and I for one do not want the opportunity, as
			it takes several goes to find out.

			(1) Obviously, it needs programming or a VERY
			experienced and careful user to be done
			properly, especially over several
			tables.

				- even as I have programmed it, I have
				had problems, mainly with corrupt
				family items, and I have more work to
				do to catch all the hitches.

					- still not able to be dumped
					on the user, as yet

			(2) It will lose all secondary indexes (no
			choice here)

			(3) The export may not work properly if
			TUTILITY is not run first

				- in extreme cases of corruption

				- signs of this are such things as
				exporting 10000 records from a 1000
				record table etc


		(3) SIMPLY RECALL THE TABLE(S) FROM A BACKUP, AND HOPE
		YOU'VE GOT A CLEAN VERSION.

			PROS AND CONS OF RECALL FROM BACKUP

			(1) If you can find a clean backup of your
			system, you are home and hosed.

			(2) You are BOUND to lose data, if you've been
			busy.

			(3) You can control the files that you bring
			back, to maintain administrative and
			referential integrity in the system.

				- You KNOW what date you went back to,
				not just that some records may be
				missing (from say, a TUTILITY
				{Rebuild}).

				- This may simply mean all files,
				which may not be bad, as you don't
				know what's damaged.

			(4) Depending on your backup system, it's
			fairly straightforward and simple, although it
			can be slow, if you have to go back a way in
			your backups to find clean data.

			(5) The only way you know you have clean data
			is if you don't get any more problems.

				- you should run at least TUTILITY
				verify after the restore


		TO SUMMARISE corruption fixes:

			RESTRUCTURE

				- is simple

				- only works if you're lucky, and the
				damage was only to keys/table links.

			TUTILITY
				- is easy

					- but cumbersome in the 4.0
					version if many tables are to
					be done

				- is only moderately reliable in
				Verify mode

				- is 95% + reliable in Rebuild mode

				- loses secondary indexes

				- keeps MEMOS and BLOBS

				- should only be run after CHKDSK
				gives a clean bill of health

			EXPORT/IMPORT
				- is NOT easy

					- but could be automated

				- does not verify

				- needs TUTILITY first, to check for
				and remove extreme corruption

				- loses secondary indexes


			Restore from Backup

				- loses data

				- is fairly easy, but can be slow

				- ensures that user knows exactly what
				they have lost, from the backup date

					- if their office system is
					kept reasonably carefully

				- I would suggest at least a TUTILITY
				Verify after restoration

					- I know this sounds circular,
					but there you have it!


			- All of these deal ONLY with corrupt DATA,
			not families.

			- None of the above can ensure clean data.

			- Always have two copies of the table you are
			working on.

				- If anything goes wrong ALWAYS
				MAINTAIN 2 copies.

			- If you're religious, pray. If not, just
			worry.


        ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

                TO SUMMARISE THE WHOLE OPERATION:

		(1) Remove the corruption

		(2) If it recurs
	    	see (1)
			try removing it once more

		(3) if it recurs
	    	see (1)
			- you MAY have another problem

			- Easiest first

			- (these can be tried in any combination,
			depending on the urgency/cost factor, with
			retries between each experiment)

			(a) Virus check

			(b) Run CHKDSK or similar

			(c) Run a disk surface checker

			(d) Run diagnostic software

				- (preferably after hours, as a
				repeated burnin)

				- repair indicated faults

 			(e) remove all TSRs, and gradually reinstall
			them.

				- includes not using Windows or
				networks if possible

			(f) reinstall Paradox

			(g) reinstall any other software that may be
			connected, or is providing data input.

			(h) Get the power checked over an extended
			period

				- If problems show, install protective
				equipment as required.

			(i) Copy the whole system ( I mean the whole
			disk) across to another machine, if one is
			available.

			(j) Try inserting different disk driver cards
			etc, if any are available and you feel like it
			and can do it.

				- or take the machine for "replacement
				diagnosis" to a shop that has plenty
				of spares etc

			(k) I'm sorry. See (1)

        end of article


	28.9.93 - 18.10.93

        Author :

        N. F. White

                Nick White