>I've written a VOD program using VB & VFP. It works okay, however, I want it to be database driven not have to use work-arounds just to make it work. I perfer to program in VFP, however, VB ran the MPEG ActiveX player better: didn't work quite as well in VFP.
>I have a NT server with 10 to 20 workstations requesting videos. The VB program runs on a Windows 98 workstation whick interfaces with the user making the video request. We've had to use text files in order to get VB & VFP to communicate. Text files were used becuase we couldn't get VB to R/W to VFP database. Really want the whole system to be database driven.
>From what I've read on some of the threads ...
>I could write a COM object, load and run the COM object on a server, then VB (running on a workstation) could use the COM object to R/W to a VFP database(existing on a server).
>Is this, basicly, how it works? Can all my VB programs use the one COM Object at once (muti user)?
>I would appreciate any advice.
>Thank you.

What you are describing is actually DCOM. The only difference between COM and DCOM is that DCOM is COM but where the server object lives on another machine. To get this to work, each client machine has to be correctly configured with security rights and through DCOMCNFG. DCOMCNFG creates the necessary registry entries that lets the clicnet machine map a specific ProgID with the correct remote path to the hosting DLL or EXE.

Creating a VFP COM object to do your database updating will work- but your only interface to the object will still be parameters (you probably know this). This is not so bad if you want to have your client program just pass the COM server an ADO recordset and the COM server can convert it to a VFP cursor using VFPCOM, and use the resulting cursor to update the base tables.