>George,
>
>>
>>Nevertheless, by "payback" I meant risk versus reward. How many VFP deveopers would you think that this would immediately benefit? How great a change would have to be made to existing, debugged code to accomplish this? Believe me, the Foxteam would look at this in exactly this context.
>
>First, I truly think that a majority of VFP developers would be anxious to have this kind of feature available to them.
>The idea is that NO existing and debugged user code would have to be changed to implement this. Of course VFP internals need lots of change, but that is the case whenever we get new features and facilities in VFP. I can't begin to imagine the changes that were necessary to implement NULLs and no doubt that was done to have compatibility to SQL Server regardless of the fact that the SQL Server literature I've read all advocates avoiding use of NULL fields if at all possible.

I wasn't referring to the user. I was referring to the product itself.

>SNIP
>>Sure existing apps would working basically unchanged. However, as it is, creating a remote view is not a big deal. Create the ODBC entry, add the connection to the DBC, and create your view. Then it works just as if it's a native table. Further, with the Installsheild addition, creating the ODBC entry on a workstation isn't a problem any longer.
>
>Still, what could be easier, for native VFP I/O and data, than using simple xBase and SQL commands than we are all used to?

My point would be since the data is server side, you probably wouldn't want to do so. You'd design as you would for SQL Server.

>SNIP
>>
>>If, however, greater security is required than can be provided by the network OS, then SQL Server is the way to go.
>
>Sure SQL Server provides more security options that might be needed by some applications, so those would migrate there regardless (as today).
>But I think that you underrate the potential of workstation operators to do silly things. Many shops have very high turnover rates in such positions and training in this little detail is minimal and often misunderstood.

No, I don't. After 15 years here, I've seen just about all the silliness I care to. I had a friend who I warned about the SirCam worm. Gave her all the details, including what exactly the message would say (both English and Spanish versions). Told not to open any attachments. Sure enough, she did and got the worm.

>>Performance I'd argue with. What you're going have to have is a component capable of handling multiple requests (like SQL Server). I think that the performance would probably degrade below the point that's provided by ODBC, since the ODBC driver is client side as opposed to server.
>
>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.

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.

>SNIP
>>>3) Yes, a client side UPS is smart for sure. But that would do nothing to prevent the operator from simply turning the workstation off inopportunely, and this does still happen. We still see enough messages regarding corruption here at UT to confirm that there remain problems out there, and this proposal should prevent much of it.
>>
>>Sure we do, but again nothing can be done about user stupidity except educating the user. There is a point here though about corruption in a server scenario. Even with a server side UPS, there's still going to have to be a considerable amount of cost involved in regards to the server. "Inside SQL Server 7.0" from Microsoft makes the following recommendations. In this case, to implement these to prevent server side corruption.
>>
>>1. At least a SCSI drive, but preferably a RAID with mirroring and striping. (RAID1+0).
>>
>>2. A drive controller that it capable of being write-back caching disabled.
>>
>>In short, you just can't set up a run-of-the-mill server and reasonably think that you've solved all the potential corruption possibilities. Further, it'd be best that it be a server dedicated to this task.
>
>I really don't think this is a serious problem at all. I believe that SCSI (RAID or not) is straight-forward and the ability to disable write-back cache is pretty much standard. I think that "Inside SQL Server 7.0" mentions the ability to correctly process (write-) cached data after failure is the hard-to-find product.

This relies on two things. One is that the controller cannot report back a write until the bits are actually on the disk. Two, that the RAID setting be at least RAID-5 (striping with parity checking) or RAID 1-0 (striping and mirroring). In either case, these are among the more costly. In the case of RAID-5, the media can fail and the disk can be recovered on the fly.

If you're talking about simple recovery from the transaction log, then only the first point applies.

>SNIP
>>
>>Yep, the network itself is over 100 servers, I've got about 40 or so apps running on a handful of them.
>>
>>No, I don't think the "for the desktop" thing too far. There's a significant difference in the design paradigms between developing for a desktop (even if the data is on a LAN server) and developing for a backend like SQL Server. I get the feeling sometimes (and it's just a feeling), that some folks either don't understand this or simply refuse to acknowledge it.
>>
>Let me repeat the objective of this wish. It is to permit design and development exactly as today yet to transparently allow (some) VFP data to be stored and accessed through a VFP 'server' product. In other words, to extend the current design paradigm for VFP applications for years to come.

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