In fact, it you create a primary index on a table you will see a physical
*.px "child file".

Close paradox, delete the px file, then back into paradox and look at structure
of table, the * primary key indicator is gone. 

The indexes (primary and secondary), table view settings, values, etc. are
derived from the "child" files when looking at the structure.



"Steven Green" <greens@diamondsg.com> wrote:
>ditto to what the others said.. sec indexes don't create themselves
>
>
>--
>
>Steven Green
>Myrtle Beach, South Carolina, USA
>
>http://www.OasisTradingPost.com
>
>Collectibles and Memorabilia
>Vintage Lego Sets and Parts
>- and Paradox support, too
>"Anders Jonsson"  wrote in message 
>news:5def7a79$1@pnews.thedbcommunity.com...
>
>I agree with Tom.
>
>As to doing backup, I would always make a full backup on all the files
>in a Paradox database. I would be surprised if the database would be so
>big that it would be be a real issue, disk space is cheap today.
>
>
>
>
>Den 2019-12-10 kl. 02:26, skrev Tom Krieg:
>> As far as I know, Paradox doesn't automatically recreate secondary index

>> or .val files. It has no way of knowing how to recreate them because all

>> the information needed is stored in those files. The .db file is just
a 
>> flat file of 64K blocks, containing fields with data in them.
>>
>> My understanding is that the only way to re-create these files once 
>> they're gone, is manually or through code.
>>
>>
>> On 10/12/2019 12:26 am, Kevin Baker wrote:
>>> Tom,
>>>
>>> So the only way the children files would be recreated is if I initiated

>>> it through code?  I ask this because to my knowledge I don't have any

>>> code to re-index the table, yet the files were recreated.
>>>
>>> This issue has come about because I was looking at doing incremental

>>> backups, but have read this wasn't a good ideal due to the children file

>>> issue.  My thought was if I had to do a restore of a db, then I could

>>> just delete the children and have paradox recreate them.
>>