I understand your POV. We are in the luckier position of already having a large app up and running and doing a great job. That doesn't stop the potential customers still objecting to the nature of the beast, despite the obvious success and scalability of the existing solution.
FWIW, I think that Citrix will continue to be a big winner for some time to come.

>The net of all this seems to be that I'm fairly certain VFP could handle the workload w/o breathing hard, given adequate hardware. But believing it and convincing someone else are two different things. We're dealing with large corporate clients, and they make decisions based on CYA - cover your a**. No one ever got fired for buying an SQL based solution (which means Oracle or MS SQL), but a VFP database is an unknown for them. We can, however, mitigate some of their FUD by pointing to real-world examples of large scale VFP apps using native tables.
>
>The real issue here is that most of the advantages of a SQL database are negated with our application combined with a terminal server/thin clients. But it's hard to make someone understand that. On a terminal server, for all intents and purposes, the VFP application is a "local" application. Our customers are retail environments, and closed at night. So they have maintenance time (for backups, etc.) Since no data moves across the network (only screen shots, and mouse-clicks/ keystrokes), data corruption and index issues are no more or less likely than an SQL database. Interestingly, our sister company uses the application on a terminal server with 30+ workstations, and so far( 2+ years), we've never needed to reindex (we do pack every few months.) Also, having all the data and application on one server, and using diskless thin clients radically changes the security landscape, not to mention the manageability of the system. Terminal services is not a pancea, but it does works very
>well for certain kinds of applications. Really, we're working against a mindset here, not concrete, real-world objections. There are some advantages to many of the SQL databses, no question about it. But the comparisons are not as cut and dried as they used to be. We're been recommending terminal services since Win2K came out, and it looks even better in Server 2003.
>
>That said, here are some great links to VFP applications (compliments of Tamar Granor) Most have been converted to SQL backends, but it's still a good starting point.
>
>http://fox.wikis.com/wc.dll?Wiki~VFPSuccessStories~VFP
>http://fox.wikis.com/wc.dll?Wiki~ApplicationCrossReference
>http://www.advisor.com/Articles.nsf/aid/MATIV02
>http://www.advisor.com/Articles.nsf/aidp/RUBEM67
>
>
>>Chris
>>You may, but please keep it brief, we're very busy right now. Also anything of interest to the community should go on this forum.
>>
>>>Thanks, this is what I was hoping to find, an example of an existing VFP application running under high volume. Would it be ok if I emailed you directly to follow up on this?
>>>
>>>Chris
>>>
>>>>Hi Chris,
>>>>One of our clients is running about 390 users at the moment, about 150 over Citrix in about 15 locations, and 240 direct to the network at HO. About 10GB of live data being accessed and about 20GB in backups, which are also accessible live.
>>>>All the files are native foxpro tables. The network stability and quality is extremely good and so we have little or no reindexing or data corruption. I can't remember the last time we lost a memo field. Maybe more than 5 years ago. We've gone to getting the users to run reports against day old data to reduce load on the primary server (ie data warehousing).
>>>>So all well and good.
>>>>With continued growth we plan to migrate some tables to SQL Server, but there's no immediate performance or cost reason for doing so.
>>>>We also do about 4 million VFP generated pages per week from the web site.
>>>>See www.ht.com.au
>>>>So at times the transaction rate must be quite high, and no problems to report.
>>>>
>>>>
>>>>>Given sufficient hardware resources, does VFP have any inherent limitations as to the volume of transactions/data updates it can handle in a given period of time? Or is it just related to how fast the CPU/hard drive can process them?
>>>>>
>>>>snip...