At 07:47 2017-12-29, mbsoftwaresolutions@mbsoftwaresolutions.com wrote:
I've seen long-time softwares with VFP backends that had a ton of data (10+ years worth) and I had devised a method in one case recently to be able to "archive" old data by storing it in a subfolder intelligently (so it could be easily retrieved and/or reimported into the main data set). I haven't used a VFP backend since 2004 when Bob Lee introduced me to the MySQL world but nonetheless I thought I'd ask if devs here ever put anything like an "archiving" feature into their software, and how they do it. In my case, instead of slinging 600MB of data across the network (in the case of one of my clients), my archiving showed a reduction of like 75%, so only 25% of that was being pulled across the LAN instead. (They didn't need all the data from the beginning of the App's time...they just needed relevant/recent data.)
I realize that with MySQL and other such RDBMSes this is a non-issue, but I wanted to ask the VFP-backend folks their approach to this for the sake of (hopefully) interesting discussion. One final juicy thread before 2017 is finished. :-)
I added an archive/dearchive to my client billing app years ago. The tables that we were concerned about were the work transaction table and the invoice table. Archive up to a selected date. It is ad hoc.
Sincerely,
Gene Wirchenko
On 2017-12-29 12:18, Gene Wirchenko wrote:
At 07:47 2017-12-29, mbsoftwaresolutions@mbsoftwaresolutions.com wrote:
I've seen long-time softwares with VFP backends that had a ton of data (10+ years worth) and I had devised a method in one case recently to be able to "archive" old data by storing it in a subfolder intelligently (so it could be easily retrieved and/or reimported into the main data set). I haven't used a VFP backend since 2004 when Bob Lee introduced me to the MySQL world but nonetheless I thought I'd ask if devs here ever put anything like an "archiving" feature into their software, and how they do it. In my case, instead of slinging 600MB of data across the network (in the case of one of my clients), my archiving showed a reduction of like 75%, so only 25% of that was being pulled across the LAN instead. (They didn't need all the data from the beginning of the App's time...they just needed relevant/recent data.)
I realize that with MySQL and other such RDBMSes this is a non-issue, but I wanted to ask the VFP-backend folks their approach to this for the sake of (hopefully) interesting discussion. One final juicy thread before 2017 is finished. :-)
I added an archive/dearchive to my client billing app years ago.The tables that we were concerned about were the work transaction table and the invoice table. Archive up to a selected date. It is ad hoc.
Hi Gene,
THAT'S what I'm talking about. I'll be this feature really gives your app twice the shelf-life too since it can basically hold almost up to TWICE as much as a single maximum with this design!
Nice touch.
If staying with dbf's I would implement *local* dbc's and create local views of date-delimited data from the remote tables - hope that makes sense! This is also a good first step to moving to a remote rdms - you just change the local views in the dbc.
On 2017-12-30 05:48, AndyHC wrote:
If staying with dbf's I would implement *local* dbc's and create local views of date-delimited data from the remote tables - hope that makes sense! This is also a good first step to moving to a remote rdms - you just change the local views in the dbc.
Yep. I never used dbfs directly in my apps; I always created local views and/or cursors using an approach like Charlie Coleman showed us years ago at Central PA VFP Users Group and/or using Paul McNett's MakeUpdatable.prg (http://leafe.com/download/makeupdatable.prg).
-
AndyHC -
Gene Wirchenko -
mbsoftwaresolutions＠mbsoftwaresolutions.com