Summary:	ASTERISK-04926: [patch] RES_ODBC Sanity Check [back from the grave]
Reporter:	Anthony Minessale (anthm)	Labels:
Date Opened:	2005-08-29 12:24:52	Date Closed:	2011-06-07 14:10:06
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) res_odbc_sanity_rev0.diff.txt
Description:	This patch was lost under the rug cos it was tacked onto an old bug that was closed. This implements the config option sanitycheck => X in res_odbc.conf set it to 1 to check when an error is encountered set it to 2 to check everytime an odbc object is fetched 1 is the default behaviour The issue here is if you wait for a fail you have a chicken/egg kanundrum because the reconnect invalidates your prepared statment so you would need to go back in time and rexecute a bunch of code which would require a setjump longjmp nightmare or something.  So when you absoultely need to make sure you have the best chance of getting a SQL stmt to execute on a connected server you would set sanitycheck => 2 if you can live with losing some here and there then leave it alone and use default. ****** ADDITIONAL INFORMATION ****** ODBC related stuff has no category so I picked core/general Disclaimer On File anthmct@yahoo.com
Comments:	By: Kevin P. Fleming (kpfleming) 2005-08-31 17:36:47 This is quite confusing; sanitycheck would appear to have only two valid values, but they do not match the syntax used for every other option in Asterisk (where values start with zero). In fact, if the user does set 'sanitycheck=0' thinking that it will turn this off, it won't. Since you don't allow obj->sanitycheck to be zero (new_odbc_obj sets it to 1 if it comes in as zero), there is not really any need to test obj->sanitycheck for being non-zero; it only matters if it is 1 or higher than 1, right? On top of that, you reset the 'connect' and 'sanitycheck' variables every time you go through the ast_variable_browse() loop, so I don't see how their values could actually have any effect unless they are the last variables processed from the config. Can we just make this use 'sanitycheck=0' is the existing behavior, and 'sanitycheck=1' is the new behavior, leaving values higher than one for higher levels of checking in a future patch? By: Michael Jerris (mikej) 2005-09-25 16:08:42 suspended due to no response.  Please re-open with response.  Thanks.