Re: [sqlite] Conversion failure

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

Re: [sqlite] Virtual Table BestIndex Being Passed LIKE constraints in SQLite 3.13.0?

On Sat, Jun 25, 2016 at 2:55 AM, Mike Nicolino wrote: > Hey Everyone, > > I'm got a system with virtual tables using System.Data.SQLite > 1.0.102.0/SQLite version 3.13.0, the LIKE constraint for queries is now being > passed to the virtual table BestIndex functions

[sqlite] Virtual Table BestIndex Being Passed LIKE constraints in SQLite 3.13.0?

Hey Everyone, I'm got a system with virtual tables using System.Data.SQLite 1.0.102.0/SQLite version 3.13.0, the LIKE constraint for queries is now being passed to the virtual table BestIndex functions (BestIndex is getting 65 as its constraint.op). I had asked a question regarding LIKE

Re: [sqlite] Conversion failure

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,

Re: [sqlite] Conversion failure

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: >

Re: [sqlite] Conversion failure

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.

Re: [sqlite] Conversion failure

And, by the way, do not forget to set your console font to a UNICODE font. The raster fonts are designed for OEM code pages (eg, 437/850) and cannot display the unicode character set properly. You need to use a TrueType font (both Consolas and Lucida Console will work -- Consolas being the

Re: [sqlite] Conversion failure

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

Re: [sqlite] Conversion failure

> 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

Re: [sqlite] Conversion failure

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,

Re: [sqlite] Conversion failure

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,

Re: [sqlite] Conversion failure

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 --+ +---

Re: [sqlite] Conversion failure

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

Re: [sqlite] Conversion failure

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

Re: [sqlite] Conversion failure

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.

Re: [sqlite] Conversion failure

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

Re: [sqlite] Conversion failure

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

Re: [sqlite] Conversion failure

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

Re: [sqlite] Conversion failure

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

Re: [sqlite] Conversion failure

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

Re: [sqlite] Conversion failure

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

Re: [sqlite] Conversion failure

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

[sqlite] SQLite Logo

I am putting together a commercial training for SQLite. I would like to use the SQLite logo - as seen on the website - on the cover of the materials. Can do? ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org

Re: [sqlite] Conversion failure

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 >

Re: [sqlite] Conversion failure

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

Re: [sqlite] Conversion failure

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

Re: [sqlite] Conversion failure

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

Re: [sqlite] Correct design to split sqlite db into month and year ?

On 24 Jun 2016, at 3:19am, mon siong wrote: > This is the correct design for sqlite to split database into > multiple sqlite file and access by multiple application? I also experience db > corrupt . This design cause the DB corrupt ? Your design is a good

Re: [sqlite] Conversion failure

The hex dump shows the sz-ligature encoded as (hex) e1. That is NOT a valid UTF sequence. Sqlite ASSUMES and EXPECTS all input to be UTF encoded. Passing ISO/ANSI encoded special characters in strings is ok as long as the presentation layer on both sides EXPECTS that same encoding. Using