On Sat, Jun 25, 2016 at 11:26 PM, Simon Slavin wrote:
>
> On 26 Jun 2016, at 2:52am, Igor Korot wrote:
>
>> Now we need to see the actual German version test result with old and
>> new version of the shell tool.
>
> No need. Given your testing and the bugfix Keith pointed to I can predict it
>
On 26 Jun 2016, at 2:52am, Igor Korot wrote:
> Now we need to see the actual German version test result with old and
> new version of the shell tool.
No need. Given your testing and the bugfix Keith pointed to I can predict it
will work fine for the new version. The problem was that the old
> Good news - it looks like the API was fixed as well. I don't have a
> crash anymore.
> However I have a bad news - the API was fixed in the backward-incompatible
> way.
> Meaning that running the new DLL against the old database will still
> crash. But I guess that is kind of expected.
> So wit
Simon,
On Sat, Jun 25, 2016 at 9:11 PM, Igor Korot wrote:
> Simon,
>
> On Sat, Jun 25, 2016 at 8:32 PM, Simon Slavin wrote:
>>
>> On 26 Jun 2016, at 1:29am, Igor Korot wrote:
>>
>>> Now it would be interesting to know what is the result on German
>>> version of Windows with German
>>> keyboard.
Simon,
On Sat, Jun 25, 2016 at 8:32 PM, Simon Slavin wrote:
>
> On 26 Jun 2016, at 1:29am, Igor Korot wrote:
>
>> Now it would be interesting to know what is the result on German
>> version of Windows with German
>> keyboard.
>
> Agreed.
Anyone from Germany around who has German version of Wind
On 26 Jun 2016, at 1:29am, Igor Korot wrote:
> Now it would be interesting to know what is the result on German
> version of Windows with German
> keyboard.
Agreed.
> Also, for my purposes I should be using that version of the SQLite,
> right? And everything will just work.
That version or la
Simon,
On Sat, Jun 25, 2016 at 8:18 PM, Simon Slavin wrote:
>
> On 26 Jun 2016, at 1:14am, Igor Korot wrote:
>
>> That would be 313, correct?
>
> Yes. The idea is to see if the bug still occurs in the current version. If
> it doesn't, it has probably been fixed already.
It looks like I h
On 26 Jun 2016, at 1:14am, Igor Korot wrote:
> That would be 313, correct?
Yes. The idea is to see if the bug still occurs in the current version. If it
doesn't, it has probably been fixed already.
Simon.
___
sqlite-users mailing list
sqlite-u
For comparison, here is what I get on my Mac:
SQLite version 3.13.0 2016-05-02 15:00:23
Enter ".help" for usage hints.
Connected to a transient in-memory database.
Use ".open FILENAME" to reopen on a persistent database.
sqlite> CREATE TABLE abcß▀(id integer primary key, αΓ string);
sqlite> SELECT
Simon,
On Sat, Jun 25, 2016 at 8:08 PM, Simon Slavin wrote:
>
> On 25 Jun 2016, at 5:51am, Igor Korot wrote:
>
>> This are the results of me trying:
>>
>> SQLite version 3.9.2 2015-11-02 18:31:45
>> Enter ".help" for usage hints.
>> Connected to a transient in-memory database.
>> Use ".open FILE
On 25 Jun 2016, at 5:51am, Igor Korot wrote:
> This are the results of me trying:
>
> SQLite version 3.9.2 2015-11-02 18:31:45
> Enter ".help" for usage hints.
> Connected to a transient in-memory database.
> Use ".open FILENAME" to reopen on a persistent database.
> sqlite> CREATE TABLE abcß▀(
> This are the results of me trying:
>
> SQLite version 3.9.2 2015-11-02 18:31:45
> Enter ".help" for usage hints.
> Connected to a transient in-memory database.
> Use ".open FILENAME" to reopen on a persistent database.
> sqlite> CREATE TABLE abcß▀(id integer primary key, αΓ string); first
> value
Keith,
On Sat, Jun 25, 2016 at 10:14 AM, Keith Medcalf wrote:
>> > And look in the registry under
>> HKLM\CurrentControlSet\Control\NLS\CodePage
>
>> On my Windows 8.1 machine I don't have HK_LOCAL_MACHINE\CurrentControlSet.
>
> Ooops. My typo ...
>
> It is HKLM\SYSTEM\CurrentControlSet\NLS\Code
> > And look in the registry under
> HKLM\CurrentControlSet\Control\NLS\CodePage
> On my Windows 8.1 machine I don't have HK_LOCAL_MACHINE\CurrentControlSet.
Ooops. My typo ...
It is HKLM\SYSTEM\CurrentControlSet\NLS\CodePage
> > and report the value for ACP and OEMCP ...
> > and also the v
half Of Simon Slavin
>> Sent: Saturday, 25 June, 2016 02:40
>> To: SQLite mailing list
>> Subject: Re: [sqlite] Conversion failure
>>
>>
>> On 25 Jun 2016, at 5:51am, Igor Korot wrote:
>>
>> > So now the question is - what encoding is that value, so
Simon,
On Sat, Jun 25, 2016 at 4:39 AM, Simon Slavin wrote:
>
> On 25 Jun 2016, at 5:51am, Igor Korot wrote:
>
>> So now the question is - what encoding is that value, so that it can
>> be successfully converted to wstring?
>
> Please execute
>
> PRAGMA encoding
It gives UTF-8.
Thank you.
>
>
-users-
> boun...@mailinglists.sqlite.org] On Behalf Of Simon Slavin
> Sent: Saturday, 25 June, 2016 02:40
> To: SQLite mailing list
> Subject: Re: [sqlite] Conversion failure
>
>
> On 25 Jun 2016, at 5:51am, Igor Korot wrote:
>
> > So now the question is - what encoding
On 25 Jun 2016, at 5:51am, Igor Korot wrote:
> So now the question is - what encoding is that value, so that it can
> be successfully converted to wstring?
Please execute
PRAGMA encoding
https://www.sqlite.org/pragma.html#pragma_encoding
Simon.
___
Scott,
On Fri, Jun 24, 2016 at 2:16 PM, Scott Robison wrote:
> On Fri, Jun 24, 2016 at 12:03 PM, Scott Robison
> wrote:
>
>> On Windows, when you get a string of characters, you either get an ANSI
>> string using some code page, or you get a wide character string.
>>
>> When you get an ANSI stri
On Fri, Jun 24, 2016 at 2:02 PM, Keith Medcalf wrote:
>
> > No, I'm using consolas, but am using whatever default codepage settings
> > come with the system (I installed Windows 10 1511 February update on a
> new
> > computer a few months ago). ACP=1252, MACCP=1, OEMCP=437. chcp
> reports
> >
> No, I'm using consolas, but am using whatever default codepage settings
> come with the system (I installed Windows 10 1511 February update on a new
> computer a few months ago). ACP=1252, MACCP=1, OEMCP=437. chcp reports
> my console is using code page 437.
Fascinating!
This means that c
On Fri, Jun 24, 2016 at 12:54 PM, Keith Medcalf wrote:
>
> > On Friday, 24 June, 2016 12:17 -0600, Scott Robison said:
>
> > Okay, rather than guessing, I just did a test from a Windows 10 command
> > prompt. I am getting appropriate UTF-8 sequences. Here is my experiment:
> >
> > I opened a memo
> On Friday, 24 June, 2016 12:17 -0600, Scott Robison said:
> Okay, rather than guessing, I just did a test from a Windows 10 command
> prompt. I am getting appropriate UTF-8 sequences. Here is my experiment:
>
> I opened a memory database and issued the following commands:
>
> create table tes
On Fri, Jun 24, 2016 at 12:03 PM, Scott Robison
wrote:
> On Windows, when you get a string of characters, you either get an ANSI
> string using some code page, or you get a wide character string.
>
> When you get an ANSI string, it is just a sequence of 8 bit bytes. UTF-8
> is also a sequence of
-users-
> boun...@mailinglists.sqlite.org] On Behalf Of Keith Medcalf
> Sent: Friday, 24 June, 2016 11:56
> To: SQLite mailing list
> Subject: Re: [sqlite] Conversion failure
>
>
> > I just did ALT+225 in the SQLite shell during the CREATE TABLE command.
>
> that shou
On Fri, Jun 24, 2016 at 11:08 AM, Igor Korot wrote:
> > To answer your main question: Will a DB in SQLite produce the same
> > characters/encoding in Germany as in the US or China and can data be
> safely
> > sent from one to the other?:
> > The answer is: It should... if the Apps you use convert
> I just did ALT+225 in the SQLite shell during the CREATE TABLE command.
that should be ALT+223, which is ß (UTF8 = C3 9F)
ALT+225 is a different character á (UTF8 = C3 A1)
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://m
On 2016/06/24 7:08 PM, Igor Korot wrote:
OK, so all in all.
What I gather from all your replies is that however I enter the data -
table name, table fields -
whether it will be with "ALT+num", or directly typing it on the
keyboard, and independently
on where the input is produced - US, Germany
Hi,
On Fri, Jun 24, 2016 at 12:51 PM, R Smith wrote:
>
>
> On 2016/06/24 6:11 PM, Simon Slavin wrote:
>>
>> The ALT+num system for entering unusual characters is a Windows thing. On
>> a Mac you do it by picking the character from a virtual keyboard shown on
>> the display, or by holding a key d
Well, that broke spectacularly.
Please bear with me for one more try...
On 2016/06/24 6:51 PM, R Smith wrote:
Igor, to try and explain very simply what needs to happen for one of
your scenarios, I will try a box diagram (I hope this prints correctly):
+-- INPUT --+ +---
On 2016/06/24 6:11 PM, Simon Slavin wrote:
The ALT+num system for entering unusual characters is a Windows thing. On a
Mac you do it by picking the character from a virtual keyboard shown on the
display, or by holding a key down for a second to see variations on it. For
instance, if I hold
On 24 Jun 2016, at 4:56pm, Igor Korot wrote:
> Do you have an international version of OSX or an English one?
There is no such thing. All copies of OS X work with all languages. You tell
it which languages you can read and any programs which support those languages
start displaying in them.
Simon,
On Fri, Jun 24, 2016 at 11:44 AM, Simon Slavin wrote:
>
> On 24 Jun 2016, at 4:37pm, Igor Korot wrote:
>
>> Now are all those scenarios correct?
>> Will me and my German friend be able to open each other db and work with
>> them?
>
> Yes. Unless there's a bug somewhere. Programs which
On 24 Jun 2016, at 4:37pm, Igor Korot wrote:
> Now are all those scenarios correct?
> Will me and my German friend be able to open each other db and work with them?
Yes. Unless there's a bug somewhere. Programs which call the SQLite API
should not be doing anything different just because the
On Fri, Jun 24, 2016 at 11:36 AM, Simon Slavin wrote:
>
> On 24 Jun 2016, at 4:34pm, Igor Korot wrote:
>
>> What do you mean?
>> I'm talking here about the SQLite shell tool downloaded from the
>> official web site (the executable).
>> I'm NOT talking about self-compiled tool and neither modified
Simon,
On Fri, Jun 24, 2016 at 11:34 AM, Igor Korot wrote:
> Simon,
>
> On Fri, Jun 24, 2016 at 11:13 AM, Simon Slavin wrote:
>>
>> On 24 Jun 2016, at 3:55pm, Igor Korot wrote:
>>
>>> Are those 3 scenarios correct?
>>
>> They are if the shell tool (or any other SQLite software) works the way it
On 24 Jun 2016, at 4:34pm, Igor Korot wrote:
> What do you mean?
> I'm talking here about the SQLite shell tool downloaded from the
> official web site (the executable).
> I'm NOT talking about self-compiled tool and neither modified self-compiled
> one.
I'm saying that there may be a bug in t
Simon,
On Fri, Jun 24, 2016 at 11:13 AM, Simon Slavin wrote:
>
> On 24 Jun 2016, at 3:55pm, Igor Korot wrote:
>
>> Are those 3 scenarios correct?
>
> They are if the shell tool (or any other SQLite software) works the way it
> should do. If you have found a situation where the selected code pa
On 24 Jun 2016, at 3:55pm, Igor Korot wrote:
> Are those 3 scenarios correct?
They are if the shell tool (or any other SQLite software) works the way it
should do. If you have found a situation where the selected code page changes
what makes it into a SQLite database then there is a bug some
Rowan et al,
On Fri, Jun 24, 2016 at 4:34 AM, Rowan Worth wrote:
> On 24 June 2016 at 16:13, Simon Slavin wrote:
>
>> On 24 Jun 2016, at 5:04am, Igor Korot wrote:
>>
>> > But everything should work independently of what code page is being used?
>>
>> The SQLite shell tool should work independen
On 24 June 2016 at 16:13, Simon Slavin wrote:
> On 24 Jun 2016, at 5:04am, Igor Korot wrote:
>
> > But everything should work independently of what code page is being used?
>
> The SQLite shell tool should work independently of the code page you have
> set. It should be translating strings from
On 24 Jun 2016, at 5:04am, Igor Korot wrote:
> But everything should work independently of what code page is being used?
The SQLite shell tool should work independently of the code page you have set.
It should be translating strings from your current code page into Unicode.
From your report
On 2016/06/24 9:15 AM, Hick Gunter wrote:
I have a friend who owns an automated dog hotel. To check in your dog, it needs
to go inside a standard dog box which is then put on a conveyor belt. To check
out your dog, you present your receipt to a scanner, which causes the box to be
retrieved a
On 2016/06/24 6:04 AM, Igor Korot wrote:
No, I didn't.
But everything should work independently of what code page is being used?
My interface to the DB is based on the std::wstring. So, if someone
will create the DB
inside the shell and then create tables and name them using Chinese,
why I sho
[mailto:sqlite-users-boun...@mailinglists.sqlite.org] Im Auftrag von Igor Korot
Gesendet: Freitag, 24. Juni 2016 04:14
An: SQLite mailing list
Betreff: Re: [sqlite] Conversion failure
Simon,
On Thu, Jun 23, 2016 at 8:44 PM, Simon Slavin wrote:
>
> On 23 Jun 2016, at 11:42pm, Igor Korot
The sqlite shell, at least historically, has I think not accounted for text
encoding and simply passed whatever it reads from the console into the
database.
There has been recent changes in this area since your last email on the
subject, for sqlite 3.12.0. What version are you using, Igor?
-Rowan
Kevin,
On Thu, Jun 23, 2016 at 11:39 PM, Kevin Benson wrote:
> --
>--
> --
> --Ô¿Ô--
> K e V i N
>
> On Thu, Jun 23, 2016 at 10:38 AM, Igor Korot wrote:
>
>> Hi, Clemens,
>>
>> On Thu, Jun 23, 2016 at 10:33 AM, Clemens Ladisch
>> wrote:
>> > Igor Korot wrote:
>> >> I
--
--
--
--Ô¿Ô--
K e V i N
On Thu, Jun 23, 2016 at 10:38 AM, Igor Korot wrote:
> Hi, Clemens,
>
> On Thu, Jun 23, 2016 at 10:33 AM, Clemens Ladisch
> wrote:
> > Igor Korot wrote:
> >> I am trying to find out why the following code fails to do proper
> conversion.
> >>
Simon,
On Thu, Jun 23, 2016 at 8:44 PM, Simon Slavin wrote:
>
> On 23 Jun 2016, at 11:42pm, Igor Korot wrote:
>
>> OK, so are they UTF-8, UTF-16 or something else?
>> And I'm talking the default one - the one which is set when I just
>> open the shell tool and say CREATE TABLE() on the
>> empty
On 23 Jun 2016, at 11:42pm, Igor Korot wrote:
> OK, so are they UTF-8, UTF-16 or something else?
> And I'm talking the default one - the one which is set when I just
> open the shell tool and say CREATE TABLE() on the
> empty database.
> Knowing this will help with the exception I am seeing.
Yo
On Thu, 23 Jun 2016 17:49:04 -0400, Igor Korot
wrote:
> Yes, it is a PC (a laptop with Windows).
> OK, I understand and its unfortunate, but that's life.
>
> Now the question is: what is the best way to fix it?
> From the link I posted it sounds like there is a byte sequence before
> the string,
On 2016/06/24 12:42 AM, Igor Korot wrote:
Your locale should not have any effect on what goes into a SQLite
database. All strings must be translated into Unicode before they are
passed to the SQLite API. And by 'All strings' I include SQL commands
like the ones which create tables and defin
Simon,
On Thu, Jun 23, 2016 at 6:14 PM, Simon Slavin wrote:
>
> On 23 Jun 2016, at 10:53pm, Igor Korot wrote:
>
>> So what I'm trying to do is to see what will happen if I get a
>> database with the German character(s)
>> or Asian characters in the table/field name and they will be entered
>> th
On 23 Jun 2016, at 10:53pm, Igor Korot wrote:
> So what I'm trying to do is to see what will happen if I get a
> database with the German character(s)
> or Asian characters in the table/field name and they will be entered
> the same way.
All table/field names in a SQLite database are Unicode.
Hi, Ralf,
On Thu, Jun 23, 2016 at 12:38 PM, Ralf Junker wrote:
> If you are on Windows, you can use SQLiteSpy to correct such wrongly entered
> ANSI text to Unicode throughout an entire database:
It is not wrongly entered text.
I am using Windows with English locale only.
So what I'm trying to
ot
> Gesendet: Donnerstag, 23. Juni 2016 17:58
> An: SQLite mailing list
> Betreff: Re: [sqlite] Conversion failure
>
> Hi, Gunter,
>
> On Thu, Jun 23, 2016 at 10:59 AM, Hick Gunter wrote:
>> Open the editor application, type in your command, save to file and the vi
If you are on Windows, you can use SQLiteSpy to correct such wrongly
entered ANSI text to Unicode throughout an entire database:
http://yunqa.de/delphi/products/sqlitespy/index
Open the database and from the menu pick
Execute -> Text to Unicode Convertsion ...
A dialog opens where you can
sequence you gave to it.
-Ursprüngliche Nachricht-
Von: sqlite-users-boun...@mailinglists.sqlite.org
[mailto:sqlite-users-boun...@mailinglists.sqlite.org] Im Auftrag von Igor Korot
Gesendet: Donnerstag, 23. Juni 2016 17:58
An: SQLite mailing list
Betreff: Re: [sqlite] Conversion failure
Hi
ftrag von Igor
> Korot
> Gesendet: Donnerstag, 23. Juni 2016 16:39
> An: SQLite mailing list
> Betreff: Re: [sqlite] Conversion failure
>
> Hi, Clemens,
>
> On Thu, Jun 23, 2016 at 10:33 AM, Clemens Ladisch wrote:
>> Igor Korot wrote:
>>> I am trying to find out why
Korot
Gesendet: Donnerstag, 23. Juni 2016 16:39
An: SQLite mailing list
Betreff: Re: [sqlite] Conversion failure
Hi, Clemens,
On Thu, Jun 23, 2016 at 10:33 AM, Clemens Ladisch wrote:
> Igor Korot wrote:
>> I am trying to find out why the following code fails to do proper conversion.
>&
Hi, Clemens,
On Thu, Jun 23, 2016 at 10:33 AM, Clemens Ladisch wrote:
> Igor Korot wrote:
>> I am trying to find out why the following code fails to do proper conversion.
>> It works if the tableName have "abcd", but fails if it has "abcß" (the
>> German letter for the "ss" (looks like Greek lett
Igor Korot wrote:
> I am trying to find out why the following code fails to do proper conversion.
> It works if the tableName have "abcd", but fails if it has "abcß" (the
> German letter for the "ss" (looks like Greek letter beta)).
>
> const unsigned char *tableName = sqlite3_column_text( stmt, 0
Hi,
I am trying to find out why the following code fails to do proper conversion.
It works if the tableName have "abcd", but fails if it has "abcß" (the
German letter for the "ss" (looks like Greek letter beta)).
struct Table
{
std::wstring name;
std::vector fields;
std::vector foreign
63 matches
Mail list logo
