file too large

[Brian K. White]

Why export to csv? Just copy to a new qualifier in the same file, the 
processing becomes a single copy command for the entire record you want 
to preserve.

You can do the same thing for archiving, make a new qualifier for a 
given date range.

Assuming you have a selection set or separate selection processing to 
find old records, the actual report processing to archive is just

lookup alias = self at qual r=free -e
copy alias
delete
end

You probably don't want to use "-" for self, use the name of the filepro 
file even though you're already in it. Lookup - means to look up a 
record in the current file and jump/move the current focus TO it, but 
since the lookup is to some other qualifier I don't know what it would do.

To go the other way and create a new qualifier that has only the records 
you want to keep, point being to make a new raw key file that is 
smaller, just take away the delete from above, then rename the key files 
so the original 2G file is named key20110203 and the new smaller 
keysomething is named key.

dxmaint -ra -e
to rebuild all indexes after the musical chairs and you're done.

In the future, allow the file to grow to almost 2G but not all the way 
to 2G, have something that periodically archives old records to new 
qualifiers using the code at the top, and don't worry about physically 
shrinking the key any more. It's fine to let it grow to almost 2G and 
just keep copying and deleting records as they get old. The musical 
chairs is just a one time to get the key down under 2G because several 
things choke when the file is exactly 2G even if you aren't trying to 
grow it any more. You don't need to do the dxmaint except the one time 
either.

-- 
bkw

On 2/3/2011 4:45 PM, scooter6 at gmail.com wrote:
>    Well, there are over 8 million records in this file - so I was looking for
> a bit quicker of a solution to get this resolved
>    I can't wait to get this system on a CentOS server - SCO is soooooo dang
> slow haha
>    I'm currently looking to export the records to a few csv files, then
> delete key&  data for this file and import only the most
>    recent 6 months or so and then resolve the rest when I get back next week
> from vacation....
>    Why do these things happen the day before I'm leaving town? haha
>
>    So, to clarify - is this a SCO OpenServer 5.0.5 issue, or is this a
> filePro error? Meaning, if I upgrade tonight to 5.6.10 would this
>    resolve the issue?
>
>
>
>
> On Thu, Feb 3, 2011 at 4:38 PM, Jeff Harrison<jeffaharrison at yahoo.com>wrote:
>
>>   ----- Original Message ----
>>
>>> From: "scooter6 at gmail.com"<scooter6 at gmail.com>
>>> To: filePro Mailing List<filepro-list at lists.celestial.com>
>>> Sent: Thu, February 3, 2011 4:13:05 PM
>>> Subject: file too large
>>>
>>> We have a note line file that has apparently surpassed the 2GB size on
>>   SCO
>>> OpenServer 5.0.5 running filePro 5.6.07R4
>>> A lot of users got stuck  recording new records to this file, so I got
>> them
>>> all off the system and  tried adding a record and I'm getting
>>>
>>> ..../appl/filepro/filename:   key  file too large
>>>
>>> We had previously run an archive on this file,  but I know filePro won't
>>> actually 'shrink' the file size reported on the file  system.
>>>
>>> Are there any utilties that will 'shrink' this file below the 2GB  size
>> limit
>>> by 'removing blank records' ?
>>>
>>> So much for my vacation that  was supposed to start tomorrow........
>>   uggghh
>>>
>>>
>>>
>>> Scott
>>
>> If your blank records are actually deleted records, then yes there are a
>> number
>> of utilities that can shrink your file.  You can also do this yourself -
>> just
>> archive all the remaining records to another (new) file (or qualifier in
>> the
>> same file), and then from the OS just copy the key file back on top of the
>> original key.  Do the same for any other data segments that may exist.
>>   Then
>> rebuild all of your indexes in the original file and you should be all set.
>>
>> One possible "gotcha" - sometimes people actually use the record numbers as
>> pointers - I assume you are not doing that?
>>
>> Going forward you may want to set up a periodic archive so this does not
>> happen
>> again.
>>
>> Good Luck.
>>
>> Jeff Harrison
>> Author of JHExport and JHImport.
>>
>>
>>
>>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: http://mailman.celestial.com/pipermail/filepro-list/attachments/20110203/24535382/attachment.html
> _______________________________________________
> Filepro-list mailing list
> Filepro-list at lists.celestial.com
> Subscribe/Unsubscribe/Subscription Changes
> http://mailman.celestial.com/mailman/listinfo/filepro-list
>