RE: [sqlite] A proposal for SQLite version 3.0
Null is not a value. The definition of NULL is that a value has not been assigned and is therefore unknown. Once a value is assigned, Null is no longer valid. Unless somebody changed the definition in the last thirty years or so :-) > -Original Message- > From: Tom Shafer [mailto:[EMAIL PROTECTED] > Sent: Wednesday, April 07, 2004 9:09 PM > To: [EMAIL PROTECTED] > Subject: [sqlite] A proposal for SQLite version 3.0 > > > Vote for a database parameter:IS NULL A VALUE ? YES or NO > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[sqlite] Clustered indicies Was: [sqlite] A proposal for SQLite version 3.0
Jeff, Jeff Pleimling <[EMAIL PROTECTED]> 08/04/2004 12:42 PM To: [EMAIL PROTECTED] cc: Subject:Re: [sqlite] A proposal for SQLite version 3.0 At 12:08 PM 4/8/2004 +1000, [EMAIL PROTECTED] wrote: > I believe you're thinking of a 'clustered index'. This puts the data > into the order of the index. There can be, of course, only one clustered > index per table. > Since at least some of the data in the table is moved around on every insert, > regular indexs need to take this into account (usually by indirection, rather > then modifying all of the indexes with each insert). Ahh, I didn't think of that. I don't have any other indices on my table, so this wouldn't be a problem for me... but I can see now how it would harm the general case. I guess the simplest implementation would have a proabition on having -any- other indicies on the table. > >If a table could be ordered according to an index, rather than having an > >external index, I think it would significantly improve the time and space > >performance of my databases. I don't know whether my experience would be > >shared by other users. It it were something that could go into 3.0 it > >would at least do me some good. > Clustered indexes can really slow the performance for OLTP (On-Line > Transaction Processing) and other systems where data is added/deleted in a > mixed fashion. Every time a record is inserted, data is possibly moved on > the disk (with page splits causing even more slowdowns). Yes, that's what's happening already in the index whenever I do an insert. My thinking was that maintaining an index-ordered table would be less work overall than maintaining a table with an ordered index. I could be wrong on that, but I'm not sure I see the flaw in my logic. > If your system is entirely historic data, that would be great - but if your > system is inserting meter readings in (near) real-time, you'd probably > get a big performance hit. It's certainly real-time, with the occasional query. > There are many pros and cons. A google search turns up articles (usually for > MS SQL Server) on both side - some people saying 'always' and some 'never'. I can certainly see how the usefulness of this feature could be limited. I guess the problem is primarily related to how the rowid is chosen. If I could choose a rowid that would put the table in the correct order, and renumber as required I might make some ground. I could order by ROWID, then... although there may have to be some kind of code tweakage to allow the where clauses to operate correctly. Hmm... maybe something like this: BEGIN TRANSACTION; SELECT * FROM mytable WHERE -- if the insertion point is after current data: INSERT INTO mytable VALUES (MAX(ROWID) + 10, ) -- else if insertion point is between two values INSERT INTO mytable VALUES (( + )/2, ) -- else rearrange contiguous values UPDATE mytable SET ROWID = ROWID+1 WHERE ROWID >= AND ROWID < INSERT INTO mytable VALUES (, ) END TRANSACTION; Perhaps the changes to sqlite could be as minimal as providing a facility to say: "I promise to keep these rows in an order consistent with this index" so sqlite will use the index in queries. Benjamin. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sqlite] A proposal for SQLite version 3.0
At 12:08 PM 4/8/2004 +1000, [EMAIL PROTECTED] wrote: A little while ago a list reader suggested a kind of index (from ms access, if I recall... I don't recall the term they used) that is not external. Instead the index changes the order in which the table itself is organised. I believe you're thinking of a 'clustered index'. This puts the data into the order of the index. There can be, of course, only one clustered index per table. Since at least some of the data in the table is moved around on every insert, regular indexs need to take this into account (usually by indirection, rather then modifying all of the indexes with each insert). If a table could be ordered according to an index, rather than having an external index, I think it would significantly improve the time and space performance of my databases. I don't know whether my experience would be shared by other users. It it were something that could go into 3.0 it would at least do me some good. I'm not sure it would be good for your application. Clustered indexes are good for OLAP (On-Line Analytical Processing) and other systems where data is rarely inserted (or is inserted in batches at off-hours) and most of the interactive activity is selects (with very few inserts). Clustered indexes can really slow the performance for OLTP (On-Line Transaction Processing) and other systems where data is added/deleted in a mixed fashion. Every time a record is inserted, data is possibly moved on the disk (with page splits causing even more slowdowns). If your system is entirely historic data, that would be great - but if your system is inserting meter readings in (near) real-time, you'd probably get a big performance hit. There are many pros and cons. A google search turns up articles (usually for MS SQL Server) on both side - some people saying 'always' and some 'never'. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[sqlite] A proposal for SQLite version 3.0
Vote for a database parameter:IS NULL A VALUE ? YES or NO - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sqlite] A proposal for SQLite version 3.0
Peoples :) "D. Richard Hipp" <[EMAIL PROTECTED]> 07/04/2004 11:22 PM To: [EMAIL PROTECTED] cc: Subject:[sqlite] A proposal for SQLite version 3.0 > A design proposal for SQLite version 3.0 can be found at: > http://www.sqlite.org/prop2.html > Feedback from the user community is strongly encouraged. Since this is a fairly rare opportunity to make incompatible suggestions that could make it into code, I thought I'd put this left-field one out there: My main use of sqlite is in a database that stores vast quantities of historical data (individual changes on meter readings, that sort of thing). The main table contains data for multiple instruments that each provide their data in time order with their own updates, but out of order with the updates of others: Instrument1,2am,value is 0 Instrument2,1:59am,value is 3 Instrument1,3am,value is 1 Instrument2,3:01am,value is 4 This table is constructed in the order that data comes in, but the queries I want to do are quite different: SELECT * FROM thetable WHERE instrument="Instrument1" AND time >= 2am and time <= 3am ORDER BY TIME; Well, I have an index to make this work efficiently (the exact query and index details probably aren't that important here). The problem is that the index contributes significantly to the size of the database and the fact that I keep the original ordering around but unused seems like a waste of effort. Queries are also slower than they would be if they were following an integer primary key along a real table, with the extra O(log(n)) lookup for each result entry. A little while ago a list reader suggested a kind of index (from ms access, if I recall... I don't recall the term they used) that is not external. Instead the index changes the order in which the table itself is organised. You suggested at the time that if explicit ordering were required the user could use a CREATE TABLE AS SELECT statement to get things in that order, but that sqlite would have to table-scan as it would have no saved knowledge of the table ordering. Moreover the table would not remain ordered as new elements were ordered. If a table could be ordered according to an index, rather than having an external index, I think it would significantly improve the time and space performance of my databases. I don't know whether my experience would be shared by other users. It it were something that could go into 3.0 it would at least do me some good. The other thing that I think will help me most is the native storage of numeric formats. It's great to see this happening :) On the wchar_t subject, I've just looked up http://docs.sun.com/db/doc/806-0477/6j9r2e2bp?a=view, which says wchar_t is a long under 32-bit solaris and int under 64-bit solaris. Both numbers are 32-bits long. According to http://en.wikipedia.org/wiki/UTF-32, a 32-bit representation is the only unicode that is actually fixed-width. Both UTF-8 and UTF-16 are multi-byte, rather than wide characters. This page also lists various known unicode encodings, so may be of some value. Benjamin. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sqlite] A proposal for SQLite version 3.0
Darren Duncan wrote: Here are some of the things I like (correct me if any actually not present): Your summary looks very good. Thanks you. - SQL strings given to prepare() can have "?" placeholders for inspecific literals to fill in later with bind() functions. VERY VALUABLE. - Actual blobs can be stored and fetched without any nasty encoding/decoding. Version 2.8.13 already supports this, BTW. Version 3.0 will continue the support. - Can distinguish between a NULL (explicit unknown value) and a string of zero length (explicit known value). SQLite has had this property going back to version 1.0. The distinction is lost in the wrappers to many scripting languages. But that isn't really SQLite's fault. I do not see UTF-16 providing any speed benefits in regards to being 'the same' as internal Unicode representations for various operating systems like Windows or Mac OS X; true, it may match some OSs, but for others you will need just as much work or speed penalty to convert from UTF-16 to what the operating system uses and from UTF-8. Of course, you may already know this and the disk/memory usage leveling may be the main reason you support UTF-16. The internal representation of text can be either UTF-8 or UTF-16 (either byte order). The text representation is fixed when the database is created. If you are dealing primarily with UTF-8 text, it makes sense then to create the database so that it uses UTF-8 internally. Similarly, create databases to use UTF-16 internally if that is your primary usage. That way conversions are minimized. Regardless of the internal representation, text can always be accessed as either UTF-8 or UTF-16. If what you want does not match the internal representation, an automatic conversion occurs. -- D. Richard Hipp -- [EMAIL PROTECTED] -- 704.948.4565 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sqlite] A proposal for SQLite version 3.0
eno wrote: well, the question is: Support UTF-16 to what extent? I think here of sorting questions, (but other may arise). Obviously, sorting within a single language is specific to that language, whereas sorting a, say, german word with an ukrainian word is what a programmer calls "undefined". And comparing two german words - according to the rules a german user would expect - might be different from what a default comparison routine would return. The programmer can use sqlite3_create_collation() to register collating sequences for any languages she wants. You can then say things like: SELECT addr FROM phonebook ORDER BY name COLLATE german; CREATE INDEX idx1 ON phonebook(name COLLATE ukrainian); CREATE TABLE phonebook( name1 TEXT COLLATE french, name2 TEXT COLLATE japanese, addr TEXT ); Unlike client/server databases which much provide a predefined set of sort orders, SQLite provides a single simplistic sort order plus the capability for the programmer to add whatever other sort orders are desired. -- D. Richard Hipp -- [EMAIL PROTECTED] -- 704.948.4565 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sqlite] A proposal for SQLite version 3.0
At 9:22 AM -0400 4/7/04, D. Richard Hipp wrote: A design proposal for SQLite version 3.0 can be found at: http://www.sqlite.org/prop2.html Feedback from the user community is strongly encouraged. Hey, this looks great! Here are some of the things I like (correct me if any actually not present): - New features in 3.0, 2.x maintained for bug fixes only. - Altered "sqlite3_" API prefixes to simplify app binding to both versions. - Principle of break everything at once (same one used with Perl 6 design). - API backward compatability with 2.x relegated to external wrapper layer. - Unicode is now the native text representation, and only option for files. - All internal code from pager layer on up is natively/conceptually big-endian only, with big/little distinctions made at OS layer or other periphery. - SQL strings given to prepare() can have "?" placeholders for inspecific literals to fill in later with bind() functions. VERY VALUABLE. - Actual blobs can be stored and fetched without any nasty encoding/decoding. - Can distinguish between a NULL (explicit unknown value) and a string of zero length (explicit known value). - Actual integers and floats which are 64 bits, when program wants *numbers*. - Default collating output of NULLs followed by numbers, by blobs, by text. - Ability to use binary values in indexes. - All "unqualified" function APIs expect UTF-8 for text by default, where UTF-16 has separate functions with '16' added to their names. - Smaller and faster than 2.x. - Removal of deprecated callback interface. Here are some improvements or suggestions that I can make: - Provide support for named inspecific literal placeholders in SQL rather than only positional ones, which the "?" are. I think that some other database engines use placeholder names like ":foo" and ":bar" so you could do it that way. These are useful because the SQL code and corresponding bind function calls are a lot more self-documenting, and less prone to programmer errors (alignment errors) when making or changing longer SQL statements with lots of placeholders. Another advantage is that when the same inspecific literal value is used multiple times in the same SQL statement, as often happens, it only needs to be bound or copied by the API once. Note that for simplicity or efficiency the named and positional versions should both be available, and be mutually exclusive (eg: someone could use both at once without conflicts). - While you are good to have support for it, I'm not sure I recognize a great amount of value that UTF-16 provides over UTF-8. More specifically, the main benefit I see UTF-16 providing is a more efficient use of disk space or memory when our data has a lot of non-latin characters in it; in that respect it tends to level the playing field resource-usage-wise for people in all parts of the world. However, I do not see UTF-16 providing any speed benefits in regards to being 'the same' as internal Unicode representations for various operating systems like Windows or Mac OS X; true, it may match some OSs, but for others you will need just as much work or speed penalty to convert from UTF-16 to what the operating system uses and from UTF-8. Of course, you may already know this and the disk/memory usage leveling may be the main reason you support UTF-16. - You mentioned in one line about doing something with the recent concurrency proposal discussion. Obviously this will have to be fleshed out inside the proposal before it can be commended on as feedback. I probably forgot some of what I was going to say in this feedback, so maybe later. Note also that I am not reading anyone's responses to DRH's initial post and proposal until after I post this, so that my impressions of the original proposal are not tainted by them. So thanks DRH, and keep up the good work. -- Darren Duncan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fw: [sqlite] A proposal for SQLite version 3.0
In 04/08/2004 05:38 AM, Roy Black wrote: I have no clue how Jakub Adamek gets 3x bigger files than MS Access. I always get 2x less. How is it possible ? My opinion is closer (but not exact) to Jakub's. I have 3 databases, each database has the same structure (about 100 tables) but different amount of data. Here you have my comparsion of disk spaces used by my databases in MS Access and SQLiter format: MS Access: DB1 - 20MB DB2 - 31MB DB3 - 18MB SQLite: DB1 - 45MB DB2 - 67MB DB3 - 38MB So, as you can see, after mdb2sqlite conversion, I get more than 2x bigger SQLite files. Greets -- Mateusz Łoskot, mateusz at loskot dot net GNU/Linux (Slackware 9.1) http://counter.li.org #220771 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sqlite] A proposal for SQLite version 3.0
It might be true if you mostly store large quantities of NUMERICAL data (float, int, ...) since they are currently stored as strings (the value 1234567, would be stored using at least 7-8 bytes instead of 4). If you were in the same situation as I, where I use database mostly for strings, you would be in the opposite situation, the SQLite database would be about half the size of the MS Access one, since MS Access seems to save all strings as UTF-16. Simon B. On Wed, 2004-04-07 at 10:50, Jakub Adamek wrote: > Hello, > > I am using SQLite in a car navigation system which should work on PDAs > as well. Thus speed and size is crucial for us. SQLite is superb in the > speed category, but the size of its file is not so superb. I see you > mentioned something about file size. My experience is that SQLite makes > roughly about 3x bigger files than MS Access. How would this change in 3.0? > > Thanks for your excellent work, > > Jakub Adamek > > D. Richard Hipp wrote: > > > A design proposal for SQLite version 3.0 can be found at: > > > > http://www.sqlite.org/prop2.html > > > > Feedback from the user community is strongly encouraged. > > An executive summary of the proposed changes follows: > > > >* Support for UTF-16 > >* Better BLOB support > >* User-defined collating sequences (for better > > internationalization support) > >* Smaller and faster than 2.8.13. > > > > The plan is to continue to support the 2.8.X series > > indefinately and in parallel to the 3.X series. But > > the only changes to 2.8.X going forward will be bug > > fixes. New features will go into 3.X. Beta releases > > of version 3.X are expected within a few months. > > > > I do not have much experience with UTF-16 and am > > expecially interested in feedback on that area of > > the design. > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] >
RE: [sqlite] A proposal for SQLite version 3.0
Wouldn't this be due to SQLite storing everything as strings? If your database is predominantly numbers then I imagine the differences between Access and SQLite could be huge. Steve -Original Message- From: Roy Black [mailto:[EMAIL PROTECTED] Sent: 08 April 2004 04:38 To: [EMAIL PROTECTED] Subject: Fw: [sqlite] A proposal for SQLite version 3.0 I have no clue how Jakub Adamek gets 3x bigger files than MS Access. I always get 2x less. - Original Message - From: "D. Richard Hipp" <[EMAIL PROTECTED]> To: "Jakub Adamek" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Wednesday, April 07, 2004 9:10 AM Subject: Re: [sqlite] A proposal for SQLite version 3.0 Jakub Adamek wrote: > My experience is that SQLite makes roughly about 3x bigger files than MS > Access. How would this change in 3.0? > SQLite is very storage efficient in the common case. In a typical table, SQLite will use about 4 or 5 bytes of disk space for every 3 bytes of actual data stored. Put another way, about 60% to 75% of an SQLite database file is the actual data being stored and the other 40% to 25% is overhead. If you have an example where the overhead is significantly larger than this, I'd be interested in seeing it. The new version 3.0 file format is anticipated to reduce overhead by about 5%. YMMV, of course. -- D. Richard Hipp -- [EMAIL PROTECTED] -- 704.948.4565 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [sqlite] A proposal for SQLite version 3.0
Yes, things are very tight on all of our products over here as well! I would like to know what causes a bloated file. Thanks, Allan http://www.aspire.ws http://store.aspire.ws -Original Message- From: Roy Black [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 07, 2004 10:38 PM To: [EMAIL PROTECTED] Subject: Fw: [sqlite] A proposal for SQLite version 3.0 I have no clue how Jakub Adamek gets 3x bigger files than MS Access. I always get 2x less. - Original Message - From: "D. Richard Hipp" <[EMAIL PROTECTED]> To: "Jakub Adamek" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Wednesday, April 07, 2004 9:10 AM Subject: Re: [sqlite] A proposal for SQLite version 3.0 Jakub Adamek wrote: > My experience is that SQLite makes roughly about 3x bigger files than MS > Access. How would this change in 3.0? > SQLite is very storage efficient in the common case. In a typical table, SQLite will use about 4 or 5 bytes of disk space for every 3 bytes of actual data stored. Put another way, about 60% to 75% of an SQLite database file is the actual data being stored and the other 40% to 25% is overhead. If you have an example where the overhead is significantly larger than this, I'd be interested in seeing it. The new version 3.0 file format is anticipated to reduce overhead by about 5%. YMMV, of course. -- D. Richard Hipp -- [EMAIL PROTECTED] -- 704.948.4565 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Fw: [sqlite] A proposal for SQLite version 3.0
I have no clue how Jakub Adamek gets 3x bigger files than MS Access. I always get 2x less. - Original Message - From: "D. Richard Hipp" <[EMAIL PROTECTED]> To: "Jakub Adamek" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Wednesday, April 07, 2004 9:10 AM Subject: Re: [sqlite] A proposal for SQLite version 3.0 Jakub Adamek wrote: > My experience is that SQLite makes roughly about 3x bigger files than MS > Access. How would this change in 3.0? > SQLite is very storage efficient in the common case. In a typical table, SQLite will use about 4 or 5 bytes of disk space for every 3 bytes of actual data stored. Put another way, about 60% to 75% of an SQLite database file is the actual data being stored and the other 40% to 25% is overhead. If you have an example where the overhead is significantly larger than this, I'd be interested in seeing it. The new version 3.0 file format is anticipated to reduce overhead by about 5%. YMMV, of course. -- D. Richard Hipp -- [EMAIL PROTECTED] -- 704.948.4565 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sqlite] A proposal for SQLite version 3.0
Simon Berthiaume wrote: >> Notice that text strings are always transferred as type "char*" even if the text representation is UTF-16. This might force users to explicitely type cast some calls to function to avoir warnings. I would prefer UNICODE neutral functions that can take either one of them depending on the setting of a compilation #define (UNICODE). Create a function that takes char * and another that takes wchar_t * them encourage the use of a #defined symbol that would switch depending on context (see example below). It would allow people to call the functions in either way they want. Example: int sqlite3_open8(const char*, sqlite3**, const char**); int sqlite3_open16(const wchar_t*, sqlite3**, const wchar_t**); #ifdef UNICODE #define sqlite3_open sqlite3_open16 #else #define sqlite3_open sqlite3_open8 #endif I'm told that wchar_t is 2 bytes on some systems and 4 bytes on others. Is it really acceptable to use wchar_t* as a UTF-16 string pointer? Note that internally, sqlite3 will cast all UTF-16 strings to be of type "unsigned char*". So the type in the declaration doesn't really matter. But it would be nice to avoid compiler warnings. So what datatype are most systems expecting to use for UTF-16 strings? Who can provide me with a list? Or even a few examples? -- D. Richard Hipp -- [EMAIL PROTECTED] -- 704.948.4565 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sqlite] A proposal for SQLite version 3.0
On Wed, 7 Apr 2004, D. Richard Hipp wrote: >A design proposal for SQLite version 3.0 can be found at: > > http://www.sqlite.org/prop2.html > >Feedback from the user community is strongly encouraged. >An executive summary of the proposed changes follows: > >* Support for UTF-16 > >I do not have much experience with UTF-16 and am >expecially interested in feedback on that area of >the design. > For better or for worse (I've not much experience myself) other systems use wchar to represent UTF-16 strings, so it might be worth adopting that convention. This may cause problems, though, as we'd have to check if wchar is defined, and typedef it ourselves if not. If you're going to be changing the function prefix to sqlite3_, then it might also be worth changing the header file to sqlite3.h as well, that way we can also provide a seperate sqlite.h which wraps the sqlite3 API in the old API. I'd prefer that than being able to use the two library versions at the same time. Is there much call for a binary to use two versions of the library at the same time? Surely the proper dump/restore as discussed a few weeks would be better for data compatibility? Cheers, Christian -- /"\ \ /ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL X - AGAINST MS ATTACHMENTS / \ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sqlite] A proposal for SQLite version 3.0
Hello, I am using SQLite in a car navigation system which should work on PDAs as well. Thus speed and size is crucial for us. SQLite is superb in the speed category, but the size of its file is not so superb. I see you mentioned something about file size. My experience is that SQLite makes roughly about 3x bigger files than MS Access. How would this change in 3.0? Thanks for your excellent work, Jakub Adamek D. Richard Hipp wrote: A design proposal for SQLite version 3.0 can be found at: http://www.sqlite.org/prop2.html Feedback from the user community is strongly encouraged. An executive summary of the proposed changes follows: * Support for UTF-16 * Better BLOB support * User-defined collating sequences (for better internationalization support) * Smaller and faster than 2.8.13. The plan is to continue to support the 2.8.X series indefinately and in parallel to the 3.X series. But the only changes to 2.8.X going forward will be bug fixes. New features will go into 3.X. Beta releases of version 3.X are expected within a few months. I do not have much experience with UTF-16 and am expecially interested in feedback on that area of the design. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sqlite] A proposal for SQLite version 3.0
As a developer of Delphi components for SQLite I would recommend a new function for both releases to investigate the fileversion. Perhaps it's already there. Of course you can open a database and wait for an exception to occur, but this is not a very clean way of doing things. Having this possibility it would mean that the single component set will be able to handle both sqlite versions, and call different routines and allocate different dll, depending on the version of the file. function GetSQLiteFileVersion(FileId : pChar) : cardinal; albert drent aducom software - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
