On 26 Nov 2011, at 2:54pm, Jean-Christophe Deschamps wrote: >> And it's convenient to be able to do the prepare during startup. I've just >> never had to worry about this situation. It means you have to do special >> handling for the first _step, but it's a reasonably compact way of handling >> the potential problem. > > I can't use prepared statements in practice with the (interpreted) scripting > language I use most (AutoIt) due to its DLL invokation being so slow: having > to first prepare then perform multiple _Bind calls and having to sort out > variable type for each _Bind proves way slower than an all-in-one "dumb" > _Exec. That's possibly true for more scripting languages.
I'm in the same boat. I effectively run a SQLite master/slave environment and the commands have to be sent to the server somehow. Even if I were to pass the command and parameters separately, all I'd be doing is putting them together on the other end. And passing stuff in an array and doing the assembly work would end up making my system even slower. So I make up for it by using an 'exec' which executes only the first command, and by hashing the command so that tampering with it would make it fail the hash. But there's no reason you'd have to use exec just because you're passing a string. You can still use _prepare, _step, _finalize if you find it convenient, you just use it on a string which has the completed command in. > That's why _Exec should definitely be kept part of the SQLite API. I hadn't known its removal was even being considered. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
