2 deleted 2 characters in body
source | link

The parameter list in @params can have names matching the names of the parameters used by the sp_execute_external_script procedure itself, like @script or @language, for instance. There would need to be a way, then, to determine whether thea parameter pertains to the system SP or to the user script.

Making it a rule that @params be always specified last in the list of the parameters pertaining to sp_execute_external_script and all the parameters specified after @params be considered pertaining to the user script is one easy way to implement the distinction. So, if a parameter like @language is specified after @params, it will be interpreted as a script parameter and not the SP's parameter.

And I believe that is what is happening in the cases where you are specifying @output_data_1_name or @language after @params. Those parameters simply must go before @params to avoid potential ambiguity.

Granted, there is not a word about this in the manual, which, however, is a problem with the manual more than a problem with sp_execute_external_script.

The parameter list in @params can have names matching the names of the parameters used by the sp_execute_external_script procedure itself, like @script or @language, for instance. There would need to be a way, then, to determine whether the parameter pertains to the system SP or to the user script.

Making it a rule that @params be always specified last in the list of the parameters pertaining to sp_execute_external_script and all the parameters specified after @params be considered pertaining to the user script is one easy way to implement the distinction. So, if a parameter like @language is specified after @params, it will be interpreted as a script parameter and not the SP's parameter.

And I believe that is what is happening in the cases where you are specifying @output_data_1_name or @language after @params. Those parameters simply must go before @params to avoid potential ambiguity.

Granted, there is not a word about this in the manual, which, however, is a problem with the manual more than a problem with sp_execute_external_script.

The parameter list in @params can have names matching the names of the parameters used by the sp_execute_external_script procedure itself, like @script or @language, for instance. There would need to be a way, then, to determine whether a parameter pertains to the system SP or to the user script.

Making it a rule that @params be always specified last in the list of the parameters pertaining to sp_execute_external_script and all the parameters specified after @params be considered pertaining to the user script is one easy way to implement the distinction. So, if a parameter like @language is specified after @params, it will be interpreted as a script parameter and not the SP's parameter.

And I believe that is what is happening in the cases where you are specifying @output_data_1_name or @language after @params. Those parameters simply must go before @params to avoid potential ambiguity.

Granted, there is not a word about this in the manual, which, however, is a problem with the manual more than a problem with sp_execute_external_script.

1
source | link

The parameter list in @params can have names matching the names of the parameters used by the sp_execute_external_script procedure itself, like @script or @language, for instance. There would need to be a way, then, to determine whether the parameter pertains to the system SP or to the user script.

Making it a rule that @params be always specified last in the list of the parameters pertaining to sp_execute_external_script and all the parameters specified after @params be considered pertaining to the user script is one easy way to implement the distinction. So, if a parameter like @language is specified after @params, it will be interpreted as a script parameter and not the SP's parameter.

And I believe that is what is happening in the cases where you are specifying @output_data_1_name or @language after @params. Those parameters simply must go before @params to avoid potential ambiguity.

Granted, there is not a word about this in the manual, which, however, is a problem with the manual more than a problem with sp_execute_external_script.