cancel
Showing results for 
Search instead for 
Did you mean: 

Can/Should we check for error on connection object after the followng calls

Former Member
0 Kudos

Normally after a call to the 'SQLDBC_Connection_connect' function we check for the possible errors by calling the

SQLDBC_ErrorHndl *errHndl = SQLDBC_Connection_getError(conn);

SQLDBC_ErrorHndl_getErrorText(errHndl); or SQLDBC_ErrorHndl_getErrorText(errHndl);

Should we be doing the same after the following calls too ? They all take 'SQLDBC_Connection*' as a parameter just like 'SQLDBC_Connection_connect' . In other words the question is is the SQLDBC_Connection object set with the error information (if any) in case any of the following call fails?

SQLDBC_Connection_createStatement

SQLDBC_Connection_close

SQLDBC_Connection_setAutoCommit

SQLDBC_Connection_commit

SQLDBC_Connection_releaseStatement

SQLDBC_Connection_close

Please advise.

Regards

Raj

Accepted Solutions (1)

Accepted Solutions (1)

TTK
Employee
Employee
0 Kudos

Hello Raj

Usually checking the error is sensible, if the method in question returns a value of type SQLDBC_Retcode.

However, createStatement sets a memory allocation error, if no statement could be generated due to memory restrictions and therefore a NULL would be returned.

Regards Thomas

Former Member
0 Kudos

Hi Thomas,

So, the conclusion is SQLDBC_Connection object is set with error information (if any) in case, any of the following call fails.

SQLDBC_Retcode SQLDBC_Connection_close

SQLDBC_Retcode SQLDBC_Connection_commit

SQLDBC_Retcode SQLDBC_Connection_rollback

And it is better to check for the errors.

Regards

Raja

TTK
Employee
Employee
0 Kudos

And it is better to check for the errors.

Definitely yes!

Of course, error handling is only necessary, if an error occured. E.g. if commit returns with SQLDBC_OK, there is no need to examine the error object.

Regards Thomas

Answers (0)