File restructure bastardization

Don Coleman dcoleman at dgcreact.com
Tue Sep 27 08:51:57 PDT 2005


Nancy Palmquist wrote:

> Kenneth Brody wrote:
>
>> Quoting George Simon (Thu, 22 Sep 2005 11:36:58 -0400):
>> [...]
>>
>>>> ObDisclaimer:  This is not an official endorsement by fPTech, just
>>>> my own opinion.
>>>>
>>>> Since you aren't changing the length of the fields, and the new type
>>>> would accept the existing data as-is, with no effect on sort-order
>>>> (in case there are indexes built on them), you could theoretically
>>>> edit the map, changing "YESNO" to "*" or "ALLUP", even while people
>>>> are using the file, with no ill effect.
>>>>
>>>> Of course, I would highly recommend trying this out on a test file
>>>> first.
>>>
>>
>> [...]
>>
>>> Any time I've changed a field edit from anything to an asterisk,
>>> re-structuring does not take place.  I don't think (know?) that is true
>>> for ALLUP.
>>
>>
>>
>> Changing a field type to "*" without changing its length does not
>> trigger a restructure, as the field's contents would not change
>> during such a restructure.
>
>
> But the lockfile will not allow this kind of change if the file is in 
> use as indicated by the original posting.  The only way to change the 
> map would be from outside of filePro.
>
> I agree with all others - this is a very touchy type of change.  If 
> you make any other change to the map your customers may crash entirely 
> and the data become corrupt.
>
> I would suggest this be handled during the scheduled maintenance time.
>
> Nancy
>
Thank you to all who responded to my question.  I tested this on my 
local work station by changing the field edit from "YESNO" to "*" and 
then ran autoshuf.exe.  There was no restructure of data and all data 
appears fine.  As Ken has already stated, changing a field edit from 
"YESNO" to "ALLUP" did trigger a file restructure with autoshuf.exe.  In 
preparation for this change I shut down each client with fP installed 
and then disabled the network share to the drive containing the fP 
executables and their fP programs & data.  I then copied my map.new file 
from my client to the network and ran autoshuf.exe.  It appears to have 
worked fine (4 days & counting).  I choose not to directly edit the map 
on the network although Ken has stated that this will not cause a file 
restructure ("YESNO" > "*") and not cause a loss of data.  Of course, 
should anyone gain access to the file during any of these processes the 
results could be catastrophic. 

Hopefully I took all necessary precautions to minimize any risks.  As 
stated earlier, this is the first time I felt the need to handle the 
restructure in this way.  This client runs 24X7X365 excepting the 2.5 
hours per night that everyone is required to log off during their system 
backup.  Thank you again for all the advice & suggestions.

Don Coleman


More information about the Filepro-list mailing list