foxpro in dos to vb .net???

[sodina77]

is it possible to convert a system which uses foxpro 2.6 into an object oriented system? maybe usinf vb .net??

 

[Olaf Doschke]

Seems like an awakening from a long sleep. There's VFP9 for the Vista+ generation and you've not updated through 5 other foxpro versions (there was no VFP4). Be prepared that you'll now may get away cheaper and faster, than taking together what migration to each new version would have taken, but it's a huge gap between fpd 2.6 and VB.Net 2008.

In certain cases it may be possible to do this partially only. Eg keep the DOS app and data, implement parts of the application in VB.net and work on the same DBFs. But there are some code page issues (DOS vs. Windows), though it's technically possible to access older DBF version with VB.net using the OLEDB Provider of VFP. It's unlikely though, that you will be happy with the current table structures in an OOP application. It's likely you'll want a redesign of the database.

It's of cause possible, like it is possible with any system: By a complete rewrite. You'd perhaps migrate data to SQL Server and app to VB.NET, maybe VFP, that depends on who should migrate the system with which knowledge about the data, the application and the programming languages.

Bye, Olaf.

 

[AndyInNC]

I've recently implemented a design that uses existing FoxPro 2.6 dbfs via SQL Server by setting up Linked Servers. I set up an ODBC connection on the SQL Server box which connects to each directory where the dbfs are. (The dbfs are grouped into various directories on the network based on their functionality.) Then, I created a linked server for each directory with SQL Server 2005. For greater flexibility, I created a view for each dbf that I wanted to reference using the OpenQuery function. This allowed me to rename a field or concatenate fields or provide formatting for my SELECTs. (Date/time fields, for example.)

If it's possible to move to Visual FoxPro 3.0, look into that. Fox 2.6 does not allow NULL values like Fox 3. Update statements need to be checked for the correct values without NULLs. It can get kind of sticky while you're setting it up, but once it's in place, it's a lot easier to work with.

 

[Olaf Doschke]

Also take a look at the Advantage Database Server. It can also host your DBFs without changes. It is a bridgw for .NET languages to access data through a Server system and still allows you to use both set oriented SQL queries and record oriented navigating table access. It's an even easier migration path than SQL Server linked databases and it knows DBFs inside out.

Bye, Olaf.