Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations derfloh on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Upgrade from VFP 8 to 9
- Thread starter iolair
- Start date
Dan Freeman
Programmer
Take a look at the list of enhancements:
Only you know if there's something you "just gotta have".
Only you know if there's something you "just gotta have".
TamarGranor
Programmer
One important reason to go to VFP 9 and then patch to Service Pack 2 is that it includes fixes for visual issues under Vista and Windows 7.
There are lots of other reasons to upgrade, but as Dan said, only you know what matters to you.
Tamar
There are lots of other reasons to upgrade, but as Dan said, only you know what matters to you.
Tamar
We have ten licenses, so cost could be a factor
Do you have 10 Developers?
Remember that the licenses are applicable to the Development users, not the resultant application end-users.
That was always one of the many BIG PLUS's when considering the use of VFP.
Good Luck,
JRB-Bldr
Do you have 10 Developers?
Remember that the licenses are applicable to the Development users, not the resultant application end-users.
That was always one of the many BIG PLUS's when considering the use of VFP.
Good Luck,
JRB-Bldr
Olaf Doschke
Programmer
Well, costwise it's 10 x $349 US (official upgrade price of MS) vs cost for anything else, eg migration to a totally different programming language+database. If you find some much cheaper offer, perhaps its academic licenses, watch out.
If migration is long or mid term your choice anyway, you might put that money into training or conferences or books or time. How much do you charge your customers? How much time of your employees can you fund not working for customers? How much is your net gain of an hour work, so how long will you need to work to fund the buy of VFP9? Those figures might help you make the choice easier.
I would also consider, that the invest comes a little late. Unless you don't need to continue your vfp work you could also skip vfp9 and start in VS2010 or Java or go web, cloud or classic web apps.
As long as your customers don't care what their applications are programmed in VFP9 has some time to live, considering it works under the Win8 developer preview and it's unlikely to change.
Depends on your needs.
Bye, Olaf.
If migration is long or mid term your choice anyway, you might put that money into training or conferences or books or time. How much do you charge your customers? How much time of your employees can you fund not working for customers? How much is your net gain of an hour work, so how long will you need to work to fund the buy of VFP9? Those figures might help you make the choice easier.
I would also consider, that the invest comes a little late. Unless you don't need to continue your vfp work you could also skip vfp9 and start in VS2010 or Java or go web, cloud or classic web apps.
As long as your customers don't care what their applications are programmed in VFP9 has some time to live, considering it works under the Win8 developer preview and it's unlikely to change.
Depends on your needs.
Bye, Olaf.
- Thread starter
- #6
To answer the question, no, just one developer. Possibly 7 or 8 users, maybe 10 max.
As far as keeping up, we were using FoxPro 2.5 until 2006, so, we can probably do just fine on VFP until 2020..... <g>
Our developer does own SQL Server and VS, but is not familiar with it at all.
And we do have Access as part of Office 2010, but I've heard Access is not very powerful. We do have a rather small database, though - less than 1 GB, I think it's around 945MB if I remember right.
Iolair MacWalter
Network Engineer
As far as keeping up, we were using FoxPro 2.5 until 2006, so, we can probably do just fine on VFP until 2020..... <g>
Our developer does own SQL Server and VS, but is not familiar with it at all.
And we do have Access as part of Office 2010, but I've heard Access is not very powerful. We do have a rather small database, though - less than 1 GB, I think it's around 945MB if I remember right.
Iolair MacWalter
Network Engineer
- Thread starter
- #7
To answer the question, no, just one developer. Possibly 7 or 8 users, maybe 10 max.
Then you only need a single license for the single Developer.
Again, the number of application users is in-consequential as far as VFP licenses are involved.
Our developer does own SQL Server and VS, but is not familiar with it at all.
That is good, but, even if they knew one of the VS languages REALLY well, it would very likely take a significant length of time to convert an existing VP application to VB.Net, C#, etc (one of the VS languages) since the languages are totally different than VFP.
However if you thought that your data volume might increase significantly, you might want to consider modifying your VFP application (VFP8 or VFP9 version) to utilize the SQL Server as your data 'backend' where you would not have the 2GB data table size limitations instead of the VFP data tables - but until that circumstance appears on the horizon, its certainly not necessary.
Good Luck,
JRB-Bldr
Then you only need a single license for the single Developer.
Again, the number of application users is in-consequential as far as VFP licenses are involved.
Our developer does own SQL Server and VS, but is not familiar with it at all.
That is good, but, even if they knew one of the VS languages REALLY well, it would very likely take a significant length of time to convert an existing VP application to VB.Net, C#, etc (one of the VS languages) since the languages are totally different than VFP.
However if you thought that your data volume might increase significantly, you might want to consider modifying your VFP application (VFP8 or VFP9 version) to utilize the SQL Server as your data 'backend' where you would not have the 2GB data table size limitations instead of the VFP data tables - but until that circumstance appears on the horizon, its certainly not necessary.
Good Luck,
JRB-Bldr
Dan Freeman
Programmer
JRB-Bldr, you are assuming that those 10 users are using compiled programs. There are actually places where end-users use Foxpro from the command window.
Olaf Doschke
Programmer
It's a waste to own it and not make use of it. You could at least start with data, so learn a bit T-SQL, actually it is simply sql with a bit more options of eg MERGE, INTERSECT, recursive sql and more. Can be used from VFP of course.
It sems all you do is inhouse development and you might go on with vfp until 2020. And then? add another few years because you still lack any other knowledge?
It's true that you have much time at hand to learn something new, but that's no argument to wait with it until you don't get around it anymore.
The age of your in house developer is a factor. If he's near retirement it would perhaps be an idea to hire someone new already bringing in some sql server and vs knowledge. You know the older someone get's, the harder it is to learn something new.
Bye, Olaf.
Mike Lewis
Programmer
Just to add another thought ...
Iolair, you say you have one developer and about ten users. If you do decide to go from 8 to 9, you will only need one copy of VFP, but you will need to upgrade the runtimes on all the users' systems.
That's not a problem. It's just an extra step - something you will need to allow time and effort for.
Personally, I think the productivity gains the developer will get from upgrading will make the cost and effort worthwhile. But it depends in part on how much further development he will be doing. If the application is complete, it might be better just to leave things as they are.
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro articles, tips, training, consultancy
Iolair, you say you have one developer and about ten users. If you do decide to go from 8 to 9, you will only need one copy of VFP, but you will need to upgrade the runtimes on all the users' systems.
That's not a problem. It's just an extra step - something you will need to allow time and effort for.
Personally, I think the productivity gains the developer will get from upgrading will make the cost and effort worthwhile. But it depends in part on how much further development he will be doing. If the application is complete, it might be better just to leave things as they are.
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro articles, tips, training, consultancy
my 2 cents ;
1) there are a number of improvements in the cursoradaptor that might be a bonus in working with sql back-ends but hardly seems to be a value in your case.
2) reports !! vfp9 reporting system is the killer feature ; allows you to do all of the kind of thngs that Crystal Reports did e.g. multi-band reports. This is the kind of thing you can SELL to your clients , allows you to do all sorts of new business-oriented reports , that might help pay the upgrade costs.
1) there are a number of improvements in the cursoradaptor that might be a bonus in working with sql back-ends but hardly seems to be a value in your case.
2) reports !! vfp9 reporting system is the killer feature ; allows you to do all of the kind of thngs that Crystal Reports did e.g. multi-band reports. This is the kind of thing you can SELL to your clients , allows you to do all sorts of new business-oriented reports , that might help pay the upgrade costs.
Olaf Doschke
Programmer
Actually my favorite improvement in VFP9 was the sql engine improvements. I have to admit I don't know what changes occurred between vfp7 and 8, so I got all those plus the ones between vfp8 and vfp9.
As far as tells, quite a lot of the sql engine improvements was done in VFP9 and not in 8.
Several forms of subselects are allowed which wheren't before. And even though it's very nice alread, this is still behind what an MS SQL Server offers in regard to SQL alone. If your developer isn't very sql query affine he might not miss this improvement, but it is a great improvement, too, indeed.
Bye, Olaf.
As far as tells, quite a lot of the sql engine improvements was done in VFP9 and not in 8.
Several forms of subselects are allowed which wheren't before. And even though it's very nice alread, this is still behind what an MS SQL Server offers in regard to SQL alone. If your developer isn't very sql query affine he might not miss this improvement, but it is a great improvement, too, indeed.
Bye, Olaf.
Mike Lewis
Programmer
Iolair,
I've been thinking some more about this, and it occurs to me that you're asking the wrong people.
All the replies you've received are from committed VFP developers who use the product every day and are likely to continue to do so. It's not surprising that we would all favour using the latest version.
But if your application is settled in, and you have no immediate plans to enhance it or to develop it further, you might be better off leaving things as they are. There will inevitably be a cost in upgrading - both in money and effort - and the new features are unlikely to justify that investment.
Just my humble opinion.
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro articles, tips, training, consultancy
I've been thinking some more about this, and it occurs to me that you're asking the wrong people.
All the replies you've received are from committed VFP developers who use the product every day and are likely to continue to do so. It's not surprising that we would all favour using the latest version.
But if your application is settled in, and you have no immediate plans to enhance it or to develop it further, you might be better off leaving things as they are. There will inevitably be a cost in upgrading - both in money and effort - and the new features are unlikely to justify that investment.
Just my humble opinion.
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro articles, tips, training, consultancy
- Thread starter
- #16
Thanks for all the input. No, our developer is mid-career and is committed to learning VS and SQL Server, but I was looking short term.
We've gotten estimates to re-write in SQL Server and VB, and the three we contacted said about 18 months to do it. So, it's bigger than I thought, programming-wise.
As for me, I feel very comfortable maintaining the current VFP code, should problems arise.
@Mike Lewis - just got back from the Orkney Islands. How's the weather in Edinburgh?
Iolair MacWalter
Network Engineer
We've gotten estimates to re-write in SQL Server and VB, and the three we contacted said about 18 months to do it. So, it's bigger than I thought, programming-wise.
As for me, I feel very comfortable maintaining the current VFP code, should problems arise.
@Mike Lewis - just got back from the Orkney Islands. How's the weather in Edinburgh?
Iolair MacWalter
Network Engineer
Mike Lewis
Programmer
Iolair,
I assume you have a good reason for going to SQL Server, but have you considered keeping the front end in VFP? It would be much easier than converting to VB (at least, I would think so; I've nothing to base the comparison on).
The weather in Edinburgh is unually good for November - warmer and brighter than Orkney, I would guess.
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro articles, tips, training, consultancy
I assume you have a good reason for going to SQL Server, but have you considered keeping the front end in VFP? It would be much easier than converting to VB (at least, I would think so; I've nothing to base the comparison on).
The weather in Edinburgh is unually good for November - warmer and brighter than Orkney, I would guess.
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro articles, tips, training, consultancy
I've just had one "major" app that uses vfp front and 100% sql server back-end. Used cursorAdaptors all the way , ( although u will see some negatives posted about these ) . App has run 3 years now without a blink. I don't know if any of the sql/ca 'fixes' in vfp9 helped as opposed to vfp8 , but I can only vouch that vfp9 works 100% , a dream , as easy as native vfp cursors. So if u plan to go sql back-end , yes go vfp9 !!
You will then be able to see the dotNet route for coding the same user interface in VB /C# and estimate the time multiple
You will then be able to see the dotNet route for coding the same user interface in VB /C# and estimate the time multiple
We've gotten estimates to re-write in SQL Server and VB, and the three we contacted said about 18 months to do it
As others have said immediately above, you wouldn't REALLY have to change the VFP 'front-end' of your application.
You could merely modify your existing VFP application to utilize a SQL Server 'back-end' instead of the VFP data tables. That shouldn't take you anywhere near that long.
And if you already had your data in the SQL Server, the VB (hopefully VB.NET not older VB) development (if you REALLY wanted it in that language) could occur at a much more leisurely pace since you would still have a workable VFP application.
And with the application's data already in the SQL Server, the VB project would already have its data where it needed it.
Good Luck,
JRB-Bldr
As others have said immediately above, you wouldn't REALLY have to change the VFP 'front-end' of your application.
You could merely modify your existing VFP application to utilize a SQL Server 'back-end' instead of the VFP data tables. That shouldn't take you anywhere near that long.
And if you already had your data in the SQL Server, the VB (hopefully VB.NET not older VB) development (if you REALLY wanted it in that language) could occur at a much more leisurely pace since you would still have a workable VFP application.
And with the application's data already in the SQL Server, the VB project would already have its data where it needed it.
Good Luck,
JRB-Bldr
agree 100% with jrb , matter of fact , there is no real performance/feature/stability benefit to re-do for sql bak-end , but if u can get your client to pay for it , it's an excellent way to finance some kind of 2/3/5 year plan to transition yr apps to dotNet.
Only reason I did app on sql back-end was that the client mandated it , plus the same db was also being accessed by a web app, which actually was a fairly valid reason in that case. I have used WestWind connection and yes the web side could have been done very easily in that , but in the project , the web side was done in ASP by another, so this kind of scenario is also some thing to bear in mind
Only reason I did app on sql back-end was that the client mandated it , plus the same db was also being accessed by a web app, which actually was a fairly valid reason in that case. I have used WestWind connection and yes the web side could have been done very easily in that , but in the project , the web side was done in ASP by another, so this kind of scenario is also some thing to bear in mind
- Status
Similar threads
