[EMAIL PROTECTED] wrote: > QUESTION 1: sqlite3_prepare_v2 is the merely the working name > for the new function. What should the official name be? > Some possibilities include: > > sqlite3_prepare_ex1 > sqlite3_prepare_ng > sqlite3_new_prepare > sqlite3_compile > sqlite3_compile > QUESTION 2: Are there any other API warts that need to be > worked around that can be fixed by this same change? > The fact that prepare depends upon a database connection handle. IE, it'd be nice to be able to compile once, and re-use for situations where you know you're using the same database, but don't want to incur the preparation cost for every time you want to go off and execute the statement. (Not talking, compile time, but rather, prepare once per runtime, and you're done). It'd make life hella easier for people doing multi-threaded work, to compartmentalise/fine grain as much as possible, and to create connections/queries resources only as they're needed, then tear them back down once they've finished. > QUESTION 3: Suppose there is a schema change and the SQL > statement is automatically reprepared. But the schema change > is such that the SQL is no longer valid. (Perhaps one of the > tables mentioned in a SELECT statement was dropped.) What > error code should sqlite3_step() return in that case? > I trust your judgement on this ;) > -- > D. Richard Hipp <[EMAIL PROTECTED]> > > > ----------------------------------------------------------------------------- > To unsubscribe, send email to [EMAIL PROTECTED] > ----------------------------------------------------------------------------- > > >
-- Bill King, Software Engineer Trolltech, Brisbane Technology Park 26 Brandl St, Eight Mile Plains, QLD, Australia, 4113 Tel + 61 7 3219 9906 (x137) Fax + 61 7 3219 9938 mobile: 0423 532 733 ----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------
