Re: Designing archives into your VFP-backend application

Author: Stephen Russell

Posted: 2017-12-29 at 12:41:12

On Fri, Dec 29, 2017 at 12:20 PM, <

mbsoftwaresolutions@mbsoftwaresolutions.com> wrote:

> On 2017-12-29 12:00, Stephen Russell wrote:

>

>> I think you missed my point. this is a separate product you are creating

>> that will pull data from VFP and only store it online. You can then build

>> up a new style of reporting outside of VFP. Once they approve of it you

>> can delete the data older than 4 years or 7 years from the VFP

>> environment. The Data Scientist role may suit you very well.

>>

>> Check out this:

>> https://www.zs.com/services/technology/technology-services/

>> big-data-and-data-scientist-services.aspx

>>

>

>

>

> Thanks for the link. Data Scientist is definitely a job for the future

> and big $$$ I think! My original post was not so much about reporting; it

> was about hauling tons of data over the LAN that's no longer relevant and

> the archival process I proposed to resolve that (without permanently

> deleting data). As we said in a previous thread, the whole DBF isn't

> coming across the network unless you've got commands like REPLACE ALL etc.

> and unfortunately in the case of my previous Corporate app at Sylvan,

> there's tons of old code from previous devs where they did that often.

>

> ----------------------------

My company won't get rid of transactional data and the size of the 4 GL

tables that are in my way is roughly 600 gigs. Finding specific data in

them that is outside the scope of my indexes takes way too long. It also

takes additional time to do a restore as well. In 2018 we are porting to

an upgrade on a new data server so it will take each test more time to

restore as well.

To me, IRS data demands past 7 years. I'll keep 8 and remove 3 years of

older transactions now because we already have them in the DW as well.

Welcome to my monthly fight. :)

--

Stephen Russell

Sr. Analyst

Ring Container Technology

Oakland TN

901.246-0159 cell

--- StripMime Report -- processed MIME parts ---

multipart/alternative

text/plain (text body -- kept)

text/html

---

_______________________________________________

Post Messages to: ProFox@leafe.com

Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox

OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech

Searchable Archive: http://leafe.com/archives/search/profox

This message: http://leafe.com/archives/byMID/profox/CAJidMYLLW1uHzXhKNuYZB7SmFKM8dwMrz393zSaVrQVc1B+oaA@mail.gmail.com

** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.

©2017 Stephen Russell