> If they are stored with wchar_t, then using the '16' APIs is > probably easiest to use (ie sqlite3_open16, sqlite3_prepare16_v2, etc).
Just don't forget that wchar_t on some platforms (reportedly on Linux for example) is 32-bit integer. So conversion between wchar_t and UCS-2 encoding is not always as easy as you can think. Pavel On Fri, Aug 21, 2009 at 9:44 AM, Doug<pa...@poweradmin.com> wrote: > Hi Erick -- > > I can only help a little with #3. How are your strings stored in your > program? If they are stored with wchar_t, then using the '16' APIs is > probably easiest to use (ie sqlite3_open16, sqlite3_prepare16_v2, etc). > That's what I do and all sorts of European and Asian customers don't have > any issues with storing and retrieving local strings. If you don't use the > wide-char (16) APIs, you would need to explicitly convert your strings to > UTF-8 (which is not the same as ASCII) before handing to SQLite. > > Doug > > >> -----Original Message----- >> From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users- >> boun...@sqlite.org] On Behalf Of e...@sitadella.com >> Sent: Thursday, August 20, 2009 4:21 PM >> To: sqlite-users@sqlite.org >> Subject: [sqlite] (no subject) >> >> Hi guys, >> >> This is my first post. I am creating a simple document archiving >> program >> for small businesses. I am creating it in a scripting language called >> www.autohotkey.com. I intend to place the SQLite database file on a >> network share and use sqlite.dll to access and manipulate it. >> >> In general, everything is on a relatively small scale: there will be >> less >> than 10 users who will occasionally interact with the database, there >> will >> be around 4 tables and based on experience with a similar system, I >> don't >> expect a total of more than 50000 records after a few years of use. The >> client computers will be Windows XP or newer and the database file will >> be >> located on a network share on a Windows 2000 server or newer. >> >> 1. I have read that the file locking mechanisms on older windows >> networks >> are not very reliable and that it is not advisable to use SQLite on NFS >> or >> network shares. Given the robustness and efficiency of SQLite and the >> low >> frequency of use of my application, do I still need to worry about >> placing >> the database on a network share? >> >> 2. Should I modify any of the default settings to better suit this >> environment? >> >> 3. I am having problems reading and writing international characters to >> and from the database, specifically the norwegian characters æ, ø and >> å. >> If I use sqlite.exe to create a records containing æ, ø or å, I can >> read >> the record using sqlite.exe without any problems. Likewise, if I use >> SQLiteSpy to create a record containing ø, æ or å I can read the record >> using SQLiteSpy without any problems. But if I create a record in >> sqlite.exe and try to read it with SQLiteSpy or vice versa, it doesn't >> work as expected and the special characters are converted to all sorts >> of >> oddball symbols like squares and question marks. I assume this is >> somehow >> due to different ASCII/UTF encodings, but how can these problems be >> avoided? >> >> 4. Select commands are case sensitive with æ, ø and å. Is there a >> simple >> workaround for this? >> >> >> Regards, >> Erik >> >> _______________________________________________ >> sqlite-users mailing list >> sqlite-users@sqlite.org >> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > > > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
