FPW to VFP Migration

[pmbroh]

I have a medium to large 2.6 FPW application with screens developed using YAG's Flash screen development so the screen code is pretty heavy but still works great. I have another application that needs to use the tables from this application but can only communicate using ODBC. So my options are

A: Output the data to VFP shadow files with the obvious disadvantages that this creates

B: Migrate to VFP.

If I go with B are there any easier ways to do this or just use VFP to translate the files and then clean up what ever is left over. I read in an earlier post about the document that MEI put out on this. Is this still valid.

Thanks, Pete B.

 

[TamarGranor]

I don't understand why your second application can't just work with the tables from the FPW app.

Tamar

 

[pmbroh]

Thanks, for the response Tamar. Based on your response, will ODBC work fine with the old 2.6 tables. Thanks, Pete B.

 

[rwesiuc]

pmbroh:

I have migrated my 2.6 program to 6.0 by using the compiled screen files from 2.6 (.spr, .spx), programs (.prg), menus (menuname.*), and reports (.frt,.frx). Keep the original screen definitions out of the project by creating a new folder for this project and only copying the files you want to include. I created a new project and placed my main program in there and rebuilt it so it would include all the files. It was not as easy as it sounds though, some of my files in the project were not included by simply rebuilding, so I had to manually include those by hand. Also, all reports need a simple conversion to make them useable, just open them in the visual version and the conversion takes place automatically. The menu is also converted by opening it in visual. There are also potential errors lurking around by hard coded dates, unintended key words not in 2.6, but in visual. You need to debug any potential problems if you can, but it does work. I develop in 2.6 and then convert to 6 on a weekly basis. I even created some macros to help me copy recent files and convert the reports and menus.

Best of Luck!
Bob Ethridge

 

[JRB-Bldr]

Tamar's question refers to - "I have another application that needs to use the tables from this application but can only communicate using ODBC."

Is this 2nd application written in Foxpro?

If so, then why would you need to use ODBC to access the original application's data tables?

Another Foxpro application should work directly (no ODBC required) with other Foxpro tables as long as the tables were not created in Visual Foxpro (these tables would have different headers). VFP applicaitons can use down-level tables fine, but not vice versa.

As to your original question concerning converting your FPW application to VFP....

First, it is not clear from what you say above about the 2 different applications, as to how converting to VFP will aleviate your problems.

That said, there are a LOT of advantages of converting to VFP. But, as Bob suggests above, the "conversion" is not a simple task. And the VFP "translate" is not quite as good as one would hope. There will still be a lot of work to do within your screens to get them back working as before. But if you have the SPR files generated by YAG's Flash screen development, then you have the source code necessary to do the task.

I have "converted" a number of my client's FPW applications to VFP and, in most cases, I could migrate a good bit of the code, but re-writing some or all of the appliction allowed me to better use VFP's advantages.

Good Luck,


JRB-Bldr
VisionQuest Consulting
Business Analyst & CIO Consulting Services
CIOServices@yahoo.com

 

[rwesiuc]

JRB-Bldr:

One note on your comment, I am not translating the screens to VFP screens; that is where VFP does a poor job. What I have done is taken the 2.6 compiled screen files and used those in the VFP project. Try it on something simple to see what I mean. The compiled code is easily read by VFP, it is esentially a prg with an spr extension, and works so much better than a translated screen. Down the road, you then can replace pieces of your project with recreated screens. The advantage is that you don't have to do it all at once!

Thanks,
Bob