vfp9 to vb.net,sql server

[irfhan]

Dear all

kindly help me on this,if possible!
The concern where i am working is having a software package which deals with finance,inventory,HR & payroll which was developed in vfp9 since 10 years ago.the product is fine moving in the market.now the management decided to migrate the platform to vb.net with sql server.
i am a programmer working on the same product with 4 years experience in vfp9 giving support,customization as per the users request.
since i am new to dotnet platform,i dont know where to start with dotnet.

can any one give me the idea of your best move on!!

best regards

 

[Mike Lewis]

You might be better posting your question in a VB.NET forum.

Meanwhile, I've asked the management to delete your other thread ("Dear all kindly help me on this"), as it is an exact copy of this one.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[Olaf Doschke]

You can split this question into two:

a) How do you do things in VB.net (rgeardless of what other databases, programming languages and IDEs you already know)
b) What similarities are between VFP and VB.Net, so you can easier understand VB from a VFP developer perspective

I second Mike in that a) is best asked in a VB.NET forum

In regad of b) you find something, eg
[URL unfurl="true"]http://foxcentral.net/microsoft/netforvfpdevelopers.htm[/url]
and
[URL unfurl="true"]http://www.amazon.com/Visual-FoxPro-Basic-NET/dp/0672326493[/url]

Just a warning: Both books address older Visual Studio and VB.Net versions, things have changed, but of course this is a helpful starting point. Yet also VB.NET learning videos, tutorials, forums, references etc. are good to start from scratch and learn the best practices.

What may be very helpful is to know you can migrate feature by feature, as long as you go for a winforms application, you can use some of the Migration strategies Microsoft offered to VB6 developers to migrat to dotNet, as these tools base on COM/OLE, which you can also use in VFP. In short you can develop Forms or controls in VB.NET Interop projects/Components, which you can use via COM in VB6 or also VFP.

In [URL unfurl="true"]http://msdn.microsoft.com/en-us/vstudio/ee413549[/url] mainly look for the Interop Toolkit 2.1

Bye, Olaf.

 

[irfhan]

hi mike,

its nice to hear from you..

mike,infact i am more comfortable with vfp9 and it is a great platform too.the product which they developed 10 years back will be as it is. they are really happy with the product.but new customers wanted something developed on dotnet. all they say is microsoft announced by 2015 vfp support stops.

mike can you pls help me on this !!

 

[Olaf Doschke]

And here is an article showing hos this toolkit can be used in VFP:
[URL unfurl="true"]http://weblogs.foxite.com/bernardbout/2007/06/20/using-the-interop-forms-toolkit-in-vfp9-a-walkthrough/[/url]

The way this migration will work overall is implementing form by form in VB.Net and replacing VFP forms, until the only leftover will be a VFP screen with menu, which then can then be replaced by a full and native VB.net application.

It's easier, if in a previous step DBFs are migrated to SQL Server, so maybe that would be a first step to take before going VB.NET at all, because VB.Net offers more tools and subsets of dotNet classes/assemblies to work with SQL Server data, than with DBF data. You can use OleDbCommand with VFP OleDBProvider and ODBCCommand with the VFP ODBC driver, but that is about that. No LinqToDBF, no Enntitiy Framework support etc. Besides data migration is easier anyway, as a first step.

Bye, Olaf.

 

[irfhan]

thank you very much mr.OlafDoschke.i am going through it


best regards

 

[TamarGranor]

Just because Microsoft stops offering support for VFP, that doesn't mean that your application will suddenly fail. There are thousands (probably tens of thousands) of FoxPro 2.x applications running in businesses around the world and that product hasn't been supported for more than a decade. VFP applications will continue to work for a long, long time.

Tamar

 

[clipper01]

irfhan;

I am currently in the process of re-building an application from VFP to dotNet . The application is a typical VFP "special" , in this case the back-office end of a site that provides on-line orthodentic services

http://www.esmdigitalsolutions.com/.

I should be fairly advanced with this in a couple of weeks and plan to blog the progress. I hope to get feed-back from other VFP users who have converted on methods/techniques/patterns etc . I will post the VFP version and the dotNet version to my FTP site with test dats for users to view/comment. Are there any others on this site who have done a full re-build ??

My advice is to totally forget any kind of migration tool-kits , it is a totally differnt mind-set , you will just end up "fighting" it if you try to "convert" it . You have to invest a lot of time up-front, in buildng your own tool-kit of methods,techniques

