Well, it didn't seem to work when I copied the file to MacOSX. It
said (after accepting to go into command line mode) "invalid file
format".
I don't have an intel box to test now, so I will try again on monday
at the office.
My other option is to save the data in 2.8 format and convert from
2.8 to 3.1 with the dump command as explained in the documentation. I
installed the 2.8 version from darwinports on MacOSX.
Obviously, I would rather have the first solution working.
Thanks,
Alex
--
Alexander Lamb
[EMAIL PROTECTED]
On Aug 4, 2006, at 6:11 PM, [EMAIL PROTECTED] wrote:
Alexander Lamb <[EMAIL PROTECTED]> wrote:
Well, I am afraid it didn't work.
Somehow, the legacy_file_format info is not "sticky".
The "legacy_file_format" pragma does not appear to be
sticky, but it is. The value reported back by
PRAGMA legacy_file_format
is incorrect. But the legacy file format did get set.
Mario Frasca <[EMAIL PROTECTED]> wrote:
[EMAIL PROTECTED] wrote:
Adding DATE and TIMEINTERVAL types to SQLite would require an
incompatible file format change.
well, yes, that was already clear. but: where is the type of the
data
being stored? aren't there a few spare bits to use for 'future
additions', that is, new data types? sure, a file containing date
data
would not be understood by executables where this has not been
defined,
but maybe it is possible to do it so that they see a 'text'... or
maybe
not...
Mario: Look back over this thread, and others before it, and
observe all the grief that gets caused by file format changes.
I've learned my lesson: No more file format changes except
too fix a serious bug.
--
D. Richard Hipp <[EMAIL PROTECTED]>
