Creation Password (GRX)

[Brian K. White]

On 2/25/2011 2:03 PM, Chris Sellitto wrote:
>>> Chris said:
>>>
>>> Sometimes what we do here is we will take an existing file (ie.
>> Gr_REDBK),
>>> and copy the key, map, and indexes into another folder, for example
>> called
>>> REPREDBK.  What we see happen when we do this is when we access the
>> file
>>> REPREDBK we get a "ENTER CREATION PASSWORD FOR 'REPREDBK'" message
>>> box.
>>> There was no password on the original GR_REDBK file to begin with.
>> Does
>>> anyone know why this happens....
>>>
>>>
>>> Scott says:
>>>
>>> You should use the fpcopy program provided to copy a file to a new
>> file
>>> name, or to rename an existing file.  That will prevent the problem
>> you
>> are
>>> having.
>>>
>>> As for your current situation, I seem to remember it has something to
>> do
>>> with the map file getting some encrypted password in it and when you
>>> directly copy it to a folder with a new name (as opposed to using
>> fpcopy)
>> this
>>> generates the problem.  I can't remember but I believe the way to
>> directly
>>> edit the map (like with notepad) to remove this problem has been
>> discussed
>>> on this list.  I hope someone else will jump in and give you that
>> procedure.
>>>
>>> Regards,
>>>
>>> Scott
>>
>> If I remember this hack correctly, one would create a new filepro file
>> with
>> the name wanted with at least 1 field.
>>
>> Then open the original map and the new in an editor and copy everything
>> below the header to the new map. Make sure that you replace the first
>> field
>> in the new map file with the first field of the map old file so
>> everything
>> lines up properly. Then copy the key and data segment sizes making sure
>> not
>> to change the password.
>>
>> Map:record length of key;record length of data:number of fields in
>> key;password
>>
>> map:595:0:66:bcea1c80:vgH8o(Mg&arI*}#h
>>
>> In the above case, the record length is 595, the data segment is not
>> used -
>> zero length, 66 fields in key; then the password.
>>
>> The save the new map and copy the key, data and the rest of the files
>> to the
>> new directory.
>>
>> A lot of work when fpcopy, as mentioned above and by Ken, does this in
>> a
>> much easier, cleaner and faster way.
>>
>> Richard Kreiss
>> GCC Consulting
>> rkreiss at gccconsulting.net
>
> Thank you everyone for all the replies.  I do know about the fpcopy utility, and have used it many times in the past.  For this particular application I had forgotten that we were actually doing something similar to what Richard was describing.  I had added a new field to the database, and the file I was copying to still had the old map layout.  Richard's suggestion jogged my memory, and I was able to resolve my issue.
>
> One question I do have is can fpcopy work from the command line with parameters?

Yes and no.
It takes no flags and you're not officially supposed to be able to run 
it non-interactively, but if you are careful to lock down a few 
variables it is possible to feed it keystrokes in a script.

See my old fpcopyall script. fpcopy has (or at least had) a problem 
where it would silently ignore and not copy some parts of filepro files 
if their names were too long.
So fpcopyall temporarily renames these parts to shorter names before 
running fpcopy, then renames them back to the original name after.

It feeds keystrokes to fpcopy, and it ensures that fpcopy never 
generates a prompt that doesn't align exactly with the fixed keystroke 
string, by specifying some variables like PFME rather than leaving them 
to chance. I haven't touched or used this in years. It probably needs 
tweaking for linux/bash. The point is the concept not to use the actual 
script without going over it.

http://www.aljex.com/bkw/filepro/#fpcopyall

-- 
bkw