For each server, you'd need a.) IIS web server and b.) web app (1 for central and another 1 that all branches will use)
From what you said, you'd have a centralized web site which people would initially login on. This web app would have an authentication routine and would determine which branch based on the user data. You could simply present the user with an HTML page with the appropriate link at this point or just re-direct them directly after login.
All the other web sites would run an identical web app that does the core application...
>>Brenda,
>>
>>I wouldn't be copying your data to SQL if you don't have to. Why not use the >live data? It's usually a big headache when you have to copy this way and, in >my experience, nobody wants the reponsibility for keeping everything in sync...
>>If you can get away with keeping everything in VFP, you could use ASP COM, >FOXISAPI, or any number of 3rd party apps that let you use VFP to manipulate >dbfs and use existing vfp app logic.
>
>I would love not to copy the VFP data to SQLServer. My Internet Group says they will only allow SQLServer but lets for this conversation ignore that.
>
>Please help me with the concept and the terminology. So when a customer logins in to the Internet application, I would have a local table that tells me which of the 30 sites his data resides. I would have a web server at each of the 30 sites and would connect to the web server that has his data. Then the screens would access the VFP data directly. And it could update the VFP data directly. Is that the idea?
>
>What are some of the tools that would have to be used, setups at each site that would have to be done, software and hardware that would have to be purchased? I am not looking for an exact list. Just a general idea in what might be involved.
>
>Thanks
>
>Brenda