DG wrote:
>>> There are truly only three possibilities.
>>>
>>> 1. There is no commit and you don't realize it.
>>>
>>> 2. The commit is failing and your understanding of the Oracle
>>> transaction model is so weak you don't understand how to interpret
>>> what you are seeing or your code doesn't trap for the failure.
>>>
>>> 3. The commit is succeeding and you have a problem with caching
>>> on the application server or in your application.
>>
>>
>>
>> 4. The TOAD is looking from another session that started a transaction
>> before the app server started it's update transaction, after looking
>> from a session that started after the update transaction committed.
>>
>> But I think 2 is pretty likely.
>>
> Well, it's none of the above. I've solved the problem. There is some
> obscure bug (or different behaviour at least) on the part of the Oracle
> ODBC driver.
>
> I've used the following ODBC lib function for committing transactions:
>
> ---
> SQLRETURN SQLEndTran(
> SQLSMALLINT HandleType,
> SQLHANDLE Handle,
> SQLSMALLINT CompletionType);
>
> HandleType is SQL_HANDLE_DBC
> CompletionType is SQL_COMMIT
> ---
>
> Then, I've changed the Smalltalk commit method implementation to use:
>
> ---
> SQLRETURN SQLExecDirect(
> SQLHSTMT StatementHandle,
> SQLCHAR * StatementText,
> SQLINTEGER TextLength);
>
> and execute SQL statement "COMMIT".
> ---
>
> And, with this change it works as one would expect.
>
> So, regarding the possibilities above:
>
> 1. It can't be. The change was visible in TOAD (another connection) for
> some time. So it must have been committed and then reverted by the ODBC
> driver code.
>
> 2. I can not comment on this. I have 10 years experience in the RDB and
> OODB technology, even implemented an OODB using MVCC (like the Oracle is
> using). I guess that should give me enough understanding of the existing
> transactional models.
>
> 3. No chance. The app works without problems with all other databases.
> But there could be a caching problem in the ODBC driver.
>
> 4. No, this is not the case here.
>
> If someone else ever encounters similar problem with ODBC here is the
> solution. Don't use SQLEndTran, execute a direct COMMIT instead.
>
> Best regards,
>
> David
You are incorrect. ODBC drivers are irrelevant to whether the database
does or does not commit a transaction. If it does then it has done so.
If it doesn't then it hasn't. Your changing the driver may have caused
something that didn't commit to commit. But it did not change the
behavior of a committed transactions.
--
Daniel A. Morgan
http://www.psoug.org
damorgan_at_x.washington.edu
(replace x with u to respond)
Received on Mon May 30 2005 - 15:44:03 CDT
