<< On more question on this server app with 100 users across the country. If one office had a computer crash could that corrupt the data on the server and cause problems for the 99 other users? >>
You have a lot of architectural decisions to make about your application before you can even approach this question. Obviously, when designing the architecture of an application-for-hire, no downtime should be one of your design principles. The biggest questions here are: - Are the users actually touching the database? Or are they simply saving data in an intermediate format that's "sucked into" the database by a server process? - Is everybody working in a _single_ databaes instance, or do they have their own instances? Separate instances mean less chance of spreading problems. - Are the users computers actually connected to the database? In a typical web application, the computers are only actually connected for very brief periods of time. Client server apps can be designed either way. A terminal services application will most likely be full time connected. The less connection time, the less chance of corruption. -- Larry
