cons for a dev machine in a different version of sql from our prod server

  • hi, im not a dba.

    For a couple of years our dev sql server has been a 2022 vm std instance with varying levels of horsepower depending on how loudly we objected.   For many years our prod , 2019 on prem std.  both have ssas, ssis, ssrs and of course the engine.

    We are looking more closely at "real" testing/deployment etc  and the question of how inappropriate this sql partnership really is has come up again and will finally be heard.

    i have to look at the backward compatibility of each and honestly dont recall if that means newer functions etc (like concatenate) are forbidden on the newer version in spite of backward compatibility or not.

    my warnings to our group will be more along the lines of inappropriateness in ssis and ssas.  And the fact that lines of code actually differ in each for the 2 different target instances.   ssis most notably in the native sql driver (we manually installed it there a couple of times already undrerstanding its being deprecated) that keeps disappearing off the dev instance every time there is an upgrade there.   ssas most notably in the connection that basically tells the server to relax the encryption rules.  unfortunately our prod server was set up years ago without encryption and its my understanding this will be a tough road for us to overcome.

    can the community comment on what i've shared thus far?

     

     

     

Viewing post 1 (of 1 total)

You must be logged in to reply to this topic. Login to reply