VB vs. VFP 3

[jlschulte]

My department is trying to make a strategic decision on which way to go forward with our programming efforts. Currently we have many programs in FoxPro 2.6 that are starting to get buggy as we get new computers.

I was looking for input as to what others have done and the experience. The two top contenders are VFP 7 and VB using Access databases. The majority of the programs query databases that aren't huge, but we do have a few with 600,000+ records.

Any tips or major problems that anyone sees?

Thanks

Jeff

 

[danceman]

I would lean towards use of foxpro. the ease of upsizing to SQL or Oracle is worth it. Foxpro is used many times for development, then port the application to acess MS SQL or Oracle. Even if you desided to use VB as the interface, with ADO as your access to the data, I would stay with foxpro.

I would avoid access like the plaque. Attitude is Everything

 

[DSummZZZ]

I think you will find the migration to VFP 7 a lot less work than to VB/Access. Especially since you already have a lot done in Fox 2.6. One way or the other though, it would pay to start converting from 2.6.

Dave S.

 

[fluteplr]

My old company made (makes) a great living converting people from Access apps with more than a few 100,000 records in any table, to MSDE, SQL Server and either VFP or VB front ends. Personally I prefer VFP as a front end to VB,, but that is open to debate.

However on the back end anyone who creates a database that big in Access and expects to run a company on it deserves all the pain and heartache they will be experiencing.

 

[jjgraf]

On access databases you are reaching the limitations of the database.

http://msdn.microsoft.com/library/d...acdecLookUpMicrosoftAccessSpecificationsS.asp

I would avoid Access like the plaque

The biggest problem i have run into using VB is ADO, ADO is just terrible with data access and is an unbelievable memory hog and slow. That is the reason ADO.net is not an Active X object anymore, it’s internal to VB.Net and C#. In fact to access SQL server you no longer use OLEDB provider it has its own access protocol into SQL 2000 so Microsoft could solve the performance problems of ADO.

No matter what development tools you end up using make sure you database is SQL server, pretty much any thing can get data from it.

 

[Guest_imported]

Since you already have lot of FoxPro apps, it's true you'll have more facility to convert them. More, Access doesn't match the speed for queries with database of more than 100 K records; it will be slower and it doesn't have the kind of speed command :
SELECT * FROM xBase INTO Cursor
REPORT FORM myReport.frx
That's it ! (Access: does the form was close, hidden? There's a slightly difference about that between Access 97 and 2000 [I know it for experience]).
You should make tests of accessing/refresh records between VB-Access and VFP (in a grid for example).
VFP is compatible with SQL Server, XML or Oracle, as Access-VB. You must install Office 97 or 2000 or XP on every client. With VFP, you pay once for the distributing EXE.
For reporting, some people install Crystal Report with every VB-Access app, and some also do that with VFP (personnaly, I prefer working with the reporting structure of VFP).

BUT, there's something weird: Microsoft dropped down this good tool. If you have many programmers in your area that can develop/support apps with VFP, it's ok. But if not ? And for the developpers, is there enough companies in the area to share the expertise ?
Finally, how much time do you think those apps will run without too many modifications ?

Dan

 

[jlschulte]

Thanks for the input. So the general concensus is that Access is bad, SQL server is good, and VFP somewhere inbetween for the database.

The front end app can be either VB or VFP, but there seems to be alot of support for VFP.

Some of our developers (and the systems department) are scared of the jump to SQL server. Should they be? Other than the investment, is there that much to be scared of?

Is MSDE really a viable option?

Thanks again for the input.

 

[rgbean]

"MSDE IS SQL Server!" I sat in a DevCon session last year and the speaker had the group repeat this "mantra" at least twenty times during the 40 minute session. The only difference is that MSDE can be distributed most of the time for free, it is "optimized" for a maximum of 5 users and comes without a lot of the utilities that SQL server has. MS recommends that developers use the real SQL server to develop the database and code, and just distribute MSDE for demos and locations that can live with it's major limitation.

Rick

 

[jonscott8]

Bare in mind, as you posted in a VFP forum, you will (and are) receive biased opinions.

Try also thread184-45568 Jon Hawkins

 

[wjs2]

jlschulte,

You will find this forum highly prejudiced toward VFP and for good reason. Deployment of VFP exe's is one of the best, if not the best, cost effective solutions around. With that in mind, your main concerns would be the growth potential, since VFP has a 2 Gig limit on tables, throughput, VFP will query 5,000+ records per second from networked 5M+ record tables (200 bytes per record) on systems I am currently running, continued support for the platform, and, assuming you have the programming expertise available. (I would really like to see some other numbers posted here to see if this is as good as it gets.) The 2 Gig limit is virtually eliminated when you consider upsizing to SQL and other ways you can split tables to keep under the limit. The upsizing requires you pay a little more attention to compatibility issues with code you implement.

Having gone through a 2.6 to VFP 6.0 conversion, I would be the first to tell you there is a lot of work to do with the interface. The plus side to this is, with the use of VFP classes you can build, once built, can be used over and over to streamline the coding effort.

If you can't tell, I'm an avid fan.

WJS

 

[jjgraf]

there is a third option now for developing applications. You can create distriputed COM+ objects in VFP and then access those objects via VFP and use XML to transfere data between the multiply teirs.

Whith this method you do not have to open the DBFs across the network or create connections to all the clients across the network to access SQL. if you do it this way and you want to make a ASP website you can then utilize the bussiness logic you already wrote.

this would help with performance problems abit and help with corrupt tables because a clients machine crashes it does not have the DBF table open the COM object has it open on the server.