George,
SNIP
>>Here I must disagree strenuously. Of course this is the essential part of the design (by the VFP Team) that is crucial. But they know how to accomplish this.
>>I realize that processing client-side (as is the case today) is a fine way to distribute processing load. But we mustn't forget that there are also overheads and limitations in this approach today.
>>Later you mention "run of the mill" servers being insufficient for something like this. While I agree, this is not so far-fetched or costly. I've been using SCSI drives for years now, as I'm sure many have. But the main issue is to at least have this option, which doesn't exist today! We can extend the life and reach of our VFP applications in a straight-forward manner with this. Today we are often faced with significant re-design, or even jumping to different platforms, to meet such requirements.
>
>Then we'll have to agree to disagree. Making the assumption that this "server" would be able to work on whatever network (NT, Novell) there is no way that it's going to out-perform SQL Server. That product is optimized for NT/2K so it won't run on a Novell box.

An important point that I probably should update my wish document with - I believe that it would be acceptable that this 'server' be limited to run on Win platforms (98, ME, 2K, XP).
>
>I'd also make the point that the drives and controller can be very costly, it isn't hard to come up with one that literally costs 10s of thousand of dollars, like the one we utilize.

Yes, I've worked with one like that too and it was the best piece of hardware I ever saw for I/O.
But there are motherboards available now with RAID 0+1 SCSI built in as well as adapters with RAID 0+1 that I can easily afford.
Still, overall, this does provide an additional range of options basically involving hardware only. You don't put this stuff on client machines.

>
SNIP
>
>I understand. I just don't think that it's feasible.

Fair enough. I still think that it is.

Jim