DOA 4.0.6 & TOracleCommand.Execute

timboc

Member²
I think this is something I asked about back in the 3.x days. I'm checking the return value from this function to see if an error has occurred. I'd expect that TRUE represent no error and FALSE represent an error.

I think the only error that is returned would be that the SQL command couldn't be executed (not that there was a problem executing it).

When I posted it back then I was told that this would be fixed in future releases but after upgrading today it seems to behave the same (old) way.

Can someone at Allround please confirm that this is unchanged from 3.x and will not change in 4.x?

Thanks,
Tim
 
In 4.0 the return value of TOracleScript.Execute indicates if execution was successful (True) or not (False).
 
Marco, thanks for the quick reply. Unfortunately my code is not behaving the way you are describing. .Execute is always returning FALSE:

bSQLExecute := OracleScript1.Commands[liCSCurrent-1].Execute;
LogEvent(OracleScript1.Commands[liCSCurrent-1].Text,false);
if bSQLExecute then
LogEvent('Execute returned TRUE',false)
else
LogEvent('Execute returned FALSE',false);

bSQLExecute returns FALSE for any Oracle statements I throw at it:
"select user from dual;" returns FALSE
"sellllllect user from dual;" returns FALSE

------- sample output --------
20040917.104756 : select user from dual
20040917.104756 : Execute returned FALSE

Do you have any other ideas or insights?

-Tim
 
Originally posted by timboc:

Do you have any other ideas or insights?

-Tim
Idea is very simple - I don't know intentionally or not, but result of TOracleCommnad.Execute method is meaningful for Non-SQL commands only. For SQL commands it is always false.

I have checked with source code.
 
Sorry, at the TOracleCommand level the result should indicate if the command was handled. It will be False for unrecognized commands. If it returns False for SQL commands, this is a bug.

If you want to know if a SQL command succeeded, check TOracleCommand.ErrorCode.
 
I'm seeing it return False for all SQL commands, that's why I grab the return and invert it before testing it. I think this is a bug (that's what I was told when I reported it for version 3.x) but the priority must be really low.

When/if it does get fixed I'll just have to remove the line in my code where I'm reversing the variables value.

-Tim
 
Back
Top