>>I only wondered how you do it. That's all
>
>Now you know.... For some reason, I think you are hoping that something can't be done here... You will have a very long wait....
>
>>For myself I've found another strategy. I use the local VFP engine for lookup data. Giving me more performance (O.K. this depends on how fast you STP approach is). To manage updates on these local data I use the replication manager to replicate updates either directly or on a scheduled basis to the VFP database with the help of the VFP ODBC driver.


>
>Well, the SPT approach is very fast. As for static data, one idea that has me intruiged is in the user of the Active Directory. This storage mechansim is ideal for static data...or data that is not updated all that often...
>Now, with replication...I think that complicates the situation WAY too much.

Can you tell me some, I wondering what complications you did find that I didn't find. Especially for lookuptables you don't have to worry about RI that much.

>Replication, even with SQL Server 7, is a pain. It introduces more complexity that has to be managed. With the SPT approach, if folks are hooked up to a wan, they can pull their lookup data from a central server, thus negating the need to replicate...Also, the Active Directory is a good choice in these scenarios..

How does active directory fit in here ?

>Here is question for you... You now that your database is going to grow beyond VFP capacities in a year. When beginning the new system, do you:
>
>1. Start in VFP and upsize
>2. State in SQL Server, and then don't worry about it....

Absolutely a 2. But as I said the two engines are not mutual exclusive. With the replication manamger I could replicate the some (lookup) data to VFP.

Walter,