Agree with other comments , VFP will keep working for many years, but there will be a certain percentage of sites ( maybe 20% ?? ) that for one reason or another ( good or bad ) , will mandate a change . Looks like your employer is one of these.

Will post again on this in a few weeks when demo is ready and be happy to answer on " how do you do that "

 

[Olaf Doschke]

The formwise migration has one big advantage: It does not try to convert dataaccess or functions, it merely let's you put together dotNET and VFP forms in VFP. The other way around is not possible, as you can't create ActiveX classes in VFP, which could integrate into a dotNet application. That shouldn't matter.

Don't misiunderstand the interop toolkit as a tool converting forms or functions. It merely adds projects templates for forms and controls to visual studio, which enable you to easier create forms and controls, that can be used as COM/ActiveX components in VB6 or VFP9 (and elsewhere, where you can integrate ActiveX).

The forms you create in dotnet can use the full power of .Net and all the .Net specifics and mind-set, as clipper calls it. You don't even need to replace each vfp form one by one. If a new design fits better in .Net, why not replace 3 VFP forms with 2 .Net forms making use of controls VFP does not offer.

Bye, Olaf.

 

[SBTBILL]

Depending on how you did things it may not be that much of a problem. I've been working in VB.NET and VFP for about 2 years now. I've found that I can cut and past a lot of VFP code into VB. I should point out that I started using SQL as a VFP data source about 4 years ago. I tend to replace VFP Case statements with IF ELSEIf Else statements. You can call the same MSSQL stored procedures with both languages with no changes to the procedure. ADO works in both. (Might be a problem with Windows 7 64 bit.) VB use a & where Fox use a + for concatenation. Single and double quotes are more testy in VB.

Haven't run any VB exe's from VFP yet as most of what I'm doing in VB is web related, but should work. The web is quite limited compared to desktop applications.

Hope this helps
Bill Couture
SBTBILL.COM

 

[clipper01]

Per prior reply , have posted sample re-build VFP to dotNet , you can get it here

http://itss50.wordpress.com.

To summarise, it is an order-tracking system for a dental technology business. The application is about 60% re-built .

Screens, features etc are pretty much the same , be happy to share info on methods,techniques etc

Will welcome any comments here or on the Wordpress blog

 

[TomSlayton]

Irfan,

Check out Murach's ADO.NET programming with VB.NET:

http://www.amazon.com/Murachs-ADO-NET-Database-Programming-2010/dp/1890774626.

It's a great book and will get you going on building three tier apps very quickly. I have been using it for a couple of years as a reference.

Best,

Tom

 

[clipper01]

yes, that does seem a very good book , with real-world , not "hello-world" examples. In general , here are a few observations , having spent some time in the rebuild referenced in prior post, these relate to the re-build of a typical VFP data-bound application ( for more "visual" applications, advice would be different)

1) forget about conversion/migration tools , the dotNet mind-set is totally different
2) forget about all the control libraries ( devexpress, infragistics , telerik etc ) . All they offer ( for VFP rebuilds ) is a grid that can do various kinds of Outlook-style grouping , a lot of eye-candy, they do not help the code in any way
3) decide on your language C#/VB and the platform Winforms/WPF . Sql Server Express, nothing else
4) decide on your data-layer methods ( and the above book seems a good guide ) , then all you need is the generic dataGridView's etc that come with dotNet . That will cover the front-end / user interface
5) use the power of dotNet , LINQ , generic types etc and you will find that "back-end" processing is much better than VFP
6) you will find coding takes longer , 20 lines in VFP , to maybe 60 lines in dotNet
7) but code will be much more robust, never have the typical VFP 'bugs' that escape to your customer

Appreciate comments from other users , as original poster seems to have lost interest

 

[craigber]

I'd suggest going web-based using ASP.Net MVC rather than Winforms or WPF, that both seem to either at or close to a dead end. Out of the box, MVC uses Entity Framework Codefirst, but it isn't required. Going web based means learning HTML, Javascript, CSS, and I highly recommend JQuery. This is in addition to C#/VB, MVC, EF, etc.

Craig Berntson
MCSD, Visual C# MVP,

http://www.craigberntson.com/blog

 

[clipper01]

surely there is still a place for the good ol' desktop/LAN app, especially as described by the original question " a software package which deals with finance,inventory,HR & payroll". Paradoxically, with all the moves to " cloud" , that might even give a new lease of life to these, as now they can be accessed on-line ? , no worries about latest/greatest OS's from MicroSoft , just run 'em, if need be, in a virtual XP box