*** 167,177 **** --- 167,203 ---- A nice feature would be a function that tests wether a sting is a valid sql-query. The complete function only looks wether there is a ";" at the end. + To tell if a string is valid SQL you need to parse it and verify all the referenced tables and columns exist etc. This is exactly what sqlite3_prepare does. You can write your own function to do this as shown below. It prepares the statement, finalizes the generated statement if any, and checks that the entire SQL string was parsed. If it is valid SQL it return SQLITE_OK, otherwise you will get an sqlite error code. + + int sql_valid(sqlite3 *db, const char *sql) + { + int len; + sqlite3_stmt *s; + const char *t; + int err; + + if (!db || !sql) + return SQLITE_ERROR; + + len = strlen(sql); + + err = sqlite3_prepare(db, sql, len, &s, &t); + if (s) + sqlite3_finalize(s); + if (err) + return err; + if (t != sql + len) + return SQLITE_ERROR + return SQLITE_OK; + } + ==== 2006-05-20 Binary date handling instead of text based. For example using 32-bit size of date is 4 bytes instead of 10 (2006-02-02) the result is 6 bytes saved + + You can currently store your dates as unix timestamps (i.e integer count of seconds since Jan 1, 1970). The time and date functions at http://www.sqlite.org/cvstrac/wiki?p=DateAndTimeFunctions show how convert these values to time and/or date strings for display as well as other formats such as Julian day numbers. ==== 2006-06-29