On Thu, 15 May 2003 06:31:05 GMT, "Dilan" <dilan_a_at_example.net> wrote:
>We have been experiencing some delays in a transaction intensive OLTP
>program written in COBOL running under Win2K. After narrowing it down to an
>embedded sql statement EXEC SQL COMMIT WORK END-EXEC., to get more clarity I
>re-wrote the program in C. I was able to reproduce the delay in a block of
>code that the Pro*C pre-compiler generated for the embedded SQL directive
>"EXEC SQL COMMIT WORK." The line reads
>
>"sqlcxt((void **)0, &sqlctx, &sqlstm, &sqlfpn);".
>
>Looks harmless, but has anyone seen anything like this before. Are there any
>name resolution operations, potential timeouts around this function call.
>The longest delay I have seen is about 62 seconds.
>
>TIA
>Dilan
>
>
>
I can't address your question directly, but as an old unrepentant
COBOL programmer, I can't imagine why rewriting the app in another
language would have any impact of the performance of any specific SQL
statement. No matter what language you write it in, what the database
sees is 'COMMIT WORK'. If COMMIT WORK itself is taking a long time,
there is something else going on. I'd suspect the delay is elsewhere
and the COMMIT WORK is a red herring.
Received on Thu May 15 2003 - 10:48:06 CDT
