Bob,

Yes, the VFP data engine is built in to the VFP ODBC driver. You should get pretty much the same performance using the VFP ODBC driver as you would using VFP directly. There will generally be a little bit of overhead involved in translating the request into something VFP understands then getting the data back to the client in a format it understands.

The main reasons to write an automation server would be scalability and re-use. You could have multiple automation servers running on different servers. If you use the VFP ODBC driver it's going to be like having an instance of VFP running on the server every time you need to access data from VFP. If you write an automation server and encapsulate all your business rules, you could use this server from any COM-compliant application. You wouldn't have to write each client to enforce the business rules.

Of course if you're writing a simple web application that just queries a VFP database and you don't expect a lot of simultaneous users, VBScript and ODBC might be the way to go.

>Well,
>
>Sure... I know what an ODBC driver is, but, what's inside it...
>
>for example.. if I use ASP with the VFP ODBC driver... and I excute a select statement, is the VFP engine built into the ODBC driver... will it perform the same as it I did the query from the VFP command window?
>
>Just curious about this when trying to evaluate a module we are going to the that must run on a web browse. It the ODBC driver provides the same speed as native FoxPro access, why not use VBScript to do the whole thing as opposed to writting a VFP automation server and calling the server.
>
>Of course, if the component already exists its a no brainer, but, if I only need to do this task for the web?
>
>BOb