Skip to Content

CODE: rs__helpconfig : RSSD procedure for displaying configuration settings

Beefed up version of the old rs_configure stored proc – adds the display of RSI, DSI and table-level configuration settings.  Improves on the current ‘admin config’ command by providing the ability to display all configuration settings together in one list (eg, What are all of the dsi_command_convert settings in use in this repserver?).


Displays configuration parameters for the repserver, RSI/routes (from this repserver) as well as DSI/connections (plus tables) managed by this repserver.  Input parameters allow for wildcard searching on the identifier and configuration names.  User also has the option of sorting the output by identifier/configuration or configuration/identifier.


rs__helpconfig  @identifier,   — string matched against all identifiers;

                               — will be wrapped in pair of %’s;

                               — optional

                               — default = ‘%’


                @configname,   — string matched against all config names;

                               — will be wrapped in pair of %’s;

                               — optional

                               — default = ‘%’


                @orderby       — legal values: ( ‘identifier’ | ‘configname’ }

                               —   ‘identifier’ ==> order by (Identifier, Config_Name)

                               —   ‘configname’ ==> order by (Config_Name, Identifier)

                               — optional

                               — default = ‘identifier’




1 – display all config settings; use default ‘identifier’ ordering (Identifier,Config_Name):




2 – display all config settings for the testdb database (‘test‘ will be converted to ‘%test%‘ for search purposes); use default ‘identifier’ ordering (Identifier,Config_Name):


     rs__helpconfig ‘test’


3 – Hmmmm, isn’t there a configuration setting for triggers? Wonder if it’s set anywhere in this repserver? (‘trigger‘ will be converted to ‘%trigger%‘ for search purposes; will match on all dsi_keep_triggers settings); use the ‘identifier’ ordering (Identifier,Config_Name):


     rs__helpconfig null, ‘trigger’, ‘identifier’


4 – I’d like to see the output ordered by the configuration name; use the ‘configname’ ordering (Config_Name,Identifier):


     rs__helpconfig null, null, ‘configname’


You must be Logged on to comment or reply to a post.
  • Hi Mark

    Wonder if you have ever tested this proc or have created a different proc for an ERSSD?

    ERSSD are being used more and more these days and I was just wondering if you had such a script.

    This script is very helpfull.



    • I tend to write/maintain code based on what I can use at my clients.

      To date I’ve yet to come across any clients using the SQLAnywhere/ERSSD, which is primarily due to clients already having ASE (and usually other RDBMSs) in house and not wanting to take on the overhead of having to train their DBAs in yet another RDBMS.

      Converting the proc from ASE to ASA/SQLAnywhere shouldn’t be too hard; the hardest part would likely be the replacement of the call to sp_autoformat … certainly doable, but at that point I’d probably opt for porting sp_autoformat to ASA/SQLAnywhere, which in turn would likely lead to some other detours/porting …

      • Mark,

        Excellent points about the ERSSD.

        However, I think we will see a growoing tendency to use the ERSSD because of its self tuning properties, which are rather nice and because the RS install handles the initial setup.

        Yes, there is a bit of a learning curve even for those of us who have used it in the distant past, but the incentive should be good as, like I say, “SAP SQL Anywhere is Anywhere”, including mobile devices like cel phones.

        That opens a great new avenue for us doesn’t it.