I came across this while searching for an answer to the same question. We’re upgrading our DB; both old and new are the same vendor and both are on the support list for our SQ server version. (Which is Community so the license issue mentioned above doesn’t apply.) So I’m guessing the procedure is: shut the server down, migrate the DB, change the pointers in sonar.properties, and restart?
Is there a formal page in the documentation for this (simple) case? If not, it’d be nice to have one. (Or add it to the page that discusses the vendor-change case.)
That page is explicitly about updating the server. I’m keeping the same SQ server but updating its database from an older version of MSSQL to a newer version of MSSQL (both versions are on the supported DB list for our SQ server).
I understand that, therefore I linked this page, maybe a bit misleading: There is no page directing you to update the database itself (without the server), therefore it seems that it would be working without any issue. Nevertheless you should do a backup and test the update first.
I was linking the page only since it contains the database maintainence that might come in handy when updating the database, in your case MSSQL.
That’s my guess too. My point (to the Sonar document writers) is that they should explicitly document this, even if it’s just a paragraph saying this works seamlessly for a same-vendor DB upgrade where both versions are on the support list for your SQ server version. That would be better than leaving it to the user to just guess.
Hey there @MisterPi, I split this thread from the one where you originally posted because that one was 4 years old. I love archaeology as much as the next guy, but next time please create a new post instead of bringing an ancient one back to life.
I appreciate your suggestion though! I’m going to flag this for the documentation team so that they can process your feedback, thanks.
Well it’s easier to continue an existing thread than to start a new thread and copy the link back to the original thread. Maybe a one-click button to do that?
I would suggest a general documentation principle, that “stating the obvious” is preferable to leaving it up to the users to guess.
