Transitioning Foxpro-Prolog 3

[amros]

Hello all,
I have never worked with FoxPro-Prolog languages. However, I am assigned a project that will help convert this project to the latest language.
The problem here, in addition to being a newbie, is that the version of FoxPro that is currently being used is version 1.8
The project is that, FoxPro 1.8 has the DB, some 20 odd DBF files. And then there is a prolog script that runs in the foreground. There are at least 15 prolog scripts and I do not have any idea to the sequence of these scripts. Each of this script is about 300o lines long.

The UI is a DOS based screen that the user enters values. Based on those, calls to some tables are made. Some complicated statistical calculations are done on this data which then gets inserted into these tables.
The complexity of this program is high. Also what complicates it further is that there is no documentation at all, which make my life so much fun. The people that are currently working with this program, have no idea about the tables, what is there in the tables and the logic for the script. All they know is what data to input and what screen comes up next and what to do in that screen and then print this information.

The computer, on which this project is running, has never been updated for the fear of breaking this program. I have a couple of dilemmas:
1. If I extract the data from the FoxPro databases and start writing the program from scratch it would take tremendous effort and not to mention the fact that the people actually using this have no idea what is happening. To get the logic, I would have to talk to an in house scientist, which I hope has some idea,

So, I am hoping that is there a way I could use this program in today’s environment. Maybe write a script in windows environment that actually has its own UI, but when u click a button on the new UI, it calls the old program, or in essence actually connects to the old screen and that in turn calls the FoxPro. So I would need something that could compile this combination of FoxPro and Prolog.


2. The second would be to extract the FoxPro information and bite the bullet. I managed to extract the data from all the tables expect one which has 250,000 rows or such. The method that I was using was that, open the DBF file in excel. Save it as excel and then open it in access. I can’t do that in Excel since Excel allows only 65000 rows. All the remaining data is lost. If I open the file directly in Access, by using the import option it gives me a error “Unexpected error from external database driver”. I think its giving me the error since the oldest version of DBF files that is there, is DBF III. And the version of my file is older than that. So I need some advice as to how to get the data put of there.


3. Also, any documentation on FoxPro 1.8 or Prolog. And how those two works together would be very helpful.

Has someone done a project like this? If yes, what was the strategy?
If no, what would be the best possible strategy to go about this project.
I would appreciate any guidance of any sort.
I am pretty clueless at this point.
I appreciate any help.
Thanks in advance
Rosalia

 

[JRB-Bldr]

I am not qualified to offer suggestions as to what Prolog is doing for this application nor if it needs to be migrated at all, but I can speak to the Foxpro part.

If the majority of the code is in Foxpro, it can, in general, be migrated as operational code into the newest version.

The user interface screens and likely the reports will most likely need to be re-created especially if this old code is in one of the FP for DOS versions, but the code such as the statistical computation code will most likely be able to move un-modified.

Don't bother attempting to get DBF file data out using Excel. That approach will most likely modify the fields and the contents into an un-usable format - such as converting String fields into Number values or vice-versa. And you have possibly already experienced the 65,000 record limit of Excel which would cause you to lose data table records.

In the vast majority of situations, the DBF data can be used as-is in another FP or Visual Foxpro (best choice) application. Yes you might WANT to modify the data tables, but it is not usually essential.

Many of us on these forums have tackled tasks such as you are describing and admittedly it was not easy.
Sometimes it was easier than other times, but it is still not a small effort.

You mention that there is no documentation. Well the first step will be to make some of your own so that, at the very least, you can have a 'road-map' available when you migrate and modify the code.

Even a very Macro-level understanding will be helpful such as:
1. When I do this, it should, in general, do that...
2. What do I need to enter and where to enter it so that I can get this or that to work...
3. What options are presented to the user on which screens/forms...
4. How many screens/forms make up the entire application
5. Etc.

Good Luck,


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

 

[DSummZZZ]

Just a thought here, but when you say 'Prolog', are you by chance referring to the .PRG (program) files?
If so, there is somewhere a starting point - i.e., 'MAIN' .prg which calls the rest of the routines. It could be named MAIN, or it could be named something akin to whatever the name of the application is.

