Doug, 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)."
I have no idea how they are stored, but I would guess as "standard" ASCII. Other community members have provided the interface/wrappers between the scripting language I am using (AutoHotkey) and the SQLite.dll, but I don't think this provides access to the "16" apis you mention. "you would need to explicitly convert your strings to UTF-8 (which is not the same as ASCII) before handing to SQLite." Explicitly converting back and forth between ASCII/UTF-8 seems to have solved this problem, thank you!! I hoped this would also solve the issues I am having with case sensitive international characters (Problem #4), but unfortunately not! (select * where LastName like '%ø%'; will not return names with capital Ø in them and vice versa). Pavel, Thank you for your reply too, I appreciate it. I think I will stick with the above mentioned solution. Regards, Erik P.S. Sorry for not having selected a subject/topic, I was too preoccupied with clarifying my post. >> 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 > _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
