New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SQLServerBulkCSVFileRecord doesn't revert IDENTITY_INSERT to OFF after a failure #2380
Comments
Hi @ingvard, I'm not sure this is a mistake within the driver. It's in the nature of IDENTITY_INSERT to persist for that connection, regardless of whether the connection is being re-used or not. If we're 'resetting' the value of IDENTITY_INSERT after failure, we're changing the state of the connection as its being returned to the pool, and that's not something the driver should do. Reading up on best practices for IDENTITY_INSERT, the recommendation is to be sure to set IDENTITY_INSERT to OFF for a table, if there is a plan to set it to ON for another. This can easily be added to your catch clause for the case above. Let us know if you have more to add regarding this topic. If not, we will move forward with closing the issue. |
@Jeffery-Wasty, thank you for your response. Your argument seems logical, but it's worth noting that
However, it's important to acknowledge that checking whether the current connection has IDENTITY_INSERT set to ON for a specific table isn't a trivial task, as per information from StackOverflow. It looks like the leaked abstraction, as the user of the What do you think about it? |
Hi @ingvard, I agree that the inconsistency you have mentioned is not something we desire, and you make a good point about the the burden of resetting IDENTITY_INSERT for the user. I'll spend more time looking into this/check in with the team, and see what more we can do from our end. |
Hi @ingvard, So I spent additional time looking into this. After trying this other drivers and with just SQL through SSMS, I was able to replicate the same behavior as seen in JDBC. That is JDBC was consistent with other sources. Furthermore, the driver does no modification to IDENTITY_INSERT, regardless of success or failure. We just pass along the value and use it to determine whether additional actions are taken against the identity column. I did try to add in behavior to set IDENTITY_INSERT for the most recent used table to OFF, in case of a failure, but was not able to find a solution. Addressing your concerns from you last comment:
As noted above. This 'inconsistent' behavior is consistent with other sources, and we can not determine how to change this in the desired way.
No, but it would be trivial to remember to set IDENTITY_INSERT to OFF after setting it to ON. In fact, I would urge that this behavior be extended to all scenarios. If you set to ON at the start of a program or query, set to OFF after transactions with that table have completed. Given the above, I'm inclined to chalk this up as 'intended driver behavior' and mark the issue closed. Please let me know if you have any additional questions, concerns, or information. |
Closing for above reasons. |
SQLServerBulkCopy doesn't revert IDENTITY_INSERT to OFF after a failure
Driver version
mssql-jdbc-12.6.1.jre11
SQL Server version
Microsoft SQL Server 2017 (RTM-CU31-GDR) (KB5021126) - 14.0.3460.9 (X64) Developer Edition (64-bit) on Linux (Ubuntu 18.04.6 LTS)
Client Operating System
Linux (Ubuntu 18.04.6 LTS)
JAVA/JVM version
Kotlin 1.9.22 (Open JDK 17)
Table schema
Problem description
After using SQLServerBulkCopy and it finishes with an exception, a connection will have IDENTITY_INSERT ON. The example below shows and repeats the problem step by step:
I have examined various situations where the insertion process breaks. From what I observe, it seems necessary to insert data that the server will accept, and then throw an exception during the response parsing stage.
The code above leads to the following exception:
because
SQLServerBulkCSVFileRecord
doesn't revertIDENTITY_INSERT ON
after the failure.Expected behavior
The expected behavior is that the connection returns to its original state as it was before starting. For instance, in a successful case, it reverts back to its initial state.
Actual behavior
The actual behavior is that the connection state for each
conn.createStatement()
or anotherSQLServerBulkCSVFileRecord
will remain asIDENTITY_INSERT dbo.TEST_IDENTITY_TABLE ON
.The text was updated successfully, but these errors were encountered: