On Wed, Jun 1, 2011 at 6:24 PM, Patrick Earl <pate...@patearl.net> wrote:
> From these, the "best" solution seems to be re-tokenizing the sql in > the provider. Is there another work-around? It seems that > implementing this at the database level would be the most efficient > approach. Obviously re-tokenizing all the SQL would be expensive. Actually... if you just want to tokenize the SQL for the parameters, as opposed to checking the validity of the SQL itself, it is not all that difficult to do. i recently did just that to add named parameter support to the MySQL back-end of a db access abstraction API. MySQLv5 doesn't support named parameters natively, so i wrote a relatively simple tokenizer which can fish them out and another routine which converts named parameters to question marks so that we can feed the data to mysql (but can also remember enough info to map the named param positions to qmark positions): http://fossil.wanderinghorse.net/repos/cpdo/index.cgi/artifact/b5ba5aa115c73b63179456d1fed7846a11878c05 Search that file for: cpdo_find_next_named_param cpdo_named_params_to_qmarks The code for those functions is public domain and should be generic enough to extract for your own use (almost without modification - i think only the return code symbols would need to be replaced). The docs are in the header file: http://fossil.wanderinghorse.net/repos/cpdo/index.cgi/artifact/6749b977687afa081f6b5b3e7fc3b19cd62bb70a That code has worked for me very well so far, and i haven't yet had any mis-parsing except on code which was itself not legal SQL (i.e. it doesn't seem to create any new problems where there isn't already a problem). -- ----- stephan beal http://wanderinghorse.net/home/stephan/ _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
