>Or substitute the famous UT message for a tighter query scope :"there are over 500 items in your query".

Well, that works in some cases. I do that on my site, but it's not the best way to handle things. In some cases you don't know how much data will get returned until your run that complex SQL Statement in the first place. Michel gets around this by using a free text engine on the data which is one solution to improve performance of text search.

>VFP does do a fairly spiffy data handling job. Most times return data is a just a string. I don't know if other technologies can render a return data string faster or better than VFP. But if they can and it's that important - then they should be used! A lot may depend simply on how will the project is designed and what the capacity requirements are.

VFP's data engine is fast and easy no doubt, but it's not unique by any stretch of the imagination. There are a few things in VFP's native data access that are nice (mainly the ability to tie into all functions and custom UDF()s directly in your queries that are somewhat Unique to VFP because it's not just a SQL engine but a language and data engine combined.

>Not sure I get the analogy.
>I was suggesting the possibility that the broadest market segment might still be relying on CGI - and could possibly be relying on it for quite sometime. In many cases, CGI would not require JSP or ASP! We can do a pretty good job with foxISAPI in this market. (Note I continue to read and re-read "foxISAPI.htm"). You wrote that back before we had STRTOFILE. You need to re-do it for XP!:)

That technology is dead. Abandoned by Microsoft... <g>

Seriously, FoxISAPI has a number of warts most of which could have been easily fixed but weren't.

>Price is never an issue - with the headaches you take on - I think you have under valued your product. But - you do have bunches (and bunches) of satisfied and thankful customers (more like a following!) - and that is priceless:). WC COMs are responding to requests all all around the world, 24-7! That, Mr. Strahl, is quite an accomplishment!

Thank you, but that wasn't really what I was getting at. The point is - in general - that paying for a solution that is relatively cheap in comparison to project cost saves big in project development. It doesn't even have to be anything as fundamental as a 'framework' but controls, support classes etc.

For exmaple, I am often amazed to see people here post elaborate questions on how to do FTP or SMTP mail and then re-writing everything when there is a bunch of free stuff available here (if you really must re-write) or full featured and supported tools that cost very little compared to the time that goes into writing from scratch. You'll see those same people asking 20 questions on how to make X work - that time alone probably cost more than a small purchase.

Same sort of thing with say a home grown FoxISAPI application...