>Thanks for the info. My company designed an application to track applicant information. When it first was proposed I said Access wouldn't be able to handle the workload. My prediction came true after a couple of months. Now they want to redesign it using Visual Basic. I believe they will use the jet engine again believing that Visual Basic is going to make a difference. Guess it's time to put my physic ability to work again.

Bill, you are in an interesting predicament because your company's strategy is probably being swayed as much by "internal" business factors as by technology factors.

I would like to suggest that you consider the ultimate size of your application's deployment. If it will eventually have many dozen or more users, you could do fine with VB as a front end and SQL-Server as the back end. Because of market-share and maintainenance issues to consider, VB is today a more politically correct way to go, and it actually does have a slightly more flexible GUI development environment. VB's RDO (Remote Data Object) capabilities make its C/S interface a bit more flexible than VFP, too, but not necessarily higher performance.

However, for a deployment that will be serving a LAN workgroup rather than an enterprise of 100's, you will be more productive and cost effective if you use VFP. The C/S capabilities of VFP are fine if you eventually need to upsize.

I personally prefer VFP because I love its speed, flexibility, and true OOP features.

I would NOT use Access. If VFP is not supported by your company, then I would go with VB/Jet/SQLServer.