Wiki Home

Vfp Back End

Namespace: WIN_COM_API
Using the VFP Port Listener method, we could easily write a Vfp Back End to create an all-VFP, truly client-server application.

The hardest part here, really, is defining a protocol.

Perhaps the best protocol to use would be ODBC, however I know nothing about what ODBC conversations actually look like. Would anyone like to find out and outline here (or put links) how to be the backend to an ODBC conversation?

How about a OLEDB Simple Provider ? See

That's right, I forgot: MS is downplaying ODBC and encouraging Ole DB, and it does look like it's not too hard to create an Ole DB provider. (This hints at what ODBC might actually be: Is an ODBC provider really just a .DLL with specific function calls? In this case, Ole DB is the same thing, only it would be an OLE-Compliant DLL, containing objects that can be instantiated through ActiveX...) - ?wgcs

It seems, as I read over the limitations of the Ole Db Simple Provider, that it basically can expose only one table: it says that only the first call to [b]openrowset[/b] will succeed. if this means what I think, then the OSP is useless if we want to actually exploit VFP's power in the back end. -- wgcs

It seems each backend (Oracle, MS Sql Server, My Sql, etc) has their own ODBC driver for the local computer, so it's likely that the conversation over the network has nothing to do with the ODBC standard, and that instead it is just the design of the local ODBC Driver that would need to conform. Considering this, creating this local ODBC Driver is probably REALLY the hard part. If we establish a Vfp Back End protocol, then perhaps the My Sql driver code (which I believe is Open Source) could be used as a base, then adjusted for this protocol.

Here's a first hack at a protocol:

TCP-Based Client Server Protocol for a VFP Back End

I propose this protocol to be as state-less as possible. (like HTTP allows)
It should be possible for this protocol to work over a synchronous connection like TCP, or a stateless (yet still synchronous, since the client drives the order) protocol like HTTP, which would allow it to work over the Web through a standard web server + ISAPI. In this manner, the protocol and the processor for it should be able to be separated from the TCP listener, so that the conversation would arrive through form GET or POST operations.

The basic operations needed are:

Also, to facilitate the security and rights management, all administration should be possible through the interface, provided sufficient rights have been established:

The TCP Protocol
Similar to SMTP,
Each request could be provided as a command name ( SMTP uses 4 chars, but for clarity, I'd think more would be nice... ), followed by parameters (unlike SMTP, the parameters I think should be Name="Value",Name2="Value2" pairs, on the same line as the command; This approximates what would be available through a Form POST).

After receiving each request, the server should return a response starting with a 3 digit number, PADL(resp,3,'0'), indicating how it was processed. The number makes it quick and easy for the client program to understand, and the text that follows can be easily read by a human. OR, the text that follows contains the content of the reply

Xm L could be used to encode the query results for transfer, but the Cursor To XML, XML To Cursor available in VFP7 isn't sufficient to rebuild an empty table (or any table) with an IDENTICAL structure to the original. I'm not sure in VFP8... PLUS, using the built in Cursor To Xml, Xml To Cursor functions would then require some specific version of MSXML to be installed on both the client and server... I don't know which version.

Contributors: wgcs
Category Projects, Category Client / Server, Category Challenges
( Topic last updated: 2003.09.02 04:32:30 PM )