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!
foxpro in dos to vb .net???
- Thread starter sodina77
- Start date
Olaf Doschke
Programmer
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.
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.
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.
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
Programmer
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.
Bye, Olaf.
- Status
Similar threads
- Locked
- Question