Short Description
|
Manual Commit with compiler version 1.03.28e
|
Entered
|
By:
am2782
When: 1999-06-24 14:28:03 Build: 1.03.07A
|
Categories
|
Type:
Question
Department: Product
Category:
ODBC Support
|
Description
|
I am unable to get the DBSOURCE Options="ManualCommit" to work with compiler version 1.03.28e. Please Advise.
'Sample Code
|
|
Append
|
By: WindSurfer When: 1999-06-24 19:31:25 New Status:
Pending Customer
|
Comment
|
Sorry your append is all compressed-- in the future, please wrapper any HTML and formatted text with a <PRE> and </PRE>, then use the "FixSampleCode" button.
We are going to make this work better very soon, so that you don't have to do that, but for now that's the way it works...
Please note that if you are implementing units of work, you will need to use a session-level threading model. We are looking at your ticket now-- will append again when we have some advice :)
|
|
Append
|
By: WindSurfer When: 1999-06-24 19:36:35 New Status:
Pending Customer
|
Comment
|
The size of your append is exceeding the SupportCenter's append limit-- can you please send the ODBC trace as a file attachment in an e-mail to surfer@ieinc.com, referencing ticket #340 in the subject.
1.3.28e is fairly backlevel, but I don't think that there are any ODBC changes in the area you are working.
Also noticed that your threading model and everything else is right on, so from here we will anticipate your log file, and work from there.
|
|
Append
|
By: WindSurfer When: 1999-07-20 18:08:59 New Status:
Pending Customer
|
Comment
|
Oracle closes statement handles following a commit--we are updating the Screensurfer ODBC support to detect this at DBConnect time so that a cached statement handle is re-prepared for each execution.
We are also implementing SQLExecDirect support, which allows you to avoid a prepare/execute approach in an Oracle environment, where there is little advantage to prepared commands since statements don't persist past a unit of work.
|
|
Append
|
By: WindSurfer When: 1999-07-23 15:12:33 New Status:
Pending Customer
|
Comment
|
We now have our test environment-- we are testing with Oracle 7.3.2.2.0 and found that statements DO persist, so it isn't the problem of the statement handle being closed...BUT, stored procedures are NOT supposed to be executed with PREPARE-EXECUTE under ODBC; they should be executed with EXECUTE-DIRECT...which might explain why the FIRST execute in your ODBC log is successful, but the second is not.
1.3.28e...don't think this has session-scope in it...
SQLDirect support is in test now-- you should note that with ODBC, you use SQL="{call ROCWEBEVENT.ROCWEBADDROCEVENTCOSMACC_RW701 ... }" by convention...do you know if the syntax you are using generally works with other ODBC products?
If possible, since we have the events table in our database, any chance you can send a copy of the stored procedure you were using with this to surfer@ieinc.com (reference ticket #340)...otherwise we'll hack one together...
|