Gil,

SPT is just SQL Pass-through. Instead of using views, you create a SQL statement and send it to the server using the SQLEXEC() function.

I'm not sure about your bridge idea. Would the IVR always have the most up-to-date information? Would it be a problem if it didn't? It seems like it could be a lot of extra work. After all that you may decide at a later date that you want the entire application to use SQL Server for other reasons.

Aside from the MS web site, I know that FP Advisor and FoxTalk have both had a number of articles about c/s programming. You may want to look for these.

One more thing. Are you sure the IVR won't work with VFP data? If it supports ODBC it might work.

>Thanks a lot for your replies, and Josh thanks for giving such a clear picture of what I'll have to be facing in the near future. The development is still on a very early stage so it wouldn't be too difficult to adjust to a new structure. I am using views in some areas but I'd like to know about what you refer to as SPT's. I think we don't have any other choice but to go ahead and do it. The IVR system we are implementing needs to be able to talk to our main database and request/update information as needed. Now, I've had a little bit of an idea so let me know what you think; what about building a bridge between the two technologies?, which means leaving the VFP database structure as it is and creating an SQL server for just communicating with the IVR, have it send/receive information to/from it and when the committing process in the IVR is executed, have VFP read and process the results of each transaction and send these results to the database. Is this too nuts or possibly feasible?
>
>Thanks,
>
>Gil
>
>P.S: Do you have any pointers on where to get any info on SPT and/or C/S migration? I will be checking the MS VFP site to start. Thanks again.