Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>The identity column will be incremented whenever an insert is attempted, even if it fails, so that part is not necessarily unusual.</p> <p>I'd look for issues with your parameter values and/or types in arrParams. What kind of object is 'data'? (I'm almost afraid to ask, but I'm not getting any hits on msdn for ExecuteIntScalar)</p> <p><strong>EDIT:</strong> </p> <p>I think van is on the right track with respect to the transaction not being committed. It loos like you're using some sort of custom helper class to manage calls to stored procedures in the database (and other DB access, presumably), and it could be that this code is swallowing the error raised by SQL server. I created a little test app and was able to reproduce the behavior you describe. Since we can't tell how your class traps exceptions etc. this may not be your actual problem, but it's one way that a stored procedure call <em>could</em> fail in the way you describe.</p> <pre><code>// call the proj_ins_all SP every time a button is clicked. protected void Button1_Click(object sender, EventArgs e) { using (SqlConnection conn = new SqlConnection(myConnectionString)) using (SqlCommand cmd = new SqlCommand("proj_ins_all", conn)) { try { cmd.CommandType = CommandType.StoredProcedure; cmd.Parameters.Add(new SqlParameter("@proj_number", SqlDbType.Int)); cmd.Parameters["@proj_number"].Value = 9001810; cmd.Parameters.Add(new SqlParameter("@usr_id", SqlDbType.Int)); cmd.Parameters["@usr_id"].Value = 2; cmd.Parameters.Add(new SqlParameter("@download", SqlDbType.SmallDateTime)); cmd.Parameters["@download"].Value = "2009-09-03 16:20:11"; cmd.Parameters.Add(new SqlParameter("@status", SqlDbType.Int)); cmd.Parameters["@status"].Value = 2; conn.Open(); cmd.Transaction = conn.BeginTransaction(); object _id = cmd.ExecuteScalar(); // _id now contains the value of the Identity column for // the row just inserted by proj_ins_all // Assume (or simulate) an error is raised after the SP is called but // before the transaction is committed. // (Comment this line out and the DB update succeeds, as expected.) throw new Exception(); // If the transaction is not committed, it'll be rolled back when // the connection is closed and the inserted row won't be in the // table even though the incremented Identity value was returned above. cmd.Transaction.Commit(); } catch (Exception) { // "swallow" (i.e. just ignore) any errors raised by the DB code. //throw; } } } </code></pre> <p>Transactions don't have to be explicitly declared to occur. For example, if you removed the calls to BeginTransaction() and Transaction.Commit() from the code above, there would still be an implicit transaction that could theoretically be interrupted and caused to roll back. So the root of your issue might be more subtle than this example, which requires an explicit transaction to demonstrate the concept.</p> <p>More practically, you can see (via Profiler) the actual SQL that the app sends to the SQL server and verify that it works when executed from SSMS, so that makes me think the issue is probably with the app code that calls the stored procedure.</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload