That's a good point Laurisa about who wrote it. It's kind of tough to say "yeah, I wrote it and it sucks" .... :-)

>I've also done this with several applications, all of which I wrote - would have loved to completely rewrite, but couldn't justify it to the boss. Alot would depend on who wrote the app to begin with. If you did and you were careful with variables and stuck to the "basics" the first time around, there will be some oddities (like text boxes disappearing in the running app/exe) that you'll scratch your head over, but the app should be pretty functional. I'd try converting it in a spare directory for kicks and giggles and see how it behaves. If it runs and you're not trying to add functionality (I did that too, and it wasn't pretty - but having the .dbc was a big plus.) Also depends on whether or not you do the "Functional" or "Visual" conversion. It may be personal choice, but I preferred the "Functional". Much luck.
>
>Laurisa Watkins
>Seattle City Light
>laurisa.watkins@ci.seattle.wa.us
>
>>Hi Bernard ---
>>
>>I am just finishing this type of port and have the following hints to share :-)
>>1. Keep lots of aspirin and booze handy.
>>2. Don't even try to re-use screens. Recode them. Look at the SPR files and see what the screens do then move any snippet code into custom methods of the new forms.
>>3. Change all PUBLIC variables to Application or other Custom object properties. Change all PROCEDURES to Application/Custom object methods.
>>4. Anytime you see SELECT-SQL statements, consider replacing it with a local view and refresh the view (after putting all tables into a database, of course).
>>>I have a FoxPro 2.6 application that the client wants to port without a complete re-write to VFP 6.0.
>>>Do you know if that is possible?
>>>If yes, do you suggest any tool to use or methods to follow.
>>>Also, are there any sensitive areas that I should be careful about or aware of during or after the porting process (if the latter is possible)?
>>>