Hey Jordan. This is not a very easy question to answer because there are so many variables that come into play. As you probably know, you'll be looking at an HTML front end, but actually there are many variations on this... I'd recommend visiting a bookstore and looking for a good web development book, one that concentrates on data access (you don't want a "build your own web site in seven days" book. Be sure to get one that talks about data access.) I don't have a good reference off-hand, maybe someone else has a favorite book.

Meanwhile, here are a few important questions to start thinking about. They will help you narrow the scope a bit:
-- can you control the browser that your end users will use? If this is not a public internet app, in other words, if you can say "this will only work under IE" your development will be much easier! You only need to test for one browser, you can use IE-specific features, etc.
-- what kind of web servers will you and/or your client be using? If you are running Microsoft's IIS you will be able to make use of ASP (or even ASP.Net). If they are running UNIX servers the situation is much different (and totally out of my range of knowledge!)
-- have you thought about the middle tier? Where will calculations and data-crunching go on? You probably don't want to do this on the front-end, so you will want some middle-layer components. VFP is well suited for this in the situation you describe, as is VB, C++, etc. But if you are starting from scratch, you might consider a dot-Net approach. I am learning dot-Net at the moment but I am hardly an expert. Still, there's a lot to like in here and I know that the next project I start from scratch will probably be done in dot-net. On the other hand, if you have existing code that you are converting (or even existing components you are using as-is) then you might stick to the existing language.






>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.