Dxmaint

Fri Nov 3 12:42:52 PDT 2017

Apologizes for the top post;

At the beginning of the rebuild program create a file with a particular 
name somewhere in the system.

At the top of the program that accesses the detail, check for that file.
If it exists, tell them you are running index maintenance.

At the end of the program that does the index rebuilding, remove the file.

Richard D. Williams

On 10/29/2017 8:42 PM, Richard Kreiss via Filepro-list wrote:
> I realize that but tell a client who wants to keep all data - forever.
>
> I created the qualifier, history for the purpose of being able to maintain
> historical data.
>
> However, there are some reports that are based on being able to look back to
> the beginning of his business over 30 years ago.  This was before I handled
> his system.  Oddly, I got this client from another client who at the time
> had retail stores and my current client was a vendor.  The original client
> wrote software for his business and wrote the programming for this client.
> When the first client sold his business, he handed me the account.  I
> updated most of the programs except for a number of the reports which I will
> not go near the logic.
>
> There is one file which contains data for product usage from the day the
> system went live.	That file is not as large as the order data file but
> is over 3 Mb in size now.  Some of the indexes are much larger.
>
> I have given up arguing with my client over the amount of data kept on-line.
> Every year I archive to the history qualifier records that are 4 years old
> or older.  This keeps the file from growing too large- record wise.
> However, the downside of this is the indexes in this qualifier are very
> large.  When I post to this file, I delete all of the automatic indexes
> first and then rebuild them.
>
> There is also a third qualifier called backup.  When an order is entered
> from the header file, the details are written to the order key and
> key.backup.  In this way, if the primary key has issues, I can rebuild the
> primary order key.  This happened a few years back and allow me to get them
> back up and running quickly.  I just cleared the key which contained
> corrupted records and allowed the order clerks to enter the new orders.
> That evening, I was able to post back all of the order details which were
> appropriate.
>
> Yes, The system had been backed up the night before, once to a tape drive
> the other to a backup computer.  However, this was faster and allowed them
> to continue working.
>
> I also maintain copies of my client's data and programs on my server.  This
> has allow me to reinstall full applications when some of my smaller clients
> have had computer failures and had not backed up their systems.  Their data
> was not up to date but they felt it was better than having none at all.
>
> I do have versions of filePro going back to 3.0 on my system.  However, the
> oldest installation any of my clients are using is 4.5.  filePro 4.8 will
> not run on a 64 bit system as some of the DLL files won't load. I get an
> error message.  I run filePro versions earlier the 5.0 on my Windows 7 or
> windows XP computers. I do have an older computer with Windows XP.  I have
> some older machines that I am considering installing DOS 5.0 on.  I haven't
> run into anyone still on DOS but who knows?
>
> Richard Kreiss
>
> PS: It doesn't pay to argue data storage with clients any more.  The prices
> for storage has dropped greatly over the years.   My first 8 MB hard drive
> cost close to $8,000 and a few year later a 35 Mb hard drive cost $675.00;
> as did a 17" color monitor.  Today one can purchase a 4Tb drive for under
> $75.00 and the latest M.2 120GB SSD for under $200.00.
>
> My own computer has a 256GB Samsung SSD and a 950 EVO Samsung 120GB SSD as
> well as a 4TB internal drive and a 1 Tb esata drive.  The SSD's are very
> much faster than the mechanical drives.   Just consider the cost of memory
> sticks; these have come down in price and gained more storage capacity and
> speed.
>
> The only issue I have with the branded server manufacturers is the pricing
> on their drives.  I would love to have client's purchase servers without
> drives as they can be populated less expensively from other outlets.
> However, they want the manufactures warrantee on the whole box and are
> willing to pay for it.
>
>
>
>
>
>
>> -----Original Message-----
>> From: Filepro-list [mailto:filepro-list-
>> bounces+rkreiss=verizon.net at lists.celestial.com] On Behalf Of Jose
> Lerebours
>> via Filepro-list
>> Sent: Sunday, October 29, 2017 6:16 PM
>> To: Richard Kreiss <rkreiss at gccconsulting.net>;
> 'filepro-list at lists.celestial.com'
>> <filepro-list at lists.celestial.com>
>> Subject: Re: Dxmaint
>>
>> On 10/29/2017 02:13 PM, Richard Kreiss via Filepro-list wrote:
>>> Situation:
>>>
>>> The is a service that rebuilds all of the auto indexes for their order
> header &
>> order detail files.  This service starts at 4 AM on Sunday and take a long
> time to
>> run as there are 10 order header indexes and 12 order detail indexes.
> Both files
>> have a qualifier and these indexes are also rebuilt.
>>> The primary order header file has 1, 075,176 records and the order
> detail file
>> has 22.719,170 records.  Most of these indexes are multi key.  The header
> file
>> rebuilds fairly quickly.  It is the detail file that takes a lot of time.
>>
>> Have you ever considered normalizing your files, using smaller tables and
>> archiving data?
>>
>> You really do not need your daily operation files with more than what is
> "open"
>> not older than 120 days, beyond that, arhive it.
>>
>> So, given an sales order module where:
>>
>> dailyOrdersh is archived to dailyOrdersha dailyOrdersd is archived to
>> dailyOrdersda
>>
>> In doing so, you can basically rebuild indexes on your daily operations
> files in
>> matter of minutes since your combined records of 3+ millions should shrink
> to a
>> few thousands (even if as many as 100K records, you will be way ahead of
> the
>> game).
>>
>> Just because you can keep millions of records in a file does not mean it
> is a good
>> idea to do so.
>>
>> All that said, a replica of your existing code should be good enough to
> grant
>> access to archived records so, there should be very little work from your
> part to
>> get this done and have a solid long term solution to your problem.
>>
>> Finally, I wonder if @menu show "@File not available due to daily
>> maintenance!" could help after checking dow() ... and a predictable time
> frame
>> you want to safe guard ... !?!
>>
>>
>> _______________________________________________
>> Filepro-list mailing list
>> Filepro-list at lists.celestial.com
>> Subscribe/Unsubscribe/Subscription Changes
>> http://mailman.celestial.com/mailman/listinfo/filepro-list
> _______________________________________________
> Filepro-list mailing list
> Filepro-list at lists.celestial.com
> Subscribe/Unsubscribe/Subscription Changes
> http://mailman.celestial.com/mailman/listinfo/filepro-list
>
>
>
>
> ---
> This email has been checked for viruses by AVG.
> http://www.avg.com
>
>