|
A customer is running ASA 8 and they are rolling out Windows 7 desktops. He discovered that his ASA 8 client install procedure did not work on Windows 7. He then found a SQLA 12 client which did install, and found that our application was able to talk to the ASA 8 server with the SQLA 12 client. He wondered, though, if running SQLA 12 clients against his ASA 8 server, he would be running an increased chance of database corruption, or some other problem. What do you think? |
|
Short answer: The customer is ok to use SQLA 12 clients to communicate with v8 server and should not expect any increase in probability of database corruption. Long answer: The normal procedure that we recommend (and expect) is that the database server is upgraded before the clients but we do sometimes (but not very often) see clients software being upgraded before the server. A good example of the server being upgraded first is a mobile synchronization situation: one database server and thousands of clients. In this situation we very highly recommend (and it is normally a requirement due to application changes) that the server will be upgraded and then over time the (mobile) clients are updated with new software as the mobile devices get upgraded or replaced. The above leads to this: When we make changes to the client-server protocol we guarantee that old clients will be able to talk/communicate with new servers but we don't (necessarily) guarantee the other way around. Having said that, AFAIK each time we have made a protocol change in the last 15+ years we have also attempted to ensure that new clients can communicate with old servers. I.e. I don't know of any reason why an new client would fail to properly communicate to an old server. But... independent of what I have said above, I don't know of any case where a database corruption has been caused by a communication error or a mismatch in client-server versions. Corruptions are typically caused by failures in the OS/IO systems, or (cough) bugs in the database server software. HTH |
