The SQL capture settings control whether SQL statements are captured and presented in the Controller UI with dynamic parameters bound to their runtime values. For example, consider Java code that constructs a SQL call as follows:

stmt = new PreparedStatement("select * from user where ssn = ?")
stmt.bind(1, "123-123-1234")
stmt.execute()

With the capture raw SQL option enabled, Splunk AppDynamics captures and presents the SQL call in the following form:

select * from user where ssn = '123-123-1234'

If capture raw SQL is disabled, the SQL call appears in its original form, with question mark parameters not bound to values. Disabling capture-raw-sql and using question mark parameters in SQL prepared statements gives you a mechanism for preventing sensitive data from appearing in the Controller UI.

It is important to note that the sensitive values must be parameterized in the original, prepared statement form of the SQL statement, as shown above. The following statement results in the potentially sensitive information (social security number) appearing in the Controller UI whether capture raw SQL is enabled or disabled since the sensitive data is not parameterized.

stmt = new PreparedStatement("select * from user where ssn ='123-123-1234'")

To configure SQL capture settings, in the Call Graph Settings tab, scroll down to the SQL Capture Settings section and choose one of the following options:

• Capture Raw SQL: Select this option to have SQL statements that are composed as prepared statements captured with dynamic parameters bound to runtime values. By default, private SQL data and queries that take less than 10 ms are not captured.

  Note: Important

  You can select this option to capture raw query details for NoSQL databases such as MongoDB, DynamoDB, and CassandraDB and the relational queries will not be scrubbed.

  Note: When you enable Capture Raw SQL in .NET environments, the agent captures the parameters for ADO.NET stored procedure calls even though the parameters are not represented by question marks. It does not capture stored procedure local variables that are not available to the CLR.
• Filter Parameter values: Select this option to have SQL statements that are composed as prepared statements captured without dynamic parameters bound to runtime values.