Complications between foxpro 8 and foxpro 2.6A

[ShortyII]

Hi I have the following question:
We are migrating away from foxpro 2.6A to foxpro 8.0
The question is now are there know errors between these two environments
I have been reading about some things on the Internet.
Like if you want to reindex a table you have to do this from the 2.6A environment because if you do this from 8.0 he will change the table layout and 2.6 isn’t able to work with it anymore.

Also I get every time the question overwrite invalid foxuser file with new empty one?
If I open a 8.0 app and then a 2.6 app

Thanx for the info you can give me.

 

[ramani]

Hi

You are migrating. That is a good step.

Are you going to operate both the applications. Then you have to take care, since the database structures are slighlty different. Then you have to reindex etc. from Fox2.6a. The later system will know the earlier system, but will reqrite as per newer one. So when you go back to FP, that will not know the newer system.

If you are going to migrate in total and forget FP once for all and continue with VFP, then you have to take care of only the convertion issues and forget about not being able to open in earlier system.

That is the problem, you face with the FoxUser.DBF and the consequent question you are answering in VFP. WHen you start in FP, the foxuser.dbf gets replaced by FP2.6 one, since it assumes the FoxUser.DBF is corrupt (the one left by VFP.). So you dont get a question.



ramani
(Subramanian.G)

http://winnersoft.coolfreepages.com/

 

[ShortyII]

But that is according to you the only thing i have to take into considuration?

Do you know how i can cancel the question from foxpro 8.0 to change the table from 3.0 to 6.0 ??

 

[wgcs]

SET SAFETY OFF might remove the question, and just do it.

It's possible to reindex in VFP6 so that Fox2.x can read the tables: Just create tables with a "fake" name (like PeopleX instead of People) then "COPY TO People TYPE Fox2x" before indexing. Then Fox2x can still read the tables.

As for the FOXUSER.DBF you can have two different CONFIG files in the same directory: CONFIG.FP (for dos) and CONFIG.FPW (for VFP), and specify the resource file in each (I don't remember the exact config file line to add, but just have Fox2x.dbf and FoxVFP8.dbf).

Other things to think of: Screen files are stored in the same file name/extension (.SCX/SCT), but different internally.

The whole architecture of your app under VFP should be different, so DON'T try to share code beyond simple utility functions. I've done it: It's like programming in VFP with a lead shoe: It takes forever to really realize its benefits.

 

[dbMark]

These are common ways to upgrade:

1. Design, write, test and debug the new application in a separate but duplicate set of real data. Compare results. If the two data sets are identical after both processes are run side by side in parallel environments, then you can switch over.

2. Rewrite the code gradually, section by section. While each new piece still needs to be tested before being implemented, the advantage is that you can bring in new and improved functionality now without waiting until the whole project is completed, but the disadvantage is you're doing extra coding simply for compatibilty between the two versions.

It sounds like you're probably migrating from FP to VFP piece by piece. It is difficult and sometimes frustrating but it can be done with proper planning. Identify and prioritize areas where (1) the new program enables desperately needed functions and (2) where the new code has minimal impact on the majority of the current data structure.

As you noted, VFP has an enhanced table structure that old FP cannot read. The others have given suggestions above on how to create the old table structure. Your challenge wll be to design ways in which the 2 systems can coexist until the port is completed.

Right now I am developing in such a situation where the old DOS application is simply too huge to port all at once but until converted it still needs enhancements in the meantime. We first examine each request and determine if VFP can do it without impacting the current DOS application overmuch. If not, then we update the old DOS application. The final conversion project will be a huge undertaking, but for now we choose our battles, giving VFP as much of the code as possible.

 

[terosoft]

Another solution for the index files is to change the default index file extension in VFP, so you can maintain your old IDX/CDX files for FP26 and ?DX for VFP.
See 'Special Terms for Configuration Files' in VFP help for how to change the default extension and other useful stuff.

 

[wgcs]

However, if you do this, then when VFP updates the data, the FP26 indexes won't be updated, and when the table is reopened in FP26, the new records (when an order is set) will seem to not exist, until a REINDEX is issued.

 

[ShortyII]

Yes wgcs thats the thing that happend to me today.
But i didn't change the names of the indexfile.
He still uses the same as 2.6 but when i insert a record the index isn't updated???

Do i have specify somewhere wich index type i use???

 

[wgcs]

What kind of indexes are used in Fox2.6? If it uses .IDX files, the index has to be opened for it to be updated (whether it's in Fox26 or VFP).

If it uses CDX files, then they should be working correctly... I wouldn't know a reason for the problem.

(the difference in creating the indexes are:

INDEX ON expr TO indexname && creates .IDX
INDEX ON expr TAG indexname && creates .CDX

 

[terosoft]

Hi again!

What they say about different index files is true, but is a possibility you may consider as VFP indexes can be more complex than FP2x ones.
Also, maintaining FP2x-compatible tables in VFP forbids the possibility of using several advances like the use of a data dictionary (DBC file).

If may I ask, what level of migration are you trying to achieve?

I've taken part in a couple of FP26 to VFP7 migrations and the team decided that the database structure was also obsolete, so we migrated the data to a improved and best normalized SQL database and wrote a special module on the new system to translate shared data from the old DBF structure to SQL and vice-versa, and when the system migration concluded the module was disabled.

I made some searching for you and found a small free e-book in PDF format that describes different migration processes between FP2 and VFP6, maybe you can give some use to it.

You can find it at

http://www.appdev.com/info.asp?page=foxmig

but needs a free registration first, if you don´t want to register let me know and I´ll e-mail it to you (580Kb approx.)

 

[DanaAnderson]

If you have been using Stonefield AppMaker, or even just GenscrnX, it will be best to simply use the generated *.spr files as programs and work on replacing them with newly designed forms. If you try to convert the project, you may likely run out of disk space. I tried this a while back. I found that because of the 3D effects that GenscrnX (which Stonefield AppMaker uses) each object on the form (textbox, button, checkbox, etc.) became a group of that object type with one member in the group. Pages became pageframes with a single page. The size of things blew out of proportion in no time.

Calling the .spr files as a program works fine, and this gives you the ability to hit the ground running and work on replacements with the new features of VFP at a less maddening pace. This is of course aside from issues regarding the data structures.

Dana