>George,
>
>I'm happy that you've replied, and those 2¢ are much more valuable here in Canada.
>My comments are interspersed with yours...
>
>>< big snip >
>>Jim.
>>
>>Frankly, I didn’t want to become involved in this discussion, but some of the ideas demand a response.
>>
>>I’m certainly not speaking here as a representative of Microsoft, even though I’m an MS MVP. What’s here is strictly my opinion.
>>
>>There are a number of reasons why I’ve just two words for this wish: Forget it! This isn’t something you’ll see now or ever. Allow me to elaborate.
>>
>>
>>1. Business Economics – Where’s the “payback” here? This isn’t something that can be implemented quickly and easily. Even if it were, it’d probably be limited to VFP table, SQL Server, and Access databases. I’ve more on this point later. You’ve got a product, or part of a product, that’s only of use within VFP and it’s free. Of course, VB and other MS products could use it, but that’s it.
>
>The "payback" is that I believe that MS could charge a license fee for this facility, separate and apart from the license for VFP itself. I did mention this in my original message. I believe that a 'per seat' license wouldn't work though.
>In addition, mine restricted this to VFP databases and tables only. Other contributors have suggested that it could encompass any other RDBMS too. While I don't doubt that, I have, so far, 'reserved' the decision as to whether or not the wish submitted will do so. My inclination is to keep this one separate, but am waiting to see what else may develop to change that.
>Assuming that this one does remain separate, and that someone else (Mr. Sosa, perhaps) submits a wish for a SQL SERVER equivalent of this (or suggests that such be integrated into this) then that would be a separate issue and we could comment then.
>>
>>The point is that if any other product wanted to use this “black box”, they’d have to buy VFP.
>
>As noted above, this is (so far) restricted to VFP and so buyers of this "product" would already own VFP license(s).

OK, this is partially my mis-understanding (or perhaps integrating your original message with other). My mistake.

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.

>>3. Existing functionality issues – What you’re suggesting is already available through ODBC, ADO, etc. What’s really to be gained, outside of making it a bit easier to implement this functionality? There’s nothing, in my opinion, really. We already have remote views, and SPT.
>
>"A bit easier..." is understatement, George. There would be no need to implement these additional available facilities! Existing applications would work basically unchanged!

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.

>My first message listed some benefits in summary terms. Others have added some more. But the biggest benefit is significant additional flexibility/security/performance options.
>- Flexibility by coding as usual yet employing a 'server';
>- Security by having the data in a better protected area;
>- Performance by reducing transmissions across the wire and having scalability for the 'server'.

I won't address the first point, for that's given.

If, however, greater security is required than can be provided by the network OS, then SQL Server is the way to go.

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.

>>
>>
>>4. Technical Issues – Here’s where we get to some serious problems. Connecting to a VFP database or table is one thing. Connecting to an SQL Server table is quite another.
>
>That is my initial feeling too, and that is another reason why I restricted this to VFP databases and tables to start with.
>>
>>SQL Server needs information from the client side in order to connect. First, there’s the issue of authentication. SQL Server provides two methods: Windows NT/2000 authentication, and SQL Server authentication. Since the “black box” is on the server, it, at least, has to know which is being utilized. So the client has to know what kind of network it’s connected to: NT/2K or Novell.
>
>I do believe that these kinds of issues can be solved. A simple off-the-top-of-my-head approach is to have a separate .INI-type file on the application (client) side (VFPtoMSSQL) that lists the required information there so that the client could send it along to the "black box".
>But, again, this isn't really part of the intended submission at this point.

Registry entries, but I think I addressed this about my understanding.

>>
>>Second, because of licensing, it has to know the NIC identifier of the workstation that’s trying to connect to it. So the client has to provide that as well.
>
>I think you'd agree this isn't really a problem.
>>
>>This is just what I can think of, in terms of technical issues. There’s also the overhead involved in connecting with a VFP table.
>
>Well if I thought that this was a serious issue I simply would not have started this thread in the first place. Not that I KNOW it's not. I just sense that it isn't.
>>
>>Don’t get me wrong, Jim. This is a good idea, just not practical.
>>
>>While I’m on the subject, here’re some more ideas that probably won’t be implemented. Again, this is strictly my opinion.
>>
>>Less chance of table corruption – Sigh. This really isn’t a VFP problem. Corruption occurs, principally for two, inter-connected, reasons. One, the workstation or network goes down in the middle of a write. Two, write-back caching.
>>
>>This later issue isn’t controllable from within VFP. VFP relies on the Windows API for reads and writes. SQL Server does its own file I/O, and strongly suggests that write-back caching is disabled.
>>
>>The solution is to buy a UPS for at least the server. Having one on the client-side is also a good idea.
>
>Addressing the three prior paragraphs:
>1a) Yes, write-back caching is a problem and this could do nothing to solve that.
>1b) This would effectively remove the aspect of the workstation going down having any effect on the possible corruption of data.
>2) nothing to say (other than you're right).
>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.

>>The question comes down to, “How valuable is the data?” Quite frankly, data corruption can occur even in SQL Server, if the hardware is done “on the cheap”. In that environment, RAID drives are strongly suggested, as well as UPSes, for this very reason.
>>
>>The 2 gigabyte barrier – If there’s more than 2 gigabytes of data, then use SQL Server. Two gigs is the exception, not the rule, especially for a desktop application.
>
>I have no qualms here. I realize that someone has suggested that this could be a way of breaking that barrier for VFP tables, by compressing them and decompressing on the fly. But I have not replied to that one yet, because I'm still thinking it through.
>I had no interest in this aspect in my initial proposal, especially because I remember Craig B's repeated assertion that it would break too much of VFP's internal code (and he did confirm that he heard this directly from VFP Team members).
>
>>
>>Security/Data Encryption – Again, if this is a problem, and the security available through the network isn’t sufficient, this needs to done via either SQL Server or MSDE, To reiterate, VFP tables/databases, are for the desktop, and are designed for that. Sure, you can deploy them on a network and get reasonable results. However, if more is needed, then SQL Server or MSDE is the answer.
>
>I have reserved judgement on encryption. Still mulling it over. It isn't a personal hot-button, I can tell you that.
>Really, George, you are carrying your "for the desktop" too far. I hazard to say that VFP has always been designed with a network in mind. I expect MS marketing to 'downgrade' the perception of one product to push another, but not us user folk. I'm guessing that you have quite a network (or networks) of very useful VFP apps. at your company.

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.

>Thanks,

No problem.