I.T. Discussion Community!
-Collapse +Expand
V.FoxPro
Search V.FoxPro Group:

Advanced
-Collapse +Expand V.FoxPro Store

Prestwood eMagazine

August Edition
Subscribe now! It's Free!
Enter your email:

   ► KBDesktop Data...Visual FoxPr...   Print This     
 
V.FoxPro Visual FoxPro (VFP):
The Situation Dictates Whether Or Not Technology Is Obsolete
 
Posted 16 months ago on 4/14/2016
Take Away:

This article discusses a real life example of how I used so called "obsolete" technology to revive a Visual Foxpro manufacturing database that was comprised by viruses.

KB102741



How many times have you heard that this software or that computer is obsolete? The “obsolete” label is readily assigned to so many different trappings of technology nowadays that one has to really wonder what is and isn’t obsolete. I would like to make the case that it's the current situation that determines whether or not a particular technology is indeed a “has been”.

One of my first ever programming customers from long ago called me at about 7:00 am on February 24, 2014. They were completely shut out of the Visual Foxpro 9 database system I had made for them. This was a manufacturing company and they could not access their orders, run job costing or look up anything – a serious fire that had to be put out! I cancelled the previous appointment I had that morning to go out there to take care of it thinking it was just some corrupted Foxpro data table indexes that could easily be recreated. It turned out to be something very different.

The person I worked with at the company informed me there had been a virus problem the previous week. I tried to re-index the Foxpro data tables, but to no avail. Every time I tried to open one of the data tables, I received a message saying something like “…not a Foxpro table…” over and over again. Apparently, the virus attack occurred on their server that contained the Visual Foxpro 9  data tables. The headers in the data tables had been corrupted to the point that Foxpro could not even recognize them as being valid data tables. To exacerbate this crisis, the back up system on their server had failed to run since January 2, 2014.

As bad as this was, there was still a silver lining to it all. Though the Foxpro data table headers had been corrupted, the data itself still seemed to be intact in each data table. At this point, I was downloading Foxpro data table repair software - one after another trying to find a quick way to remedy the crisis. They were mostly demo versions of utilities you eventually had to pay for. One or two of them seemed like they sort of worked, but I was not confident enough to go ahead and buy any of them. After fuss-bucketing around with this for a while, I decided to take a different tack and bring the ailing Visual Foxpro 9 data tables home with me to work on.

At first glance, the "technological rescue squad" I had assembled seemed rather suspect. I was going to use a 13 year old Gateway desktop computer with 256MB of Rambus memory running a Pentium 4 processor under the Windows ME operating system. I was also using Visual Foxpro 6, Microsoft Access 2000 and a small MS-DOS based Borland C/C++ 3.0  data file manipulation program I made from scratch to help facilitate the data recovery process. One had to wonder, were these ageing tools from a bygone era in computing up to the data recovery challenge I was facing?

The first thing I did for each corrupted Foxpro data table was to rename the file extensions from ".dbf" to ".txt" in the Foxpro command box as shown below:

RENAME SAMPLE.DBF TO SAMPLE.TXT               * followed by enter key press  

Then I used another proprietary Visual Foxpro 6 command to open each of the renamed ".txt" files in a Foxpro text editor as shown below:

MODI FILE SAMPLE.TXT                          * followed by enter key press  

Here, I manually removed the compromised header section of the file, which had been peppered with random characters. I tried to remove the corrupted part so the remaining data file would resemble the structure of a fixed width text file as much as possible.

For the next step, I ran it through a simple MS-DOS based Borland C/C++ 3.0 utility program I made for this task as shown below:

// specify C header files.
#include "conio.h"
#include "stdio.h"
#include "stdlib.h"
#include "dos.h"
main()
{
// declare file pointers and variables.
FILE      *cp,*dp;
long int  fileoffset, count, totalfilelength, recordlength;
// open a read only stream to the "sample.txt" damaged
// file and grab the length of the data file in bytes.
// then, rewind the file pointer to the beginning to
// prepare for processing.
if ((dp = fopen("sample.txt", "rb"))==NULL) exit(1);
fseek(dp, 0, 2);
totalfilelength = ftell(dp);
rewind(dp);
// open a append only stream to a newly created
// "samp_new.txt" file to receive recovered data
// from its damaged counterpart.
if ((cp = fopen("samp_new.txt", "ab"))==NULL) exit(1);
// initialize file offset variable to 0.
fileoffset = 0;
do {
// position file pointer at the position in the
// file stream represented by "fileoffset".
fseek(dp, fileoffset, 0);
// read the bytes from the "sample.txt" damaged file
// and write them to the new "samp_new.txt" file.
for(count = 0; count < recordlength + 1; count++) putc(getc(dp), cp);
// next, write chars for carriage return and line feed.
putc(13, cp);
putc(10, cp);  
// advance file pointer by the length of a
// record plus 1 character.
fileoffset = fileoffset + recordlength + 1;
// when the last record in the "sample.txt" file
// has been processed, exit the while loop and close
// both file pointers.
} while(fileoffset < totalfilelength);
fclose(cp);
fclose(dp);
}

