Jon,

The SQL experience is very important and will give you a strong platform for finding careers. While some might disagree, I think it would still be valuable to build on your experience in VFP6 for the development side. There are still MANY Foxpro and VFP applications out there and they will need programmers to maintain them and help transition them to other technologies.

AccPac Pro Series alone has a substantial install base and uses VFP7 with optional SQL backend. There will be numerous clients over the next few years migrating from VFP to SQL backend for AccPac Pro Series. AccountMate is another VFP source application with many, many installs.

While the VFP developer demand isn't what VB is, VFP is strong in finiancials and accounting applications in the corporate market because it used as a backbone for some of the largest mid-sized accounting companies. AccPac is #1 in Canada and #2 in the United States in mid-sized accounting software. When you go to look for good mid-sized accounting software WITH source, VFP becomes a more common solution.

Make sure you know common accounting structure and tables inside and out. If you know VFP but don't know anything about financials or accounting, you won't be much use in the largest VFP markets.

While I still think there is some strong VFP opportunities, it would be good to begin learning .NET. Realize that a lot of VFP work will be in migration to SQL, Oracle, and .NET platform.

I wouldn't listen to John Peterson's advice on anything related to VFP, and I'm sure there are plenty of other VFP programmers that would back me up on this position!

Nor would I listen to anyone who would suggest that knowing VFP alone is a good path either. There will be fewer and fewer VFP only positions in the future and you can't expect to push new projects with VFP.

But why throw away 4 years of expeience in VFP when there is still so much work to do? In fact the movement FROM VFP to other technologies over the next decade will make VFP skills valuable.

A strong platform is using VFP for frontend work and SQL for backend. Switching out the many corporate applications from VFP backend to SQL backend is the first phase. After that there will be much less pressure for companies to move away from VFP. This is cost-effective because for many companies it will be finanically prohibitive to re-write VFP apps in VB .NET. Up-sizing the database but staying with VFP for the app can often be smart, cost-effective business decision.

Be flexible when approaching clients and let them know you are not there to 'push' VFP but to help them in making objective decisions. Many want to move away from VFP and it will be your job to convince them your VFP/SQL skills will be critical to doing it right. Then when faced with the cost of using VFP/SQL compared to re-writing everything from the ground up in .NET, many companies are going to go with VFP/SQL.

My bottom line advice - Build on your VFP and SQL experience while adding VB .NET to your future skill set. Also, you will be smart to emphasize any exprience in accounting, financials, manufacturing processes, etc. Often this is more important to a company than finding a programming wizard.

Greg

>Hi guys,
>
>I realise this is not what you guys are here for but I need to make some importent decisions over the next few months and any advice suggestions would be greatly recieved.
>
>Background - I have almost 4 years of Fox 2.6 and VFP6 experience, I've been with my current company for 3 years. They have just been bought out and it seems the product I work on is going to be redevloped overseas in VB.NET. This is good for the company because they will be able to produce a product at a very low cost..but I dont think its so good for me. The new company seem not to want to involve the UK based team in any of the new product development and Im concerned because this puts me in a very weak position.
>
>Basically I want to make sure I'm in a strong position when they decide they dont need any of the developers based in the UK, probably in the next 12 months or so.
>
>I think I need to retrain as although I love foxpro there arent to many jobs about for it (espcially in the area I want). My main concern is that it seems the the role of the programmer especially in the UK is not that clear, it makes perfect sense for companies to out source their development overseas as it save a significant amount of money, but I think that means that the programmers lifetime is coming to an end.
>
>I was looking to get my MCP in VFP6, however I dont think this will really benefit me as I think if a VFP job came up I could get it with or without the MCP.
>
>I have almost 12 months experience in SQL 2000, I am seriously considering funding myself through a "boot camp" style course to gain certification on SQL 2000, hopefully this will open up some more doors for me. My idea behind this is that I would leave open the opportunity of moving into a DBA role if I gained a couple more MCP's and I feel this role may have a longer lifetime than that of a programmer. My other choice is to do some training on .net technology however I dont have any commercial experience in this so Im not so sure and it also means Im slightly more tied to the programmer role.
>
>I know I could self study for these exams, but in a cost benefit sort of way I dont know if I can wait (have) that much time before Im going to really need to move jobs. The cost of the investment (and I would see it as an investment) in the short term would hopefully be repaid in the long term by a better job and salary.
>
>At the end of the day its really my own fault that im in this position as I have sat back and not thought about the future (that along with my company not re-investing in me).
>
>Wow this is a long message if you get this far im impressed.
>
>What im interested to know..
>
>Do any of my theries make sense. I don not want to pay out lots of money for a course that may not improve my chances of finding new workk.
>
>Do "boot camps" work. Im looking to do it with "thetrainingcamp" has anybody used them or can they reccomend anybody else.
>
>Apologies for the extremely long message.