conversion of old foxpro 2.6a for dos application to Access2010/12

[jramkla]

We are having legacy application developed and running very smoothly for the past 21 years on foxpro 2.6a for dos. We wish to move on to newer GUI based Windows platform, please advise how we can get into doing this. Also would recoding the entire application be the ONLY alternative??

Need urgent answers and would appreciate if replies came in thick and fast. Thanks in advance

 

[Dan Freeman]

Access (and indeed any Windows program) is different. It just DOES things differently. Your VERY BEST option is a rewrite.

Even if you were upgrading from FPD to Visual FoxPro your best course of action would likely be a rewrite. A few (very few) lucky individuals have applications that "convert" well, but those are few and far between.

Going to a different platform, with a different operating paradigm, on a different database, you should start from scratch.

The good news is you can keep all the knowledge about how the business works and it should make creating the new application go quicker than the old one did.

 

[DSummZZZ]

I'm with Dan. The best way to go about it would be a rewrite, but a total rewrite isn't always necessary either. I am just finishing a rewrite of an app that I originally started in 1993 using Foxpro Windows.
Sure, there are a lot of things that VFP (9 in my case) does differently, but I am also reusing a lot of code from the original as methods and procedures in the rewrite.

Please. Don't even consider Access. I wouldn't recommend that platform for anything but the smallest of projects.


-Dave Summers-

Even more Fox stuff at:

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

 

[JRB-Bldr]

foxpro 2.6a for dos application to Access2010/12

Can you do a word-for-word conversion of English to Chinese?
No

In the same manner, due to the vast differences, you cannot 'convert' one application in ANY Language to Another vastly different language. That also applies for FP to Access.

Plus, why would you want to functionally Down-scale your application to Access when you could Up-scale your application to Visual Foxpro 9?

We wish to move on to newer GUI based Windows platform

With VFP9 you would indeed get the newer GUI based Windows platform, a whole host of more functionality, existing code compatibility (for the majority of the code), and a much easier 'conversion' path.

Good Luck,
JRB-Bldr

 

[jramkla]

Thanks a lot, JRB-Bldr, Dave Summers and Dan Freeman, for your response.

I too felt the same, but needed a third party feedback to convince management about it. Also according to you MS-Access 2010 too is a very weak platform isn't it? If you have many threads on this, please share, becos a colleague of mine is trying hard to convince that it is best platform and he understands technology best, all others are novices!!

Ok lastly, is it possible to secure the dbf files, in such a manner that it would work using the application only, trying to access it using Excel or any other software can be blocked???

Character fields in the dbf can be easily encrypted using a routine, How do we accomplish this for Numeric and Date format data??

The legacy application is in operation for the past 21 years, and a lot of time, money and effort has been spent on it, so very tough to take a call to discontinue using it. As i am writing this it is in operation in the company and works perfectly smoothly.

Thanks in advance and await your responses.

 

[Dan Freeman]

MS Access is perfectly adequate as a development platform for some projects. I would avoid the MDB file format, though.

You can secure DBF files at the network level just as you can secure any other folder, but if a user has access to the executable (which has access to the data) then by definition they'll have to have access to the data. If your security needs are more robust than yelling "DON'T DO THAT!" you should investigate using an actual database back end like SQL-Server.

 

[JRB-Bldr]

To get the Best Secure data tables, you might want to consider moving your data into a SQL Server (Express or Standard version) where the security is better ensured.

But, in lieu of that, as Dan has suggested, you can use Windows Network Security to minimize user access to your data directories.

And with the data secure, you can then modify your application to utilize that data 'backend' instead of the DBF (VFP) or MDB (Access) 'native' data sources.

a lot of time, money and effort has been spent on it,

That is one primary reason to consider staying in Visual Foxpro.
Changing to another language would mean TOTALLY documenting everything and then TOTALLY developing it from 'scratch' in a new language - Access of anything else.

third party feedback to convince management about it

Without a doubt, since this is a Foxpro forum, we are biased.

But many of us also develop in multiple languages and are very cognizant of the challenges of moving an existing application (especially complex ones) from Language A to Language B

As Dan indicates Access is OK for some things, but it is functionally not as comprehensive as Visual Foxpro.

If you want the fastest application conversion timeline, most functionality for future enhancements and best over-all solution to an application that is already in Foxpro, go to Visual Foxpro 9.

And don't let those who tell you "Foxpro is no longer being supported by Microsoft" deter you.
Visual Foxpro is supported extensively by users like ourselves on forums like this one (and more language-specifically Microsoft: Visual FoxPro Forum forum184 )
And the support is Better than Microsoft ever offered.

Good Luck,
JRB-Bldr

 

[Rock4J]

My opinion is, the MORE we afraid to CHANGE from old program to a new platform, the MORE TIME and MONEY are being wasted. And the job which suppose to be easier became harder for the program user, because it causing the non-IT or non-programmer workers to tolerant with the old program errors. Operating Systems such as Microsoft keep upgrading, How will a DOS program survive? Nothing will happen magically. Of course it will cause a lot of problem. But at least, in the end it worth it.

Regards,
Rocky