I am using a fpw 2.6 and migrating

[foxwizard]

I am using a fpw 2.6 and migrating to Visual Foxpro 6.0. I have already posted this question in one of the forum which is Foxpro (versions 1 to 2.6) and hoping to get the best answer from you experts in vfp. Several records in my table produces crosslink data. This means that the information in one field was moved to the next field. For example,

Fields : Sales Branch
1.25 BD
2.50 HO
3 15 DV

By looking at the 3rd record you can see that the decimal .15 was moved to the field Branch.

My question is what causes this corruption in the table?
How can I avoid this corruption?

Thanks in advance..

Bren

 

[craigsboyd]

You shouldn't be seeing any corruption like that...when you say that you were migrating...conversion process is for the screens, reports, etc. As for the tables you shouldn't need to do anything to them except for maybe mark them with a code page (even this is not necessary)...if you added them to a database then the change made to the table's header for the backlink is no different than if you took a free table created in VFP 6 and added it to a database (DBC). So while I agree with you that your table is definately corrupted (byte shifting of some sort happend), I do not see how the migration process could have been the cause. Is there more to this story such as irregular system shutdown, odd errors when you tried to run the application after converting it, etc?

Slighthaze = NULL

[ul][li]FAQ184-2483
An excellent guide to getting a fast and accurate response to your questions in this forum.[/li][/ul]

 

[foxwizard]

Sorry for the misinterpretation.. actually the corruption didn't happen during the migration. There was no migration so far but were planning to migrate to vfp soon and that's include all of our applications and databases. However we have encountered these problems and I have no idea so far what causes these problems and how to prevent them.

Bren

 

[craigsboyd]

The chief cause of this type of thing is Irregular Shutdowns of the system hosting the application and/or the tables. (There are other causes but this is the chief among them I believe) Usually you will see the index files getting corrupted, but I have seen this with tables and with memo files as well. The problem is lessened a good deal with VFP, but it still can occasionally happen. In either event, I applaud your decision (or management's) to convert the application. If you do a Keyword search on this forum you should find quite a few threads/posts on how best to prevent and deal with this. In the case you have presented I would say that you may need a hex editor of some sort so you can shift the bytes right or left until they line up with the columns, but this is a last resort and may or may not work depending on the level of the corruption. Other automated programs you could use to try and fix your data are FIXFOXPO.EXE, SALVDBF.EXE, and FOXFIX.EXE - these are a few that I know of off the top of my head that will work with free tables. Sorry I don't know the links for downloading them also, but a search on Google or this forum should yield some links for you. You may also get some semi-acceptable results by pouring the data from the corrupted table(s) into a blank table(s) given that you are able to still open the table(s).

You will also find some threads/posts dealing with the best way to convert...having done a number of these myself I can tell you that you will want to do a Visual conversion as opposed to a Functional conversion and then cut and paste your code into the appropriate events, methods, and procedures. There are a number of other things to watch out for and plenty of tips-n-tricks when converting a FPW app to VFP so read up on it and it will save you time and headaches later (if you already have then consider this my confirming of what you already know).

Slighthaze = NULL

[ul][li]FAQ184-2483
An excellent guide to getting a fast and accurate response to your questions in this forum.[/li][/ul]

 

[foxwizard]

Thanks a lot slighthaze.... I really appreciate your response.

Thanks again!

Bren