I have to run off for a brief walk (doesn't even count as a hike), but let me toss out a puzzle that I have been making no headway on in case somebody can tell me what to look at next. There is no particular code associated with this, as there is too much to post it all, and the location of the problem is very hard for me to say, yet. The problem is this:
I have two paths in a program, one works fine and the other does not. In both cases, some laborious work is performed, then a transaction is started and within that transaction, a certain function is called. Both paths call this function, and I can cause both paths to do the same thing as far as the function is concerned. The function writes data to a couple tables. I have confirmed that in both paths, this data is being written. I confirmed this because ExecuteNonQuery returns 1, which is what it should. Furthermore, if I were to try to make that ExecuteNonQuery call twice, the second time would fail because I would be duplicating the primary key for the new record. So, by both tests, I can confirm that the record is being written.
What baffles me is that immediately after this function is called, both paths do the exact same thing, which is to make a read of some data that was just written. One path has no problem with this, the other path finds nothing in the database. If I continue on and commit the transaction, the first path writes the data correctly, the new records show up in the database, and all is well. If I continue on and commit the transaction in the second path, the transaction commits fine, there are no errors, but nothing is written to the database, and by every measure, the records that were apparent when I tested the ExecuteNonQuery have simply vanished.
I can only assume that this has something to do with the transaction, and I'm kind of stretching the transaction out pretty thoroughly, but I'm not sure where to look for this one. The transaction is started in a dll, and is added to an object that is passed between multiple dlls, with each one having the opportunity to perform some work as part of the transaction, but in reality, none of the other dlls actually pay any attention to it, and the actual steps performed in the two paths are so identical that nothing really appears obvious to me. After all, the function that does all the writing is the same function in both paths, and I have confirmed that it is writing. The steps after the writing are not in the same function, but for the next few steps, one is a copy of the code from the other, and within those few steps I can show that in one case the database knows about the new records (not yet committed), while in the other case the database has no knowledge of the new records (also not yet committed, but then again they never do get written). Since the two paths are actually the same code from the time the writing happens until the time that I can confirm that the behavior differs, I can only assume that there is something different about the transaction used each time, but I have no idea what. The same code opens the transaction for both paths (it is opened in a function that is called by each path to start the transaction).
I realize that despite all the writing, there isn't much to go on, but if there was something to go on, I'd have this solved already. I'm looking for any suggestion as to why writes within one transaction, that appear to work, do not, when the function does perform the write when called by a different method. Is there something about transactions that could cause this?
I have two paths in a program, one works fine and the other does not. In both cases, some laborious work is performed, then a transaction is started and within that transaction, a certain function is called. Both paths call this function, and I can cause both paths to do the same thing as far as the function is concerned. The function writes data to a couple tables. I have confirmed that in both paths, this data is being written. I confirmed this because ExecuteNonQuery returns 1, which is what it should. Furthermore, if I were to try to make that ExecuteNonQuery call twice, the second time would fail because I would be duplicating the primary key for the new record. So, by both tests, I can confirm that the record is being written.
What baffles me is that immediately after this function is called, both paths do the exact same thing, which is to make a read of some data that was just written. One path has no problem with this, the other path finds nothing in the database. If I continue on and commit the transaction, the first path writes the data correctly, the new records show up in the database, and all is well. If I continue on and commit the transaction in the second path, the transaction commits fine, there are no errors, but nothing is written to the database, and by every measure, the records that were apparent when I tested the ExecuteNonQuery have simply vanished.
I can only assume that this has something to do with the transaction, and I'm kind of stretching the transaction out pretty thoroughly, but I'm not sure where to look for this one. The transaction is started in a dll, and is added to an object that is passed between multiple dlls, with each one having the opportunity to perform some work as part of the transaction, but in reality, none of the other dlls actually pay any attention to it, and the actual steps performed in the two paths are so identical that nothing really appears obvious to me. After all, the function that does all the writing is the same function in both paths, and I have confirmed that it is writing. The steps after the writing are not in the same function, but for the next few steps, one is a copy of the code from the other, and within those few steps I can show that in one case the database knows about the new records (not yet committed), while in the other case the database has no knowledge of the new records (also not yet committed, but then again they never do get written). Since the two paths are actually the same code from the time the writing happens until the time that I can confirm that the behavior differs, I can only assume that there is something different about the transaction used each time, but I have no idea what. The same code opens the transaction for both paths (it is opened in a function that is called by each path to start the transaction).
I realize that despite all the writing, there isn't much to go on, but if there was something to go on, I'd have this solved already. I'm looking for any suggestion as to why writes within one transaction, that appear to work, do not, when the function does perform the write when called by a different method. Is there something about transactions that could cause this?
