Best Pratices to maximize portability in SQL Server 2016












2














When it comes to develop the prototype of a solution, often the technologies has not been decided yet and might not be the same that will be used in the finished product.



In this scenarios I tend to use Microsoft SQL Server writing the queries as standard as possible to simplify the eventual migration to another Server.



Is there a way or some known practice to enforce the use of standard SQL over T-SQL dialect directly in SQL Server or via SSMS?










share|improve this question







New contributor




s.demuro is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
















  • 1




    Portability is a nice textbook goal, but it rarely happens in practice. When you have a choice between standard syntax (<>) and non-standard (!=), where there is no compromise on performance or maintainability, I always choose standard. But when it comes at other costs, or there is no standard equivalent I tap out and go proprietary. The things you give up just for the ability to later completely switch platforms wholesale just aren’t worth it imho.
    – Aaron Bertrand
    16 mins ago






  • 1




    The only time portability is a realistic goal is when you’re writing an app that needs to integrate with multiple platforms simultaneously because your customers use different platforms. Even then, unless you want functionality to be limited and performance to be terrible on all platforms, I would ship packages meant to take advantage of features of individual platforms.
    – Aaron Bertrand
    13 mins ago
















2














When it comes to develop the prototype of a solution, often the technologies has not been decided yet and might not be the same that will be used in the finished product.



In this scenarios I tend to use Microsoft SQL Server writing the queries as standard as possible to simplify the eventual migration to another Server.



Is there a way or some known practice to enforce the use of standard SQL over T-SQL dialect directly in SQL Server or via SSMS?










share|improve this question







New contributor




s.demuro is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
















  • 1




    Portability is a nice textbook goal, but it rarely happens in practice. When you have a choice between standard syntax (<>) and non-standard (!=), where there is no compromise on performance or maintainability, I always choose standard. But when it comes at other costs, or there is no standard equivalent I tap out and go proprietary. The things you give up just for the ability to later completely switch platforms wholesale just aren’t worth it imho.
    – Aaron Bertrand
    16 mins ago






  • 1




    The only time portability is a realistic goal is when you’re writing an app that needs to integrate with multiple platforms simultaneously because your customers use different platforms. Even then, unless you want functionality to be limited and performance to be terrible on all platforms, I would ship packages meant to take advantage of features of individual platforms.
    – Aaron Bertrand
    13 mins ago














2












2








2


2





When it comes to develop the prototype of a solution, often the technologies has not been decided yet and might not be the same that will be used in the finished product.



In this scenarios I tend to use Microsoft SQL Server writing the queries as standard as possible to simplify the eventual migration to another Server.



Is there a way or some known practice to enforce the use of standard SQL over T-SQL dialect directly in SQL Server or via SSMS?










share|improve this question







New contributor




s.demuro is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.











When it comes to develop the prototype of a solution, often the technologies has not been decided yet and might not be the same that will be used in the finished product.



In this scenarios I tend to use Microsoft SQL Server writing the queries as standard as possible to simplify the eventual migration to another Server.



Is there a way or some known practice to enforce the use of standard SQL over T-SQL dialect directly in SQL Server or via SSMS?







sql-server sql-server-2016 migration sql-standard






share|improve this question







New contributor




s.demuro is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.











share|improve this question







New contributor




s.demuro is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









share|improve this question




share|improve this question






New contributor




s.demuro is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









asked 1 hour ago









s.demuro

111




111




New contributor




s.demuro is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.





New contributor





s.demuro is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.






s.demuro is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.








  • 1




    Portability is a nice textbook goal, but it rarely happens in practice. When you have a choice between standard syntax (<>) and non-standard (!=), where there is no compromise on performance or maintainability, I always choose standard. But when it comes at other costs, or there is no standard equivalent I tap out and go proprietary. The things you give up just for the ability to later completely switch platforms wholesale just aren’t worth it imho.
    – Aaron Bertrand
    16 mins ago






  • 1




    The only time portability is a realistic goal is when you’re writing an app that needs to integrate with multiple platforms simultaneously because your customers use different platforms. Even then, unless you want functionality to be limited and performance to be terrible on all platforms, I would ship packages meant to take advantage of features of individual platforms.
    – Aaron Bertrand
    13 mins ago














  • 1




    Portability is a nice textbook goal, but it rarely happens in practice. When you have a choice between standard syntax (<>) and non-standard (!=), where there is no compromise on performance or maintainability, I always choose standard. But when it comes at other costs, or there is no standard equivalent I tap out and go proprietary. The things you give up just for the ability to later completely switch platforms wholesale just aren’t worth it imho.
    – Aaron Bertrand
    16 mins ago






  • 1




    The only time portability is a realistic goal is when you’re writing an app that needs to integrate with multiple platforms simultaneously because your customers use different platforms. Even then, unless you want functionality to be limited and performance to be terrible on all platforms, I would ship packages meant to take advantage of features of individual platforms.
    – Aaron Bertrand
    13 mins ago








1




1




Portability is a nice textbook goal, but it rarely happens in practice. When you have a choice between standard syntax (<>) and non-standard (!=), where there is no compromise on performance or maintainability, I always choose standard. But when it comes at other costs, or there is no standard equivalent I tap out and go proprietary. The things you give up just for the ability to later completely switch platforms wholesale just aren’t worth it imho.
– Aaron Bertrand
16 mins ago




Portability is a nice textbook goal, but it rarely happens in practice. When you have a choice between standard syntax (<>) and non-standard (!=), where there is no compromise on performance or maintainability, I always choose standard. But when it comes at other costs, or there is no standard equivalent I tap out and go proprietary. The things you give up just for the ability to later completely switch platforms wholesale just aren’t worth it imho.
– Aaron Bertrand
16 mins ago




1




1




The only time portability is a realistic goal is when you’re writing an app that needs to integrate with multiple platforms simultaneously because your customers use different platforms. Even then, unless you want functionality to be limited and performance to be terrible on all platforms, I would ship packages meant to take advantage of features of individual platforms.
– Aaron Bertrand
13 mins ago




The only time portability is a realistic goal is when you’re writing an app that needs to integrate with multiple platforms simultaneously because your customers use different platforms. Even then, unless you want functionality to be limited and performance to be terrible on all platforms, I would ship packages meant to take advantage of features of individual platforms.
– Aaron Bertrand
13 mins ago










2 Answers
2






active

oldest

votes


















4














Not really.



There is SET FIPS_FLAGGER 'FULL'.



This prints out a warning for non standard SQL - but some caveats are




  • I am unsure what specific standard this uses (and suspect it may be SQL 92)

  • From a quick test this doesn't complain about use of the + operator for string concatenation or proprietary functions such as GETDATE() so it doesn't seem very comprehensive.






