Re: [sqlite] A proposal for SQLite version 3.0
Windows UTF-16 is represented by WCHAR. It is always 2 bytes. UCS-2 can be 3 or more bytes but these are for extended characters outside the ones used for real language. For example, musical notation symbols use the third byte. I don't think any OS's use UCS2 directly. I know Oracle supports UTF8, UTF16, and UCS2. In fact, Oracle's online documentation has a really good discussion of Unicode. Look for their internationalization book. I wrote some code that was sharing data from Oracle to Microsoft SQL Server and found this book very helpful. Oracle generally favors UTF8 while SQL Server favors UTF16. http://download-west.oracle.com/docs/cd/B10501_01/server.920/a96529/toc.htm If you are going to cast to unsigned char*, you must manage the fact that your strings are two (or more) bytes. You are just effectively using a byte pointer to the string data. I think wchar_t* is used typically but the encoding is usually platform dependent. The big problem you have is that your databases are portable. I think you will need to pick and internal format to store the strings in the db so that you can then translate as appropriate for a platform. You may be able to do some clever things like use sizeof(wchar_t) to find out how many bytes are used for a character and use that for your translation. There is a Unicode book available that talks about the specs. Unfortunately, my experience has been that everyone has their own nuiances. Generally though it is pretty consistent. -- Andrew On Wed, 7 Apr 2004, D. Richard Hipp wrote: > 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? > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sqlite] A proposal for SQLite version 3.0
I'm assuming UTF-8 support will still be there as well? For Windows applications, UTF-16 is much more prevalent. -- Andrew On Wed, 7 Apr 2004, Christian Smith wrote: > 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 > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sqlite] Looking to possibly use sql lite
SQLite should be used when you are writing applications in which you do not want the user to even know they are using a database. It is embedded only and isn't designed with security or concurrency to support a mutli-user load like PostgreSQL/MySQL/Oracle/Microsoft SQL Server. Something like Postgres should be used when you want to allow multiple users to access data at the same time. You can have multiple processes use SQLite but you must manage the access yourself. There is the concept of transactions so you do have isolation levels. I usually have created a database thread and allow db access in that thread only. However, my uses of SQLite have always been as a replacement to a custom data file format for a single application. Storing everything in a single file makes backup easy as well as transporting the data from one machine to another. The single file is trivial to move around and get in the right place. Something like Postgres is more difficult to move the data files. SQLite is designed to access very large files (much bigger than 13MB). Typically, SQLite's perf number will be better than Postgres, et. al. because it is lighter weight. You can use it for a server process but you are really in charge. Think about using SQLite like you would a custom file format and you will understand most of the situations it works well. If you have a picture that has a classic RDBMS in it, SQLite is probably not the right package. Andrew On Thu, 12 Feb 2004, [EMAIL PROTECTED] wrote: > Just looking for some feedback about how people are using sql lite > Is it mostly embedded systems? > Why and in what situations would i use sqlite over postgres ? > Why and in what situations would i use postgres over sqlite ? > I also have a few questions about scalability ? > > Can multiple processes use the same database file concurrently ? > What are the locking granularities for simultaneous thread access ? > What are the costs benefits of storing everything in one file ? > I saw the benchmarks, but was concerned that the database size was only > 14meg. > > Just trying to make an informed decision. > I have needs for both a single user embedded database and a scalable > multiuser database. > I'm trying to find out how far sqlite will stretch from single use > embedded toward multiuser scalable. > > Thanks, > Kevin > > P.S. I would be happy to format replies and place them on your wiki for > future reference. > > Also do you have a mailing list archives somewhere I could search through ? > > - > 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]
