Handled sp_prepexec call for Column encryption enabled

[divang]

Description:

• The incident involved unexpected behavior when inserting strings using Always Encrypted with Secure Enclaves in Azure SQL DB.

• Unexpected insert results when using Always Encrypted.

• Subsequent inserts into encrypted columns fail after initial successful inserts.

• Issue in details at code level:
  The buildPreparedStrings method compares the last prepared statement with the current one to be executed. If both statements are identical, it signals that calling sp_prepexec is unnecessary. Otherwise, sp_prepexec will be invoked later in the driver's execution flow. However, multiple calls to buildPreparedStrings overwrite the preparedTypeDefinitions variable, which stores the current prepared statement. As a result, repeated invocations can lead to the loss of the original statement, affecting the logic that determines whether sp_prepexec should be called with updated data types and lengths.

• Resolution details:
  Within the buildPreparedStrings method, the preparedTypeDefinitions variable is cached in preparedTypeDefinitionsPrev to prevent it from being overwritten. If isAEv2() is enabled, renewDefinition is false, and isInternalEncryptionQuery is true, then the driver caches the preparedTypeDefinitions value into preparedTypeDefinitionsPrev. In subsequent calls to buildPreparedStrings, if isAEv2() is still enabled, renewDefinition is true, and isInternalEncryptionQuery is false, the driver restores preparedTypeDefinitions from the cached preparedTypeDefinitionsPrev. This caching mechanism prevents the loss of the original statement and ensures the correct signal is returned regarding whether to invoke sp_prepexec.

Testing

• Configure the SQL database with encryption enabled and create a table with column-level encryption. Below manual test method works well.

Class.forName("com.microsoft.sqlserver.jdbc.SQLServerDriver");
try (Connection conn = DriverManager.getConnection(url)) {
    try (PreparedStatement pstmt = conn.prepareStatement("insert into t1 values(?)")) {
        String data2 ="a"; 
        pstmt.setString(1, data2);
        pstmt.executeUpdate();
        String data3 =  data2 + "aa";
        pstmt.setString(1, data3);
        pstmt.executeUpdate();
        String data4 =  data3 + "aaa";
        pstmt.setString(1, data4);
        pstmt.executeUpdate();
    } catch (SQLException e) {
        e.printStackTrace();  
    }
} 

• Mocked the above use case via Mockito framework in the test case testBuildPreparedStringsForVaryLength()

[codecov]

Codecov Report

Attention: Patch coverage is 60.00000% with 4 lines in your changes missing coverage. Please review.

Project coverage is 51.70%. Comparing base (f0706ea) to head (deb3911).
Report is 1 commits behind head on main.

Files with missing lines	Patch %	Lines
...oft/sqlserver/jdbc/SQLServerPreparedStatement.java	60.00%	2 Missing and 2 partials ⚠️

Additional details and impacted files

@@             Coverage Diff              @@
##               main    #2663      +/-   ##
============================================
+ Coverage     51.62%   51.70%   +0.08%     
- Complexity     4008     4030      +22     
============================================
  Files           147      147              
  Lines         33800    33804       +4     
  Branches       5650     5652       +2     
============================================
+ Hits          17448    17479      +31     
+ Misses        13888    13881       -7     
+ Partials       2464     2444      -20     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[divang]

ADO pipeline is successful.

[David-Engel]

No general objections to these changes. But we should add tests to cover the scenario this is fixing.

[divang]

ADO pipeline is successful.

[divang]

Successful run ADO pipeline