On 9 Feb 2004, at 14:53, D. Richard Hipp wrote:
Brass Tilde wrote:
My understanding is that SQLite has had this auto-update feature since
version 2.6.0. If I understand correctly, you should only have a
problem if
you are *now* using a version prior to that, and go from that version
directly to
Brass Tilde wrote:
My understanding is that SQLite has had this auto-update feature since
version 2.6.0. If I understand correctly, you should only have a problem if
you are *now* using a version prior to that, and go from that version
directly to 2.8.12 or later. If you've kept your version of
> On 6 Feb 2004, at 14:05, D. Richard Hipp wrote:
>
> > If you use a modern version of SQLite (version 2.6.0 through 2.8.11)
> > to open an older database file (version 2.1.0 through 2.5.6) the
> > library will automatically rebuild all the indices in the database
> > in order to correct a design
On 6 Feb 2004, at 14:05, D. Richard Hipp wrote:
If you use a modern version of SQLite (version 2.6.0 through 2.8.11)
to open an older database file (version 2.1.0 through 2.5.6) the
library will automatically rebuild all the indices in the database
in order to correct a design flaw in the older
- Original Message -
From: "Nate Bargmann" <[EMAIL PROTECTED]>
> A plugin style of architecture seems much better than a bloated
> all-in-one approach.
Agreed, a plug-inn mechanism or lib-sqlite-bloated would do the job just as
well.
On 7 Feb 2004 at 12:10, Rene wrote:
> > How old is 2.5.6 version?
>
> july 7. 2002
> http://www.sqlite.org/cvstrac/timeline?d=3000=2004-Feb-07=0==0=1=1=1=1
>
> i'm just wondering what strategy will be if database format changes in the
> future, do we depend on external utility then?
I think
code, but smallest possible footprint is not (my)
major issue.
- Original Message -
From: "Michael Roth" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, February 07, 2004 2:04 PM
Subject: Re: [sqlite] OK to drop support for legacy file formats?
> Rene
Saturday, February 07, 2004 2:04 PM
Subject: Re: [sqlite] OK to drop support for legacy file formats?
> Rene wrote:
> >>Why not remove the feature but create a seperate utility project that
> >>converts any version of SQLITE DB to the latest version.
> >
> >
>
On Fri, 6 Feb 2004, D. Richard Hipp wrote:
> Would this proposed change cause anyone unreasonable hardship?
Given that I don't have any investment (code or data) in older SQLite
versions, it will be no problem for me at all if you remove the
auto-conversion feature.
Moreover, I support the
How old is 2.5.6 version?
I agree with Greg.
-Original Message-
From: Greg Obleshchuk [mailto:[EMAIL PROTECTED]
Sent: Friday, February 06, 2004 11:18 PM
To: D. Richard Hipp; [EMAIL PROTECTED]
Subject: Re: [sqlite] OK to drop support for legacy file formats?
Hello,
Why not remove
CTED]>
Sent: Saturday, February 07, 2004 12:41 AM
Subject: RE: [sqlite] OK to drop support for legacy file formats?
> Now there is experience talking. I agree with this view point.
>
> -Original Message-
> From: Greg Obleshchuk [mailto:[EMAIL PROTECTED]
> Sent: Friday, F
.
The current version of SQLite would need to error when openning an older
formatted DB file.
regards
Greg
- Original Message -
From: "D. Richard Hipp" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, February 07, 2004 1:05 AM
Subject: [sqlite] OK to drop s
> If you use a modern version of SQLite (version 2.6.0 through 2.8.11)
>
> I am proposing to drop support for this auto-update feature.
> Beginning with 2.8.12, if you attempt to open a database file
If the opinion of someone who's just started using the product, and has no
intention of using the
If you use a modern version of SQLite (version 2.6.0 through 2.8.11)
to open an older database file (version 2.1.0 through 2.5.6) the
library will automatically rebuild all the indices in the database
in order to correct a design flaw in the older database files.
I am proposing to drop support for
14 matches
Mail list logo
