>I'm not quite clear on what you ment by tons of compelling reasons to move off of VFP3.0.

Without going into a whole lot of detail, the most immediate advantages would be

- Tons of bug fixes
- Increased internal functionality (in this case COM/ActiveX)

>We use windows 95 as our OS but I have been told by previous programers that we are stuck with VFP 3.0 because are primary APP was developed in this version.

While porting the entire application would involve extensive rewriting, there's noting preventing you from writing new application modules in VFP 5 or 6 and having them use the same tables at a minimum. Changing from VFP3 to VFP5 or 6 is not just a matter of recompile and go, absolutely, but clearly, they've changed their OS and app platform to the point that it was important that you launch a URL from inside an app. If you want or need to take this operation to the next logical step, where you need VFP to programmatically control IE - launch a URL, log in, get some stuff and log out for example, without user intervention, it's going to be easier to do with VFP5/6 and COM (the WebBrowser control, or use of the InternetExplorer.Application COM object, easy to do and support with later versions of VFP, is nowhere near as easy with VFP3), as are other common tasks like coordinating things with other external applications.

-It has been relayed to me that it would virtually take rewritting the whole application completely in order to make it so we could make changes as needed to it. As for the truth behind this I can only take their word for it since they developed the APP and I am now the only one remaining to due maint. on it.

This is troublesome - if you're maintaining and extending it, and responding to user requrests, but you've never looked at the code closely enough, or at the platform closely enough, to know what's involved in moving to a more current platform, there's a problem. Is this the only application, and the only client, using this platform and the VFP platform in general? If so, and this is a sort of, "well, I'm not doing any development, just patching up with bubblegum and baling wire" situation - you aren't really concerned with more than a couple of minutes changing the app and all the other functionality can remain a black box, with no reason for you to look at the code, that's fine; I get lots of calls that "my old app someone else wrote in < fill in the blank > needs to have (add seemingly trivial list of features). They can't/won't do it, so I'm asking you...", and as long as the client knows that this isn't my area of extpertise and that I can't tell them the full impact of what they asked for, fine.

But it sounds like a significant app with ongoing support and development, and from their POV, someone needs to understand the app well enough to pick up the pieces and support their environment on an ongoing basis so that if you're dragged off kicking and screaming by a tribe of attractive and otherwise unattached women savages who need you for breeding stock on an island in the South Pacific, or worse, the guys you depend on for what needs to be done (you can't ask them questions, and you're not enjoying the good life in Tahiti sounds worse from your POV at least).

If maintaining the app is months and months of work, adding new features is an issue, bug support is an issue, and this is not the only VFP thing you need to do, days of rewrite doesn't seem to be a bad investment, from either the client's POV (they get speed and feature enhancements, they get the benefit of the time spent reexamining and documenting what's going on inside the app from the standpoint their programming resource knowing what the platform limitations are and what the design limitations are, and a programmer who has a better knowledge of what's going on inside is rarely a bad thing) and yours (a wider range of tools and functionality, and better ROI on the time you spend learning and using the tool, since if VFP is not an incidental platform for you, you need to know what makes the rest of the world want to use VFP5/6 rather than plod along with VFP3, and why it would be difficult to get the added benefits of working with the current tool. Plus, at least in my case, I'd rather develop new apps that use VFP (again, we assume that this is other than an incidental platform for you) using the current toolset.)

IOW, if this is the extent of what needs to be done, and you aren't going to look at this again for the next 6 months, and you'd rather kiss a snake than do new work with VFP, moving to a newer version of the VFP platform is not warranted. Not moving to a more current platform where this is your daily source of income is a very different matter. Not developing new things using the current tools is a bigger and very different matter.

>I'd love to get out of VFP 3 but is it possible without days of work?

Answering this would depend on what the code does, and how much change is involved in the things being exploited in the application. I have seemingly trivial forms that took basically scrapping the older implementation and starting from the ground up to move from VFP 3 to VFP 5. I have other code that I wrote back in FoxPro 2.0 that, since the procedural functionality has not changed a great deal, could move to VFP5 with little more than a recompile. IOW, you need to know what's going on under the hood of the app to answer the question, and if you don't know and don't want to know this, and investing a couple of days finding out is low ROI (you've got a full plate with more new work than you can handle, and the benefits of moving are lost for you because it's a dead end and the client because they don't see it as a problem) then don't find out...