djkym I'm not quite sure virtualization is the answer here. The purpose of migrating to SQL Server is to separate the business logic from the database function of SQL Server, which allows the server to be a "relational database management system."
The architecture as described by Jon obviously has many people scratching their heads. I think he needs to clarify what he means when he says v4 "has SQL built in...and running in peer to peer mode is faster than in client server."
All applications that use SQL Server as their datastore require an "instance of SQL Server" on which to attach the database. If you already have a SQL Server Instance, like Leslie, running anywhere on your network, you should be able to install the AC4 database to that SERVER.
The application connects to the database using a "connection string." In .Net we use a native SQL client connection. If you are not using .Net an ODBC connection is required. In either case the connection string simply provides the location to and the credentials for logging on to the server.
The power of using the SQL Server is that there is so much more functionality inherent in the server, which, in a well architected application tremendously decreases the need for the client to do a lot of the data processing.
For example, someone just recently mentioned providing an audit trail. This is a fairly common practice using SQL Server that is very difficult and resource intensive when done on the client. This type of task requires the application to keep a log of what data was changed, when it was changed, and who it was changed by.
This sort of task is easily handled by using an "update trigger," which is a piece of T-SQL code, that automatically runs anytime a record is changed. The BEAUTY of this architecture is that because the code is on the server, it will fire ANYTIME the record is changed, even if it is changed outside the application.
Try to do this in your application and you find yourself going thru all kinds of gyrations and multiple inserts to accomplish what is done invisibly by a trigger.
A place where this functionality is more germane to AC is when a patient has a name change. Using a trigger, can automatically insert the old name into a table along with the PatientID, and keep track of all the patients names. So if your patient is Elizabeth Taylor, AC will handle her many name changes just fine.
Last edited by gkfahnbulleh; 11/17/2008 5:29 AM.