One way or the other, you should be able to determine the starting point and find the order of execution by finding the "DO subroutine" commands in the code.
Also look for FUNCTION and PROCEDURE clauses in those .PRGs. They'll also be called somewhere in the other routines.


-Dave Summers-

Even more Fox stuff at:

http://www.davesummers.net/foxprolinks.htm

 

[Stella740pl]

Dave Summers,
I think, when Rosalia here mentions Prolog, she is not referring to .PRG files, but to the creation described in this article

http://en.wikipedia.org/wiki/Prolog

and discussed in forum345.

Rosalia, I have a question to you.
When you mention converting the project "to the latest language", which language do you mean? Do you have it already? Can you choose, or you are restricted to some already pre-selected for you tools?

I don't know about Prolog (heard about it years ago, never seen it), but the FoxPro part is best converted into the latest versions of Visual FoxPro (9 is the latest one). For that, you got good tips from JRB-Bldr and Dave Summers.

If that's not what you have in mind, you will have a much harder time.

 

[amros]

Thank you JRB-Bldr for the valuable post.
You said migrating the FoxPro as am operation code would be best. To go down this path, I would download Visual foxpro 9 And then use a migrate option for operational code?
Is there any documentation for this.
I think it is better for me to go this route, Since I do not know what the data in the file is, I cannot confirm and say that, "yes this migration is a success".
I think as you said I might have corrupted some data by my old migration process.
Thanks so much again.
regards

 

[amros]

Dear Dave and stella,
The are some 20 .PRG files. I am assuming these files are Prolog since I have never worked with them before.
These PRG files is what creates a screen and do the computational work of data insertion and manipulation.

Dave,
There is no MAIN.PRG
there is however a Cellx_Main.PRG. That does have the refernce to some other PRG's. Maybe that is the sequence.

Stella,
I honestly have no idea as to what latest language we need to migrate too.
I am open to any suggestions as to what will be the easiest way to do this.

Any suggestions would be very very helpful.

Thanks in advance

 

[Stella740pl]

Rosalia,

The are some 20 .PRG files. I am assuming these files are Prolog

Then, I think, Dave is right, and there is no Prolog involved. Those .PRG files are FoxPro program file. Can you open one of them in any text editor (NotePad or WordPad would do) and post a sample of the code, just to confirm?

there is however a Cellx_Main.PRG. That does have the refernce to some other PRG's. Maybe that is the sequence.

Of course. And some of those referenced may also have reference to others.

...I would download Visual FoxPro 9 And then use a migrate option for operational code?

You don't just "download" Visual FoxPro, you buy it. I remember that the full retail price used to be around $650 per developer - but that was some time ago. It is possible that it went down since then, or you may get some group discount, you have to look into it. What you do download are service packs available for free for those who already own VFP 9.0. I think, converting FoxPr to Visual FoxPro is the easiest way you can take.