The record length is the sum of the field sizes in a Visual Foxpro 9 data table plus one more character. I figured this out through trial and error. What this utility program does is rewrite the text file I created with the Foxpro “MODI FILE SAMPLE.TXT” command box directive to a different file name of the same structure (samp_new.txt in this example), but each record in the new file is terminated with a line feed and carriage return character sequence. This is done for the purpose of making the newly created fixed width text file easy to import back into an empty Visual Foxpro 9 data table having the same field structure as its corrupted counterpart. It will have a viable header section in it so as to allow Visual Foxpro 9 to successfully interpret the field structure. This worked well for the most part, though I needed to run the outputted fixed width text file for orders and storage file folders through Microsoft Access 2000. I used its data table import utility for fixed width text files to align the fields more accurately prior to importing. These two data tables seemed to be more adversely affected than the others from the virus rampage on the server. I then exported them to delimited text files from Access after this operation. They seemed to be in better shape than they previously were.

After I performed this repair operation on all the Visual Foxpro 9 data tables in the main company program, I was now ready to import the rejuvenated text files back into their empty, counterpart Visual Foxpro 9 data tables. The customer had a back up DVD of the program that was made way back in 2005. As old as these Foxpro data tables were, they were still viable. And the field structure of those data tables had not changed in all that time. So I was able to make copies of them using the following command in the Foxpro command box:

USE SAMPLE_OLD                          * followed by enter key press
COPY STRUCT TO SAMPLE.DBF               * followed by enter key press

Now I was ready to import the text files I created from the above repair operation into the Foxpro data tables. Most of the text files were fixed width, so I used this in the Foxpro command box:

USE SAMPLE                              * followed by enter key press
APPEND FROM C:\WHEREVERPATH\SAMP_NEW.TXT TYPE SDF
                                        * followed by enter key press  

For the two text files that were of delimited format, I simply did this:

USE SAMPLE                              * followed by enter key press
APPEND FROM C:\WHEREVERPATH\SAMP_NEW.TXT TYPE DELIMITED
                        * followed by enter key press

The Visual Foxpro 9 program itself was fine, since I had immediately restored it from one of my own multiple back up copies. At this point, all I had to do was rebuild the compound index tag files (.cdx) on the newly restored data tables from the application's re-index menu and they were off and running…erralmost.

By February 25, 2014 the Foxpro database application was essentially back up on its feet again, though there were still some residual issues to be fixed. One problem they had was being able to search the storage file folders by shop order number. It wasn’t working and I later discovered the shop order numbers in its data table were all preceded by a space character. So I made this jiffy Foxpro utility program to quickly remedy this snafu as shown below:

* this will left justify the shop order number
* for storage file folders so they can be successfully
* searched for. the preceding space before this field
* from the “modi file…” dbf repair was throwing off
* the search capability for this field.       
SET DEFAULT TO Z:\FOXDATA  
SELECT 1
USE STORGFILE
GO TOP
DO WHILE .NOT. EOF()
REPLACE STORGFILE->SHOPNUM WITH LTRIM(STORGFILE->SHOPNUM)
SKIP
ENDDO
USE

Another glitch with all of this was the fact that their “open orders” report was running 91 pages long, when it should have only been about 2-1/2 pages based on the one they showed me from February 20, 2014. So I made another one of my Foxpro utility programs to correct this headache as shown below:

* sequentially loop around the orders data table.

SET DEFAULT TO X:\FOXDATA

USE ORDERS
DO WHILE .NOT. EOF()

* this will populate the “invdat” (invoice date)
* field in the orders data table for records where
* the invoice date is erroneously placed in the
* satellite company’s shop order number field. this
* was a snafu that the c language utility program i made
* and microsoft access 2000 could not adjust for. the
* first 2 characters in the satellite company’s shop
* order number field must begin with “19” or “20”,
* indicating it was an erroneously placed invoice date.
* the “invdat” field for where these conditions are true
* will be set to a date with the same month and year as
* found in the satellite company’s shop order number
* field with “01” set for the day of the month. then
* the satellite company’s shop order number field will
* be blanked and the next order record will be processed.

IF !EMPTY(ORDERS->SAT_SO)
IF SUBSTR(ORDERS->SAT_SO, 1, 2) = "19" .OR. SUBSTR(ORDERS->SAT_SO, 1, 2) = "20"
YEARVAR = SUBSTR(ORDERS->SAT_SO, 1, 4)
MONTHVAR = SUBSTR(ORDERS->SAT_SO, 5, 2)
RECONDATEVAR = MONTHVAR + "/01/" + YEARVAR
NEWDATEVAR = CTOD(RECONDATEVAR)
REPLACE ORDERS->INVDAT WITH NEWDATEVAR
REPLACE ORDERS->SAT_SO WITH ""
ENDIF
ENDIF

