The EVEN LARGER QUESTION is how will you support this installation? Who will you call when you have a database problem?
How will you handle changes to the database when there are enhancements made to AC?If you answer the first two, then here are are two issues to consider, depending on the AC4 database design.
1) If the AC database designed is to run all data access thru
stored procedures it would be next to impossible to use another backend WITHOUT recreating all the stored procedures in that backend. This I believe would be a violation of AC or any vendor's license as you would have reverse engineer THEIR BUSINESS LOGIC in your database.
For example if there is a stored proc sp_FindPatientByLastName that requires the @LastName parameter, then the ODBC call will simply call the stored proc and pass it the last name 'Smith'.
Something like:
EXEC sp_GetPatientByLastName 'Smith' The sp will do all of the work which is really, something like:
SELECT FirstName, LastName, ID from Patients
WHERE last name=@LastName
ORDER by LastName, FirstName
The SP will send the result set to the ODBC recordset. Remember all of this is done internally on the server.
2) If the above data access code is written as a part of the UI, then you may, and I stress may be able to do it, BUT you are taking a huge risk, because while ODBC IS SUPPOSED to use the same set of commands for every ODBC compliant database, it does not. My rule of thumb in this regards is:
In theory, practice and theory are the same, in practice, they are different.
