On Tue, Jun 03, 2008 at 02:27:01PM -0600, Dennis Cote scratched on the wall: > Jay A. Kreibich wrote: > > > > That, or something like sqlite3_clear_bindings() that actually > > *clears* the bindings (e.g. whatever state they are in just after a > > prepare), and not just sets them to an explicit NULL, as the current > > function does. > > > > That wouldn't help. The default value is *only* used when no value is > provided by the insert statement. If the insert statement has a > parameter that can be bound, it is supplying a non-default value, and > that value will be used instead of the default value. You really do need > different statements, with and without a value for the column that is to > get the default value.
*ding* [Light bulb does on] Ahhh... yes, that makes tons of sense on a number of different levels. For some reason I was under the impression that statements that were prepared but didn't bind anything had their default parameters used. I now understand that this assumption is incorrect, and from that the rest makes sense. Jeff's suggestion is interesting, but kind of assumes there is a clear one-to-one corrispondence between bind params and specific columns. I can see a lot of cases when this might not be true, even for INSERT or UPDATE statements. For those trying to deal with this problem, it is worth pointing out that you can extract the default value for any column of any table with the "PRAGMA table_info(<table>)" command. You can then incorporate that into your application logic and explicitly bind the default value should you find yourself valueless. -j -- Jay A. Kreibich < J A Y @ K R E I B I.C H > "'People who live in bamboo houses should not throw pandas.' Jesus said that." - "The Ninja", www.AskANinja.com, "Special Delivery 10: Pop!Tech 2006" _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