* IF THE INVOICE DATE FIELD IS EMPTY (NOT YET
* INVOICED) AND THE ORDER DATE IS LESS THAN
* DECEMBER 16, 2013, THEN ASSIGN A “PHANTOM
* DATE” OF NOVEMBER 11, 1911 TO THE INVOICE
* DATE FIELD. THIS WILL PREVENT MANY OLDER AND
* UNNEEDED RECORDS FROM APPEARING ON THE OPEN ORDER REPORT.

IF EMPTY(ORDERS->INVDAT) .AND. ORDERS->ORD_DATE < CTOD("12/06/2013")
NEWDATEVAR = CTOD("11/11/1911")
REPLACE ORDERS->INVDAT WITH NEWDATEVAR
ENDIF
SKIP
ENDDO
USE

The main Visual Foxpro 9 database program was now functional. There were still some other problems I had to iron out. This company also had Visual Foxpro database applications for a large customer they used to do a lot of business with as well as a satellite company they owned that no longer utilized the program that was made for them. Their orders are now  processed through the main company program. However, they wanted to retain these two other Visual Foxpro applications for occasional future reference.

Now here's the weird part. In the beginning of this emergency, I tried to open the Foxpro data tables for the main company on the company's Windows 7 computers running Visual Foxpro 9 as well as my old desktop computer running Windows ME with Visual Foxpro 6. None of them would work. I had to manually rebuild them as previously described. None of the old company Foxpro data tables would open on the company’s Windows 7 / Visual Foxpro 9 system. However, they all opened up on my Windows ME / Visual Foxpro 6 system – darndest thing you ever saw! There was obviously something about Visual Foxpro 6 and/or the Windows ME operating system that enabled processing of the old company Foxpro data tables. This turned out to be a huge savings of work and time for me. All I had to do for each of these data tables was export the contents out to a delimited text file as shown below:

USE SAMPLE                               * followed by enter key press
COPY TO SAMPLE.TXT TYPE DELIMITED       * followed by enter key press

After doing this, I opened each of the corrupted data tables and copied out their structure to new data tables like this:
USE SAMPLE                               * followed by enter key press
COPY STRUCT TO SAMPLE_NEW.DBF           * followed by enter key press

Then I imported the delimited text files into each of their empty counterparts like this:

USE SAMPLE                                            * followed by enter key press

APPEND FROM C:\WHEREVERPATH\SAMPLE_NEW.TXT TYPE DELIMITED
                                                              * followed by enter key press

Next, I re-indexed the restored data tables in each of the two other Visual Foxpro 9 application programs and that was it! This story reinforces something I have begun to notice in recent years. When faced with a highly involved data recovery operation, the line between troubleshooting techniques and programming techniques becomes increasingly blurred. I call them “hybrid data recovery” jobs, because they aren’t all programming or all troubleshooting, but rather a mixture of both.

Like beauty, obsolete technology is in the eye of the beholder. I have to believe many other IT people have been in predicaments where the “old guard” technology may have been the best solution for a major disaster. Now don't get me wrong, I’m certainly not writing off the newer technology. It does many terrific things that make computing a breeze for so many. But you can’t be so quick to dismiss the older, so called “obsolete technology” either. One day it could be the lifeline you need to get out of the quicksand.


Comments

0 Comments.
Share a thought or comment...
 
Write a Comment...
...
Sign in...

If you are a member, Sign In. Or, you can Create a Free account now.


Anonymous Post (text-only, no HTML):

Enter your name and security key.

Your Name:
Security key = P1164A1
Enter key:
Article Contributed By Douglas.M:

Please visit my software developer website for more information about my services. I offer application development as well as Android app coding services. My developer skills are best suited to dealing with custom software projects. I can perform programming for Corel Paradox as well as C# Sharp and PHP.

In my local area of northeast Ohio, I can cater to computer repair and "fix my computer" issues.

Use my contact web page today to reach me about any software design ideas you have.

Be sure to check out my blog on Tumblr.

Visit Profile

 KB Article #102741 Counter
1219
Since 4/14/2016
-
   Contact Us!
 
PrestwoodBoards.com was developed and is maintainted by me. Do you have a question or suggestion? Do you see a problem? Contact me now. My goal is to build an ad-free and spam-free source of I.T. information with many contributers (ok to promote your website/company in your bio). Yes, my company Prestwood IT Solutions is mentioned in my bio which shows with every post, but you can contribute and promote your pet project too!

2,047 People Online Now!!  
Sign In to see who's online now!  Not a member? Join now. It's free!
Show more stats...


©1995-2017 PrestwoodBoards  [Security & Privacy]
Professional IT Services: Coding | Websites | Computer Tech