The policy so far has been that file formats within a major
version (i.e 3) are forwards compatible - files created by older versions
can be read/written by newer versions.
Sometimes features are added that mean newer versions can create
files that may not be used by older versions. If you don't use those
features, your files should be backwards compatible. For example,
files created with the "auto-vacuum" feature (version 3.1 and later)
are read-only for library versions 3.0.x. If you use "ALTER TABLE ... ADD
COLUMN" (currently cvs only) your files can't be used by versions earlier
than 3.1.4.
It seems likely this policy will continue.
--- "Kiel W." <[EMAIL PROTECTED]> wrote:
> List,
>
> I'm new to the concept of embedded databases, but it seems to be the
> ideal solution for a project I'm developing for school/ my church.
> Along with any resources you might recommend one question has been on
> my mind for awhile.
>
> As SQLite progresses and I update my source with new releases,
> recompile and deploy is this going to cause the existing database
> files to become "outdated" or no longer work? My guess is no for a
> particular branch (ie 3.x) but I want to be certain. Is there
> expected compatibility breaks later in development? To what extent?
>
> If such breaks happen, with the existing framework of SQLite, how hard
> might it be to transfer over to a newer release? Examples from 2.x to
> 3.x might be helpful.
>
> Thanks for any input.
>
__________________________________
Do you Yahoo!?
Yahoo! Small Business - Try our new resources site!
http://smallbusiness.yahoo.com/resources/
