On 23 May 2009, at 3:32pm, Filip Navara wrote: > PRAGMA schema_version ... for the second case.
Okay. Given that this does exactly what I want from one of my requests, and given Jim Wilcoxson's point that adding a PRAGMA is better than adding a function to the library, I can simplify my feature request to asking for something like PRAGMA content_version OR PRAGMA data_version which returns the number stored in bytes 24 to 27 of the header. This should have only a small impact on library size, and require very little extra code since the number needs to be worked out anyway for storage in the header. It should be useful for purposes associated with synchronisation and journaling but it's mostly so that applications which store some data outside SQL and some inside can tell if they need to worry about something messing with their data. It doesn't matter to me whether a schema-change is considered a content-change or not. I can sum the two in my own code if needed. But the documentation should describe whether field-changes, or COMMITs, or whatever is counted. I know I can read the file's header myself (and that's what my current solution does) but this means I need to include file-handing libraries in my library which I don't otherwise need. It's not a neat solution. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users