>I have a app that uses remote views and ODBC to connect to a .DBC rather than MSSQL. my customer would like to use this app on the Web through TCP thus using the Web...

Joe, using TCP/IP does not necessarily mean "using the Web".

Here are your 3 basic choices:

1. Truly using the Web, where a Web browser connects to a Web server, and the Web server uses some form of database connector to pass queries and updates off to a database engine that is usually close by. In addition to using TCP/IP, you are also using HTTP as the method to exchange packages of information, and HTML as the "language" to describe forms and user interactions. This is how Universal Threads works.

2. Using a client-server approach, like a VB or VFP app connected to an MSSQL Server. You can use TCP/IP as the network transport protocol to exchange data bewteen clients and server. This is a "fat client" approach. If you use TCP/IP, the clients and server(s) can be anywhere on the net. This often creates a major security concern for any sensitive data, so these applications are usually implemented on an Intranet, and separated from the Web via one or more security measures.

3. A "grow your own" connection between client(s) and server(s) that uses TCP/IP as the transport protocol. This is relatively easy to do if you have a nice
and reliable Windows Sockets library at hand, as you can create a socket-to-socket connection between any two applications anywhere on the net. You can talk to a Unix app or a VAX/VMS app or a Windows app. Using this approach, a client app in Miami can connect over the Internet to a server app in Seattle using TCP/IP, but the TCP connection port number can be private (that is, nobody but apps' developers need to know it), and the data passed over the connection can be encrypted any way you choose, as only the client and server apps will know what the data means or how it is structured. The transferred data is not constrained to follow any specific standard. This can be a very effective and efficient way to implement a WAN client-server application over the entire net, but if the different types of data packets and transactions (and their accompanying "do this" or "do that" commands) becomes large, you can end up with a sprawling network-bound conduit embedded in your application that conforms to no standards but the company's own.