One thing we do, which has nothing to do with ODBC, is use WebConnect to serve up read-only VFP data via the browser. This way the user does not need access to the data server, just the web server. The proc used by WebConnect retrieves the data from the server I have indicated. As long as the web server (which is NT) can see the server where the data resides, all is cool. You can even set up WebConnect on a Win95/8 machine and do the same thing.

>You're right with the exception of the part about the shared directory. In order to set up the DSN on the other computer, you'll have to tell it where the data is. If the data isn't located on a share, the other computer won't see it! This is a problem if you're using VFP data and don't want people having full access to the data via other applications other than your own.
>
>So what are the options? Well, for Win 95/98 machines you could create a read-only share and store a copy of the data there. Not exactly efficient but Win 95/98 isn't known for it's security (none!). If you have an NT Server available, store the data there and control the access via NT User privileges.
>
>HTH
>
>>Hi!
>>
>>I have "played" a little with ODBC (not making anything "serious" with it), but I was wondering the following:
>>
>>I've always thought that ODBC could be used via the network, making a client/server design. For example, I could set up a DSN on my computer that uses data on my computer, and have another computer use this same data through ODBC, without that data beeing on a shared directory. In other words, the second computer can't access directly my data, but has to ask, via ODBC, to my computer, who will fetch what it needs (ie process the SELECT instruction), and return the result set, just like a client/server design.
>>
>>Now my question is: was that right, and if so, how?