Re: Changing A Btrieve index

Keith Canniff

What about trying the following


Have an instance of Magic running on the server and not from a user that has a passed in parameter that tells Main Program to run a Magic Rebuild program.


In the Data Repository, change the indexes that you want but do not run the conversion.


Duplicate the table in the repository and give it a new name (something like <original filename_tmp>, but not .tmp because Pervasive’s locking doesn’t recognize name differences based on the extension (at least from what I remember)


The program (999) defined above does the following when launched from Main Program


Block Loop

Try to rename the original filename to the _tmp filename. This has a delay and continues to loop until the rename is successful.

End Loop


Call a subtask (999.1) that opens the original file (which now has been renamed so doesn’t exist) as Read/None. This creates an empty file but because it has the share of the file set to none doesn’t allow any other program using the table to run. This task is set to end task = Yes, Before.


This subtask (999.1) in task suffix, calls another subtask that does the following:


Subtask (999.1.1) Opens the duplicated _tmp table as Write/None/Reindex.

This task has end task = Y, Before.

Once this task ends, the indexes will be dropped and rebuilt.


The program returns to subtask (999.1) and then exits back to the parent root task (999) and in the next statement after the call subtask to (999.1) has

Block Lopp

Try to Delete the small empty original table created by the subtask

Continue loop until it can be deleted

End Loop


Block Loop

Try to rename the _tmp table that had the index rebuilt back to the original filename.

Continue loop until the table renames

End Loop


Parent program now ends and returns back to Main Program.

Exit Magic






From: [] On Behalf Of wes@...
Sent: Tuesday, January 24, 2017 8:29 PM
Subject: Re: [magicu-l] Changing A Btrieve index


But in our case we have close to 250 clients and all of them will get a definition mismatch. When clients receive an update all users must be out of the system, the the first user back in will trigger the conversions.  As we are working toward SQL, we have changed alot of our table definitions to make the transition easier. This has taken a big load off our support team as they don't have to worry about running conversions!  In addition, if a 'scratch' file has changed and deleting it doesn't hurt anything, we just delete the file and re Declare it in the main program.

We also take 2 additional precautions.

1) We have a 1 field, 1 index test table that is never used or changed.  We have experienced on rare occasions that Pervasive does not load as expected so an 'unknown database' error occurs on the first file uniPaaS attempts to open (when this happens it really screws things up because the first definition rebuild occurs thinking there is a definition mismatch even though there isn't )  The first call in our main program is a subtask to 'Declare' this test table, if there is ANY error, we give the user a message they must restart our application and then exit without processing the main program logic.

2) When a definition mismatch occurs we write a ConversionInProgress.txt file so anyone logging in with this file in existense will get a message that conversions are running please try again later, then exit the application without executing any more of the main program logic.  This way only one user will run all the necessary conversions.  The last operation in the main program is to delete the text file after all the conversions have been completed.  On occasion should something go south and this file doesn't get deleted, we have had to manually delete it.


Avast logo

This email has been checked for viruses by Avast antivirus software.

Join to automatically receive all group messages.