Thanks very much for the reply. this is just the sort of information I was looking for. it seems in my case at least that the VFP database solution will meet my needs just fine. the application doesn't need 24/7 availability and so rebuilding indexes and packing can happen during the night (or as needed).
Any ideas about a front end? what i am needing to do is to make a series of forms that can be filled out over the net with drop-down lists and grids (perhaps) and the like, but i know little about the technology that i can use to do it. any suggestions would be greatly appreciated.

mant thanks,
Jordan

>>Hi all,
>>was just wondering on the suitability of VFP for Web applications. i know you can use the language as a middle tier, but what about the database itself? do i have to use SQL Server or will VFP database do?
>>
>>thanks
>>Jordan
>
>Hi Jordan. For some types of web apps, a VFP back-end is quite appropriate. But it depends. In my experience, there are three primary issues that may deter you from using a VFP backend as a web data source. (It will really depend on the type of app, so these are general comments. If you want to provide more specific details it may help the conversation along....)
>
>First, there is the security issue. A "true" DBMS has a much more robust security model, which can be important in a lot of situations... and I find it particularly important in cases where you are exposing servers to the web. If someone manages to get access to the server hosting your database, at least with SQL Server you have a tighter security system in place. VFP7 allows you to build in database events etc. that can help you lock users out, but it's not as secure as SQL Server or Oracle (or others).
>
>Second, although the VFP database seems to me to become more and more robust with each release, I still find that in high-traffic environments I need to recreate indexes periodically. This is not a *huge* deal unless part of your reason for "going-web" is to be up 24x7. Then, it might or might not be an issue. (On a related note, if your app deletes records frequently and you need to pack frequently, you will have the same problem.)
>
>Third, if you use SQL Server or another database product, you can execute the database code (SELECTs, SPROCs, etc.) on a different box than your middle-layer code. This allows for a nice separation/balancing of duties and can really help when debugging bottlenecks and making hardware upgrade decisions. There are ways to accomplish this with a VFP database -- basically, by writing your data access code in separate components and calling those components on the database server -- but it's a bit more complicated and somewhat less orthodox.
>
>But, ultimately, your decision will depend very much on the type of app you are designing. If the data are not sensitive, downtime is permissible, and the # of users will be relatively low (hundreds, or thousands, rather than tens of thousands+) then the VFP database may work just find. And, in my experience, a VFP component <--> VFP database approach will show better performance than a VFP component <--> SQL Server approach (I probably just opened myself up to some flames, but that has been my experience).
>
>Hope this helps.