You will need to create a project in VFP9 and add there your existing files. (As for now, you may open them with a text editor and learn, what's inside and how it works. You can use VFP 9 or earlier versions documentation and Help on the Microsoft site to learn what those commands are doing. A lot of them are still there. Here:

http://msdn.microsoft.com/en-us/library/ms950411.aspx)

Depending on the code you already have, you may need to set some settings to make it compatible with older versions. After that, those calculations should work in the new version.

As for the user interface, you will probably need to create new forms (screens), but it is done mostly graphically in all new versions. It might make it a little easier for you to learn.

Depending on how the reports are created you might be able to keep them, convert them or may need to recreate.

I think, the tables should open in VFP just fine, too - as far as I remember (if you want to convert them to VFP9 tables later, you might do that).

 

[JRB-Bldr]

Lets begin by asking how do the users launch the program.

Do they launch it from a DOS prompt or a Windows icon?

If from a DOS prompt, it it an EXE file that they launch or something else?

If it is from a Windows icon, look at the shortcut properties to determine what is launched.

This will help determine something about where to begin.

If the users launch an EXE file then we need to find a .PRJ (Project file) which is used to compile the source code files into an EXE.

If the users launch something else then that will be the 'MAIN' program or some version of it (perhaps a .APP, .FXP, or.SPR).

Now as to the .PRG files - those are Foxpro source code (Program code) files for the program. It is good that you have those since a De-compile, while a viable option, often increases the complexity of things in general.

As Stella accurately points out if this application has intricate computations in it, the simplist approach would be to migrate into another newer version of Foxpro (Visual Foxpro 9). In that way you would not have to totally re-create the computational code as well as all other code into a completely different language.

The migration will be a little more complicated than just running them within the VFP environment - especially if you want to have the code appear as though it belongs in the 21st century.

I am sure that each of us has their own style as to how to approach a migration like this and even within that style there are variations depending on how much we want to change about the code.

Personally were I in your shoes I might begin by getting familiar enough with the basics of the language (most all Foxpro commands & functions are still used in Visual Foxpro 9) so that I could 'read' the code and generally be able to differentiate between Screens, Reports, and other code.

Then begin to segment the code (if not already done) into the separate primary categories. That would allow me to begin to strategize what will have to be re-created within the new VFP and what might be able to migrate as-is.

Again I will highly recommend that you survey/observe the users to create your 'roadmap' documentation of what you want your end-result to do.
1. When I do this, it should, in general, do that...
2. What do I need to enter and where to enter it so that I can get this or that to work...
3. What options are presented to the user on which screens/forms...
4. How many screens/forms make up the entire application
5. Etc.
Knowing that information will make 'reading' the code much simpler since you will have a good idea what it is that you are looking for within the code.

Even knowing simple things such as:
Screen #5 says "PRESS 1 FOR UPDATE"
will enable you to look for that text string within the code and determine where that code might be located.

As to "I might have corrupted some data by my old migration process" -

The data corruption, if it has occurred, will be in the migrated data, not in the data within the DBF data tables. That should been un-changed unless from excel you saved it back out into the same filename with the same extension (.DBF).

If you did your data migration testing (or 'live' migration) on a COPY of the data as would have been recommended, then the original data is intact and can be used as-is within the new VFP version of the application.

Keep us informed as to how we can help...

Good Luck,


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

 

[Stella740pl]

I have to second JRB-Bldr and emphasize again the importance of backing up ALL your files before doing anything at all to it (possibly, even before simple opening), and even to more than one place/carrier. Leave the original intact, and work on one of the copies. Then, if something goes wrong (and it often does), you can always revert to the original version and start that part over or try a different way.

 

[amros]

Hi Stella,
Thanks for the valuable post. I appreciate you clearly the confusion due to my lack of knowledge regarding the involvement of prolog.
I am pasting some code at the bottom of this post for your refernce.
I think you advice about buying Visual FoxPro would be something definitely to look into.
However I do have a question regarding that.
Do u think that I would be able to migrate the foxpro application of version 1.8, a DOS version, to Visual foxpro9?!


If I could migrate the DBf files, my reports as well as create a new UI, I think it would be fantastic approach. I will definitely look into it. And thanks for letting me know that you have to buy it ?

I will definitely look into the MSDN forums and get myself more acclimated with visual Foxpro.
Thank you so much for your advice. It was very valuable and much appreciated.
And I will also keep in mind the advice of backing up. I already have done that. I am working on a copy of the live data.
Regards





Code:
* CLX_MAIN.PRG
CLOSE ALL
CLEAR ALL
RELEASE ALL
RELEASE POPUPS
RELEASE MENUS
RELEASE WINDOWS
SET ECHO OFF
SET DEBUG OFF
SET EXACT ON
SET TALK OFF
SET STATUS OFF
SET HELP OFF
SET BELL OFF
SET MENUS OFF
SET SAFETY OFF
* SET ESCAPE OFF
SET ESCAPE ON
SET SCOREBOARD OFF
SET DISPLAY TO VGA25
SET DELETED ON
SET CENTURY ON

ON ERROR DO err_fix WITH ERROR(), MESSAGE(), MESSAGE(1), PROGRAM(), LINENO()

DO WHILE .T.
* ---Display main menu and get choice.
mainchoice = '2'
DO CLX_MENU WITH mainchoice
* SET COLOR TO G/N,N/W
DO CASE
CASE mainchoice = "0"
EXIT
CASE mainchoice = "1"
DO CLX_SEND
CASE mainchoice = "2"
DO CLX_UPD
ENDCASE
ENDDO


* closing operations
SET COLOR TO GR+/N,N/W
CLEAR
CLOSE DATABASE
CLOSE INDEX
SET SCOREBOARD ON
SET ESCAPE ON
SET SAFETY ON
SET MENUS ON
SET BELL ON
SET HELP ON
SET STATUS ON
SET TALK ON
QUIT
RETURN

* =================
PROCEDURE CLX_MENU
PARAMETER choice
SET COLOR TO R+/N,N/W
set talk off
set status off
CLEAR


menuhdg = "CELL EXCMANGE MAIN MENU"
col = (70 - LEN(menuhdg)) / 2
@ 1,1 TO 19,79 DOUBLE
@ 3,2 to 3,78 DOUBLE
SET COLOR TO GR+/N,N/W
@ 2,col SAY menuhdg
SET MESSAGE TO 21
menuchoice = AT( choice,"0123456789A" )
col = 25
@ 5,col PROMPT " 0. Quit " MESSAGE "Return to DOS"
@ 6,col PROMPT " 1. Generate next sendout " MESSAGE ;
"Next message city/st DOS file = CLXADDR.TXT"
@ 7,col PROMPT " 2. Update records " MESSAGE ;
"Update the message centers"

---Press <ESC>, <Return>, <PgDn> or the first character "1"..."N".
* ---Assigns 0 (on <ESC>) or 1 thru N to menuchoice.
MENU TO menuchoice
choice = SUBSTR("00123456789ABC",menuchoice + 1,1 )
* ---Release MESSAGE row.
SET MESSAGE TO
RETURN
* EOF: CLX_MENU.PRG


PROCEDURE err_fix
*-- multiuser error handling routine
PARAMETER errnum, mess, mess1, mprog, mlineno

@ 23,0
DO CASE
*-- file is locked
CASE errnum = 108
TIME = 0
DO WHILE .NOT. FLOCK() .AND. TIME < 1000
TIME = TIME + 1
ENDDO
IF TIME < 1000
@ 23,0
UNLOCK
RETRY
ELSE
@ 23,0 SAY "File can not be locked.."
WAIT "Try again later..."
quit
ENDIF

OTHERWISE
?
? ' <<<<<< Refer these messages to the programmer >>>>>> '
?
? 'Error number: ' + LTRIM(STR(errnum))
? 'Error message: ' + mess
? 'Line of code with error: ' + mess1
? 'Line number of error: ' + LTRIM(STR(mlineno))
? 'Program with error: ' + mprog
?
? ' <<<<<< Refer these messages to the programmer >>>>>> '
?
WAIT
CLEAR ALL
RETURN TO MASTER
ENDCASE
return
* EOF: ERR_FIX.PRG
*==================


RETURN &&-- CLX_MAIN.PRG

 

[amros]

Hi jrb-bldr,
I am follow up on the question on how they launch and will let you know of that. I do not have access to that box and the personnel in charge is out at the moment. I will get hold of someone else.


I will be surely taking up the advice given by you to migrating to the newer version of Visual foxpro 9.
However I do have a question regarding that.
Do u think that I would be able to migrate the foxpro application of version 1.8, a DOS version, to Visual foxpro9?!


“The migration will be a little more complicated than just running them within the VFP environment - especially if you want to have the code appear as though it belongs in the 21st century.”


My main prime focus with this application was that to get it out of the archaic 1.8 version to something more feasible today. The reason being they aren’t even updating the machine.
Could you please explain what would be the main differences between the two scenarios? I do not want to modify the logic at all. The reason, Why I thought I would have to re-do the code was because I thought there was no way that I could make the .PRG files work or migrate them into anything.
If I could run the old program, in the new VFP environment then I guess that would be fine it right?
It would achieve the main purpose of getting the application to a newer version that can be run on Windows XP.

As per your suggestion, I read up on the basics of the language.
Besides MSDN is there a tutorial that you would suggest?
Thank you so much for your advice. It was very valuable and much appreciated.
Regards,

 

[Stella740pl]

Rosalia,

The code you posted is FoxPro, absolutely.
And a lot of it would still work.
True, a lot of seriously outdated stuff (like all those @...), but would/might still work. Visual FoxPro source code still have .PRG extensions, by the way.

Do u think that I would be able to migrate the foxpro application of version 1.8, a DOS version, to Visual foxpro9?!

Well, no one said it's going to be easy, but it is doable. If the code is properly structured and business logic/calcualtions is separated from settings and user interface, then you will have an easier time than if it is all lumped together. You can keep those programs that are making calculations intact, and create all new forms, etc. You should also take care of multiuser issues (which seem to be addressed in your old programs).

If I could run the old program, in the new VFP environment then I guess that would be fine it right?
It would achieve the main purpose of getting the application to a newer version that can be run on Windows XP.

If running it on Windows XP is the main purpose, the first thing you should do is try and run it. Not in the "new VFP environment", but the way they run it now. Take a look what program/batch file/shortcut/executable/whatever else they are running now, transfer everything to XP to the same directory names/structure, and try running. It may - just may - still work. It may throw you a few fixable errors, and may then work after you correct them. It will look last century, though. If you can make it work, it would be running in the DOS Command Prompt window or full screen in DOS mode.
I would definitely try it out in the new environment first and try to make it work before starting the transition/rewriting some parts.This way, you would get a better feel of what part/command does what, how everything works and looks.

As per your suggestion, I read up on the basics of the language.
Besides MSDN is there a tutorial that you would suggest?

Take a look at the books recommended here:

http://www.ml-consult.co.uk/books.htm

This site belongs to Mike Lewis, one of the MVPs of Visual FoxPro forums here, on Tek-Tips (and, I think, also MS VFP MVP). He also has lots of great Visual FoxPro articles:

http://www.ml-consult.co.uk/foxstuff.htm.

Or see what this site recommends:

http://fox.wikis.com/wc.dll?Wiki~GoodVFPBooks

Books authored or co-authored by Tamar Granor or Marcia Akins (both are VFP MVPs and MVPs of VFP forums here) are usually very good.

Here are VFP forums you might need to ask questions once you start transition/rewriting your app.
forum1252
forum184
forum1254
forum1251
forum1253

 

[DSummZZZ]

amros,

Just for grins, I copied and pasted your code snippet into a file named CLX_MAIN.PRG. I got one compile error, which was the following line:

 ---Press <ESC>, <Return>, <PgDn> or the first character "1"..."N".

. No biggy though, I think you may have missed an '@...SAY' as you copied it. After adding that, the code ran just fine.

Of course the calls to other .PRGs failed since they don't exist on my machine, but they did properly execute the error handler.

In short, I think that if you were to run the application in VFP 9, you would at least be able to keep the users working while you performed the proper conversion to VFP in a test environment.
And once you got used to VFP, I'm sure you would really appreciate all the additional features and capabilities.


jrbbldr,
Not that it matters, but wasn't version 2.5 (maybe 2.0) the first version where you could make executables? I thought everything up until then was all runtimes.



-Dave Summers-

Even more Fox stuff at:

http://www.davesummers.net/foxprolinks.htm

 

[JRB-Bldr]

Stella has provided you with a lot of good references.

"I do not want to modify the logic at all"
Well you might just have to change your plans.

The application you have has everything in code (a.k.a. Logic).

All of the 'menus', all of the 'screens', all of the 'reports' are all in code in addition to the computational code.

In order to get just the 21st century look in the screens, the 'code' will have to be changed. You will have to eliminate the screen-specific code and replace it with 21st century Visual Foxpro Forms and code.

Changing the menus, and the reports will also require changes to the code.

Even the small sample of code you provided from CLX_MAIN.PRG has a DOS-Style screen-menu CLX_MENU in it which to come into the 21st century would need to be replaced by a VFP Menu or a VFP Form.

Typically when you make a migration like this, you plan on keeping the computational code and re-creating all new User Interface screens, reports, and menus using the new version code.

Just so that you can understand your above code somewhat better it appears to the the 'main' program where a user begins executing the application.
It will display an old DOS-style character -based screen-menu and allow the user to make a numerical choice. Once the user makes their choice the program will then branch off to execute another PRG file (working as a sub-routine)
Example:
When the user enters '1', the program will execute the
DO CLX_SEND
which will branch off to execute
CLX_SEND.PRG or a PROCEDURE CLX_SEND

Very in-line procedural code, it can be followed relatively clearly one line at a time from the start to the finish.

My recommendation of creating a 'roadmap' of your code may assist in this migration.
1. "You don't know that you have reached your destination if you don't know where you are going!"
How will you know if you have all the pieces migrated if you don't know what all the pieces are and what they are expected to do?
2. It will allow you to separate out large sections of code (like the main menu above) and just set it aside to be re-developed.

As to books... HentzenWerke is where to get the most VFP books:

http://www.hentzenwerke.com/catalog/zcatalogsubject.htm#visualfoxpro

Good Luck,



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

 

[amros]

Hello Jrbbldr,
Thanks for all your suggestions.
I have answers to the question about the access of the application.
They access it via a shortcut on the desktop.
It is a shortcut to the CLX_M.PRG file.

However in the shortcut, under its program properties,
in the CMD line E:\CellMain\Cellx\FOXPROL.EXE CX_MI is listed.
Also I think the working directory is listed.


There isn’t any .PRJ file in the working directory.
regards
R

 

[amros]

hello All,
So stepping back for a moment, if I wanted to go down the painful route of extracting just the data from the FoxPro tables and then re-writing the code, is there any other tool that can help me extract the entire data without compromising its integrity.

Thanks in advance
R.

 

[JRB-Bldr]

The fact that the users launch the app via the shortcut like you describe above confirms our above suspicions that CX_MI is the 'main' or first program off of which all other parts will be executed.

Somewhere off of that program (PRG file) there must be a call to CLX_MAIN.PRG which would display the menu on-screen.

For the moment lets discuss terminology...
* The 'Data' is indeed in the various Foxpro tables, but not the executable code.
* The 'Code' works upon the data, but does so within one or more program file(s) and then either displaying the results on-screen, to a printer or writing the results back to a table.
You would re-write the 'Code' which is in the variety of PRG, etc. files (program files - not tables), but the data would not be re-written.

If you were to re-write some or all of the code, you very likely would not need to do anything with the data in the tables.

You could indeed migrate the data into a more modern VFP data table, but it would typically not be required. In most cases you can use it as-is.
However, if you were to migrate the data the simplist would be to use VFP to do the job.

 USE OldTable
 SELECT * FROM OldTable INTO TABLE NewTable

While I have never been happy with the results and ended up re-coding a good number of components you can try using the VFP Application Conversion wizard.

From the VFP Help files...

This version of Microsoft Visual FoxPro protects your investment in applications built in previous versions of FoxPro. In Visual FoxPro, you can run FoxPro applications without changing them. You can modify and enhance applications using the Visual FoxPro language — knowing that extensions to the language do not affect backward compatibility. In addition, you can convert FoxPro screens, projects, and reports to Visual FoxPro format. It is possible that a behavior or feature change in the current version of Visual FoxPro has slightly affected existing Visual FoxPro source code. Please refer to the Behavior Changes since the Previous Version topic for more details. Behavior changes rarely affect existing code, but when they do, the remedy is very simple.

If you choose to convert your dBASE or FoxPro files to the Visual FoxPro format, you can take advantage of the unique features of this version of Visual FoxPro. You can run many files from some previous versions of FoxPro directly; others require varying levels of conversion.

You can convert most projects or components created using previous versions of Visual FoxPro simply by opening or recompiling them in this version of Visual FoxPro. When you recompile components, such as forms, screens, or reports, some modifications may be necessary. You can make modifications to these components in the same way you modify the components of this version of Visual FoxPro.

Personally I have not used the VFP Conversion tool for a LONG time, since converting a FPW2.5 app to VFP5 quite a few years ago.

However, consistent with the above VFP Help file info, Dave Summers has suggested above that you might get away with merely re-compiling a copy of your old code into VFP and it might run.

Actually Dave's experiment suggests that 'Conversion' might not even be necessary at all to get the code at least somewhat operational.

If that worked, it would get the migration project off-the-ground. If not, little time & effort would have been expended.

Good Luck,


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

 

[Stella740pl]

...if I wanted to go down the painful route of extracting just the data from the FoxPro tables and then re-writing the code

JRB-Bldr's given you lots of good advice.
I wanted to clarify something. Extract data into what?

Did you select some other type of database/language? If so, what it is? Depending on it, there may be different ways to transfer the data into the new environment. (You may do some of the data transferring work in your FoxPro environment which you seem to still have on your computers.)

Did you decide to rewrite in a newer version of Visual FoxPro? Then you don't really need to extract anything at all. VFP will be able to use the table as it is. You may want to move the data to a newer data format, but you don't have to. If you wish to do so, it is easily done from within Visual FoxPro. There are several different ways to do it, one of them is shown above by JRB-Bldr.

(JRB-Bldr, I, personally, wouldn't use SELECT-SQL to transfer the data, as it often changes the table structure - field sizes, etc. I would, probably, go for COPY STRUCTURE EXTENDED/CREATE FROM/APPEND FROM. Actually, I prefer COPY STRUCTURE TO/APPEND FROM, but I am not sure it would create a new VFP format and not just another older FP copy.)

Another question is, what are your goals, short-term and long-term?

If you just want to make the system work on XP, you may not have to do much. Chances are high that it will work as it is without even having to recompile anything at all in a new VFP. Or it may easily recompile in VFP with or without some minor tweaks.

If, however, you want a modern-looking application, you may need to rewrite at the very least the front end of it, all of user interface - forms, menus, maybe some other bits. Most likely, you can leave calculations intact, just recompile them in the new environment.

 

[JRB-Bldr]

Stella - you hit the nail on the head with your question - "what are your goals, short-term and long-term?"

Regardless of how many ways and times we explain the variety of ways to approach a conversion of this type, Rosalia (aka amros) has to first decide for herself her (or her company's) goals.

1. A "quick and dirty" conversion to get an operational app with an antiquated look-and-feel for the short term which will run under XP.

2. Or a more comprehensive conversion which will end up with a 21st century appearance, significantly MUCH more manageable code and the possibility of further enhancements using a current language (VFP 9)

Obviously the former will require less effort now, but no less effort later should directions change and the later become the goal.

On that note I went back and re-read her initial posting and saw where one of her acceptable options was -

Maybe write a script in windows environment that actually has its own UI, but when u click a button on the new UI, it calls the old program

While it would certainly not be my personal choice, if she really wants "quick and dirty", then maybe she should just copy Foxprox.exe, the PRG files and the associated tables into the appropriate directories on a test workstation running XP and create a Windows desktop shortcut to launch the old app as-is. If all of the necessary components were successfully copied, it should run in a DOS window.

JRB-Bldr

 

[amros]

JRb-BLdr and stella,
Thanks again for your posts.
I was thinking to extract the data into SQL server and then work with VB.net as the front end. My boss however wants me to work with ACCESS.
is there a tool for that.

The reason that I was asking for that is that I have to convince the management to buy the new version( which honestly I think is the route I want to go,all your advice was very helpful for that)
But I just want to to make a better case when presenting the need why, Since I am sure they will say, "Hmm.. why not use Access. It is free"

Anyways,
My Short term goal: get the application working on XP
Long term goal: get the forms looking a little better

Thanks again for all your posts guys.
It has been very helpful getting some perspective with respect to FoxPro.
amros a.k.a Rosalia