>Stephen,
>>
>>I disagree with replicating data between VFP & SQL. That's not optimizing, it's only a crutch. I have found that the people who are SQL only are serious about their decission. They have invested alot of capital in equipment, software and licenses. I would try to do what the client wants his way, and allow VFP to manipulate the data my way.
>
>It's not about manipulate data in the VFP environmant. It's about screwing up performance by using lookuptables. depending on the way you use VFP as a front end-tool you already use the VFP database as basis for your connections and views. I don't see any problem in adding a few lookuptables also (maybe also data for OLAP so the server don't get stressed when querying large reports)
>
>>Moreoften the biggest issue for VFP is security, in that there is none. SQL you have some very substancial security. Don't tell me about Encrypting data because that's not security, it's duct tape.
>
>I've found that the tables you want to replicate into a VFP database are for lookup reasons and are not THAT confidential, that security can't be solved in another acceptable way (Security on file or directory level).
>
>Walter,

I have found that DBA's are more anal about their data. It's theirs and we can just borrow in, manipulate it and add to it. but in the end it's still theirs.

Localy cashed lookups are good. State Names and postal codes are great. Customers are not. Inventory items are also not.

Are you, we speaking of a WAN interface spanning countries or cities? Or is this more of a big campus environment. Granted you do different things depending on your environment. Heck there is more than 1 server dishing up winzip7 downloads.

I guess the point I am making is that we have to listen to our customers about what they want not how we are going to deliver it. The current project I'm on is BASS ACKWARDS, but I just knod my head and go no problem.

__Stephen