share|improve this answer































    2














    Do not enforce STD SQL.



    Decide first which DBMS you will use according to the needs of your project, and take advantage of it.






    share|improve this answer























      Your Answer








      StackExchange.ready(function() {
      var channelOptions = {
      tags: "".split(" "),
      id: "182"
      };
      initTagRenderer("".split(" "), "".split(" "), channelOptions);

      StackExchange.using("externalEditor", function() {
      // Have to fire editor after snippets, if snippets enabled
      if (StackExchange.settings.snippets.snippetsEnabled) {
      StackExchange.using("snippets", function() {
      createEditor();
      });
      }
      else {
      createEditor();
      }
      });

      function createEditor() {
      StackExchange.prepareEditor({
      heartbeatType: 'answer',
      autoActivateHeartbeat: false,
      convertImagesToLinks: false,
      noModals: true,
      showLowRepImageUploadWarning: true,
      reputationToPostImages: null,
      bindNavPrevention: true,
      postfix: "",
      imageUploader: {
      brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
      contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
      allowUrls: true
      },
      onDemand: true,
      discardSelector: ".discard-answer"
      ,immediatelyShowMarkdownHelp:true
      });


      }
      });






      s.demuro is a new contributor. Be nice, and check out our Code of Conduct.










      draft saved

      draft discarded


















      StackExchange.ready(
      function () {
      StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fdba.stackexchange.com%2fquestions%2f225918%2fbest-pratices-to-maximize-portability-in-sql-server-2016%23new-answer', 'question_page');
      }
      );

      Post as a guest















      Required, but never shown

























      2 Answers
      2






      active

      oldest

      votes








      2 Answers
      2






      active

      oldest

      votes









      active

      oldest

      votes






      active

      oldest

      votes









      4














      Not really.



      There is SET FIPS_FLAGGER 'FULL'.



      This prints out a warning for non standard SQL - but some caveats are




      • I am unsure what specific standard this uses (and suspect it may be SQL 92)

      • From a quick test this doesn't complain about use of the + operator for string concatenation or proprietary functions such as GETDATE() so it doesn't seem very comprehensive.






      share|improve this answer




























        4














        Not really.



        There is SET FIPS_FLAGGER 'FULL'.



        This prints out a warning for non standard SQL - but some caveats are




        • I am unsure what specific standard this uses (and suspect it may be SQL 92)

        • From a quick test this doesn't complain about use of the + operator for string concatenation or proprietary functions such as GETDATE() so it doesn't seem very comprehensive.






        share|improve this answer


























          4












          4








          4






          Not really.



          There is SET FIPS_FLAGGER 'FULL'.



          This prints out a warning for non standard SQL - but some caveats are




          • I am unsure what specific standard this uses (and suspect it may be SQL 92)

          • From a quick test this doesn't complain about use of the + operator for string concatenation or proprietary functions such as GETDATE() so it doesn't seem very comprehensive.






          share|improve this answer














          Not really.



          There is SET FIPS_FLAGGER 'FULL'.



          This prints out a warning for non standard SQL - but some caveats are




          • I am unsure what specific standard this uses (and suspect it may be SQL 92)

          • From a quick test this doesn't complain about use of the + operator for string concatenation or proprietary functions such as GETDATE() so it doesn't seem very comprehensive.







          share|improve this answer














          share|improve this answer



          share|improve this answer








          edited 1 hour ago

























          answered 1 hour ago









          Martin Smith

          61.4k10166245




          61.4k10166245

























              2














              Do not enforce STD SQL.



              Decide first which DBMS you will use according to the needs of your project, and take advantage of it.






              share|improve this answer




























                2














                Do not enforce STD SQL.



                Decide first which DBMS you will use according to the needs of your project, and take advantage of it.






                share|improve this answer


























                  2












                  2








                  2






                  Do not enforce STD SQL.



                  Decide first which DBMS you will use according to the needs of your project, and take advantage of it.






                  share|improve this answer














                  Do not enforce STD SQL.



                  Decide first which DBMS you will use according to the needs of your project, and take advantage of it.







                  share|improve this answer














                  share|improve this answer



                  share|improve this answer








                  edited 19 mins ago

























                  answered 55 mins ago









                  McNets

                  14.7k41857




                  14.7k41857






















                      s.demuro is a new contributor. Be nice, and check out our Code of Conduct.










                      draft saved

                      draft discarded


















                      s.demuro is a new contributor. Be nice, and check out our Code of Conduct.













                      s.demuro is a new contributor. Be nice, and check out our Code of Conduct.












                      s.demuro is a new contributor. Be nice, and check out our Code of Conduct.
















                      Thanks for contributing an answer to Database Administrators Stack Exchange!


                      • Please be sure to answer the question. Provide details and share your research!

                      But avoid



                      • Asking for help, clarification, or responding to other answers.

                      • Making statements based on opinion; back them up with references or personal experience.


                      To learn more, see our tips on writing great answers.





                      Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


                      Please pay close attention to the following guidance:


                      • Please be sure to answer the question. Provide details and share your research!

                      But avoid



                      • Asking for help, clarification, or responding to other answers.

                      • Making statements based on opinion; back them up with references or personal experience.


                      To learn more, see our tips on writing great answers.




                      draft saved


                      draft discarded














                      StackExchange.ready(
                      function () {
                      StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fdba.stackexchange.com%2fquestions%2f225918%2fbest-pratices-to-maximize-portability-in-sql-server-2016%23new-answer', 'question_page');
                      }
                      );

                      Post as a guest















                      Required, but never shown





















































                      Required, but never shown














                      Required, but never shown












                      Required, but never shown







                      Required, but never shown

































                      Required, but never shown














                      Required, but never shown












                      Required, but never shown







                      Required, but never shown







                      Popular posts from this blog

                      Morgemoulin

                      Scott Moir

                      Souastre