Re: [sqlite] SQLite version 3.8.6 coming soon

[big stone]

ok,

output comparison

Size is different :
- before28 488 559
- now with beta 28 711 111
==> delta = 222 552  ... which is my number of ouput lines

The change in Newline Output policy (from CR to CR+LF) did generate a
suspens.
WinMerge says output is identical otherwise.


So my 5x improvement seems not the result of a bug.

I'm eager to see the speed-up that will show-up in your more general tests,
section 26. of  http://www.sqlite.org/checklists/3080600/index


Regards,
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] In-memory DB slower than disk-based?

[Jim Callahan]

What is the system memory utilization?
If the in-memory database overloads the real memory
the frantic os virtual memory paging (thrashing) could slow
everything down.

>From your use scenario it sounds like your database shouldn't be that large,
but how large is the database? and how large is the system ram?
What percent of the ram is being used?

Jim Callahan


On Wed, Aug 6, 2014 at 3:39 PM, Fabian Giesen 
wrote:

> On 8/6/2014 11:51 AM, Jensen, Vern wrote:
>
>> *bump*
>>
>> Anyone?
>>
>
> Not sure if this is your problem, but this kind of load puts a lot of
> stress on SQLite's page cache, which might well perform worse than your
> OS'es page cache (used for "real" disk IO) does, especially under high
> contention.
>
> Also, SQLite's defaults wrt. threading are set up to be safe, which means
> that when in doubt about what your code might be doing, SQLite will
> serialize.
>
> I did a bit of SQLite perf tuning recently and here's two things you might
> want to try:
>
> 1. What's your value for "flags"? SQLite by default (pessimistically)
> assumes that you might be sharing a DB connection between multiple threads,
> and thus wraps essentially all API functions in locks to make sure this is
> safe. In a heavily multi-threaded scenario, I would recommend that you
> manually ensure that each connection is only used by one thread at a time,
> and then add SQLITE_OPEN_NOMUTEX to your flags. This reduces lock traffic
> substantially. (If your connection was per-thread already, doing so will
> not reduce contention or have any impact on your asymptotic perf or
> scalability, but locks aren't free.)
>
> 2. Before sqlite3_initialize, try
>
>   "sqlite3_config(SQLITE_CONFIG_MEMSTATUS, 0);"
>
> This disables some API functions that provide access to memory stats, but
> avoids a global lock on every memory allocation/free, and SQLite does a lot
> of them. If you don't need these memory statistics, turning this off can
> make a noticeable difference in scalability.
>
> I'm not sure if this will affect page cache throughput specifically, but
> these two things are both fairly easy to try.
>
> -Fabian
>
> ___
> 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

Re: [sqlite] SQLite version 3.8.6 coming soon

[Scott Robison]

On Wed, Aug 6, 2014 at 6:56 PM, Richard Hipp  wrote:

> On Wed, Aug 6, 2014 at 8:33 PM, James K. Lowden 
> wrote:
>
> > On Wed, 6 Aug 2014 07:40:43 -0400
> > Richard Hipp  wrote:
> >
> > > >
> > > > PS: backward compatibility, no s, no?
> > > >
> > >
> > > A google search shows that you see it both ways - with and without the
> > > "s".  I've always used the "s".
> >
> > http://www.perfectyourenglish.com/vocabulary/backward-backwards.htm
> >
> > Two countries divided by a common tongue.
> >
> >
> Except, I speak Southern English, not British English. And I can promise
> you that we southerners prefer to add the "s" to the end of "backwards".
> I'm not sure PerfectYourEnglish necessarily has all their facts straight.
>

While it is debatable as to whether Texas is part of the south, I too used
backwards until an old retired school teacher, who was substituting one
day, scared me out of using it anymore.

-- 
Scott Robison
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite version 3.8.6 coming soon

[Richard Hipp]

On Wed, Aug 6, 2014 at 8:33 PM, James K. Lowden 
wrote:

> On Wed, 6 Aug 2014 07:40:43 -0400
> Richard Hipp  wrote:
>
> > >
> > > PS: backward compatibility, no s, no?
> > >
> >
> > A google search shows that you see it both ways - with and without the
> > "s".  I've always used the "s".
>
> http://www.perfectyourenglish.com/vocabulary/backward-backwards.htm
>
> Two countries divided by a common tongue.
>
>
Except, I speak Southern English, not British English. And I can promise
you that we southerners prefer to add the "s" to the end of "backwards".
I'm not sure PerfectYourEnglish necessarily has all their facts straight.


-- 
D. Richard Hipp
d...@sqlite.org
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite version 3.8.6 coming soon

[James K. Lowden]

On Wed, 6 Aug 2014 07:40:43 -0400
Richard Hipp  wrote:

> >
> > PS: backward compatibility, no s, no?
> >
> 
> A google search shows that you see it both ways - with and without the
> "s".  I've always used the "s".

http://www.perfectyourenglish.com/vocabulary/backward-backwards.htm

Two countries divided by a common tongue.  

--jkl

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] In-memory DB slower than disk-based?

[Simon Slavin]

On 6 Aug 2014, at 11:00pm, big stone  wrote:

> I too noticed disappointing improvements by going ":memory:".
> But, it seems also very dependent of the compilation options and the
> version of SQLite you use.
> 
> sometimes, gain is roughly 0%
> sometimes, gain can be 40%.

Pagesize for the disk version can make a surprisingly big difference.  There's 
not that much you can do about it since the majority of influences on SQLite 
speed are from things you have no control over, like the storage driver's cache 
strategy, and the OS's process scheduling.

Simon.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite version 3.8.6 coming soon

[Richard Hipp]

On Wed, Aug 6, 2014 at 5:35 PM, big stone  wrote:

> Hello Sqlite team,
>
> My specific need relies on a rather complex combination of "in", and with
> the new beta I go from 50 seconds down to 10 seconds.
> (a 5x improvement)
>
> ==> Is that sort of gain possible with the recent "in" omtimisation,


Yes.



> or  shall look deeper if result is still right ?
>

Yes.  That is the purpose of beta testing, after all.  We may have
overlooked something.
-- 
D. Richard Hipp
d...@sqlite.org
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] In-memory DB slower than disk-based?

[big stone]

Hi,

I too noticed disappointing improvements by going ":memory:".
But, it seems also very dependent of the compilation options and the
version of SQLite you use.

sometimes, gain is roughly 0%
sometimes, gain can be 40%.

==> You may try with a more recent version of SQLite than 3.7.15.2.


https://raw.githubusercontent.com/stonebig/ztest_donotuse/master/benchmark_test01_measures.GIF
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite version 3.8.6 coming soon

[big stone]

Hello Sqlite team,

My specific need relies on a rather complex combination of "in", and with
the new beta I go from 50 seconds down to 10 seconds.
(a 5x improvement)

==> Is that sort of gain possible with the recent "in" omtimisation, or
shall look deeper if result is still right ?

Regards,
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] In-memory DB slower than disk-based?

[Jensen, Vern]

Thanks for the replies, Fabian and Richard.

It’s definitely ‘good enough’ performance as-is, I mainly wanted to see if I 
was doing something clearly wrong, or if my results were surprising. Given that 
they’re not, I’m happy to move on. Thanks again,

-Vern
IMPORTANT WARNING: This message is intended for the use of the person or entity 
to which it is addressed and may contain information that is privileged and 
confidential, the disclosure of which is governed by applicable law. If the 
reader of this message is not the intended recipient, or the employee or agent 
responsible for delivering it to the intended recipient, you are hereby 
notified that any dissemination, distribution or copying of this information is 
STRICTLY PROHIBITED. If you have received this message in error, please notify 
us immediately by calling (310) 423-6428 and destroy the related message. Thank 
You for your cooperation.

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] In-memory DB slower than disk-based?

[Richard Hipp]

On Wed, Aug 6, 2014 at 2:51 PM, Jensen, Vern  wrote:

> *bump*
>
> Anyone?
>

I don't think anybody has any information for you Vern.  So much depends on
the details of your setup that it is hard to speculate what might be going
wrong.

-- 
D. Richard Hipp
d...@sqlite.org
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] In-memory DB slower than disk-based?

[Fabian Giesen]

On 8/6/2014 11:51 AM, Jensen, Vern wrote:

*bump*

Anyone?


Not sure if this is your problem, but this kind of load puts a lot of 
stress on SQLite's page cache, which might well perform worse than your 
OS'es page cache (used for "real" disk IO) does, especially under high 
contention.


Also, SQLite's defaults wrt. threading are set up to be safe, which 
means that when in doubt about what your code might be doing, SQLite 
will serialize.


I did a bit of SQLite perf tuning recently and here's two things you 
might want to try:


1. What's your value for "flags"? SQLite by default (pessimistically) 
assumes that you might be sharing a DB connection between multiple 
threads, and thus wraps essentially all API functions in locks to make 
sure this is safe. In a heavily multi-threaded scenario, I would 
recommend that you manually ensure that each connection is only used by 
one thread at a time, and then add SQLITE_OPEN_NOMUTEX to your flags. 
This reduces lock traffic substantially. (If your connection was 
per-thread already, doing so will not reduce contention or have any 
impact on your asymptotic perf or scalability, but locks aren't free.)


2. Before sqlite3_initialize, try

  "sqlite3_config(SQLITE_CONFIG_MEMSTATUS, 0);"

This disables some API functions that provide access to memory stats, 
but avoids a global lock on every memory allocation/free, and SQLite 
does a lot of them. If you don't need these memory statistics, turning 
this off can make a noticeable difference in scalability.


I'm not sure if this will affect page cache throughput specifically, but 
these two things are both fairly easy to try.


-Fabian
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] In-memory DB slower than disk-based?

[Jensen, Vern]

*bump*

Anyone?

-Vern


Vern Jensen
Software Engineer
Artificial Intelligence in Medicine (AIM) Program
jens...@cshs.org
Office: 310-423-8148 :: Fax: 310-423-0173

On Aug 4, 2014, at 12:02 PM, Jensen, Vern 
mailto:vern.jen...@cshs.org>> wrote:

Hey all! We use SQLite (3.7.15.2) as the backend for a server that provides 
floating licenses for our software. I've recently written a stress-testing 
framework that starts up any number of threads, and hits the server with 
multiple requests per thread.
While being stress-tested in this way, I've found that if the testing framework 
is using 100 threads, a single call to sqlite3_exec() can take 8-15 seconds at 
times (assuming my timeout set with sqlite3_busy_timeout is big enough to allow 
this, otherwise is failed with error code 5 -- LOCKED). This is when doing DB 
writes, obviously. journal_mode is set to WAL.

I assumed that by switching from a DB file on disk to one in memory, we'd see 
this 'write' bottleneck nearly disappear. We don't have too many records in the 
tables being written to, so the only reasonable explanation for 8-15 seconds 
for some writes would be that the DB is on disk.

Yet when switching to an in-memory database (with a shared cache, since 
currently the server has 30 separate threads, each with their own separate 
SQLite connection), I found the performance actually got slightly *worse* than 
with a disk-based version. I re-ran the tests each way several times, and 
indeed, performance is worse.
I open the shared-cache in-memory DB like this:

int result = sqlite3_open_v2("file:memdb1?mode=memory&cache=shared", &_db, 
flags, NULL);

I also tried using these for the in-memory version (versus WAL journaling mode):

sqlite3_exec(_db, "PRAGMA read_uncommitted=true", NULL, NULL, NULL);
sqlite3_exec(_db,"PRAGMA journal_mode=OFF",NULL,NULL,NULL);

but to no avail. Still worse performance than when the DB is on disk. Which 
makes little sense to me.

I realize SQLite was not designed to be accessed concurrently by 100 separate 
users, and this really is a stress-testing case that far exceeds our expected 
real-world usage. But at the same time, I'd like to get this running as 
optimally as possible, and it seems like 8-15 second writes is unreasonable for 
an in-memory database. (Not that 8-15 seconds is the average... but even the 
average is 3-5 seconds when 100 threads are stress-testing the server at once.)

-Vern
IMPORTANT WARNING: This message is intended for the use of the person or entity 
to which it is addressed and may contain information that is privileged and 
confidential, the disclosure of which is governed by applicable law. If the 
reader of this message is not the intended recipient, or the employee or agent 
responsible for delivering it to the intended recipient, you are hereby 
notified that any dissemination, distribution or copying of this information is 
STRICTLY PROHIBITED. If you have received this message in error, please notify 
us immediately by calling (310) 423-6428 and destroy the related message. Thank 
You for your cooperation.

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

IMPORTANT WARNING: This message is intended for the use of the person or entity 
to which it is addressed and may contain information that is privileged and 
confidential, the disclosure of which is governed by applicable law. If the 
reader of this message is not the intended recipient, or the employee or agent 
responsible for delivering it to the intended recipient, you are hereby 
notified that any dissemination, distribution or copying of this information is 
STRICTLY PROHIBITED. If you have received this message in error, please notify 
us immediately by calling (310) 423-6428 and destroy the related message. Thank 
You for your cooperation.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Problem with coalesce in a where clause with bind variables

[Stephan Beal]

On Wed, Aug 6, 2014 at 5:29 PM, Martin Engelschalk <
engelsch...@codeswift.com> wrote:

> Hello List,
>
> I have a strange problem with a statement like
>
> select id from some_table where coalesce(some_col, 1) = :1
>
> where :1 is a bind variable which i bind in my program using
> sqlite3_bind_text.
>

fwiw, i cannot reproduce this using:

#define SQLITE_VERSION"3.8.5"
#define SQLITE_VERSION_NUMBER 3008005
#define SQLITE_SOURCE_ID  "2014-06-04 14:06:34
b1ed4f2a34ba66c29b130f8d13e9092758019212"

so long as the value i bind is of the same type being returned. If, e.g.,
some_col is an integer and i bind '3' instead of integer 3, then i am
seeing what you describe. If i bind an integer to the integer column, or
bind a string to a coalesce-returned string value, then i see what one
would expect.

For completeness:

s2> var d = Fossil.Db.open(':memory:')
s2> d.exec("Create table t(a)")
s2> d.exec("insert into t(a) values(1),(2),(NULL),(3)")
s2> d.each({sql:'select * from t',callback:'print(this)'})
[1]
[2]
[null]
[3]

s2> d.each({sql:'select * from t where
coalesce(a,9)=$a',callback:'print(this)',bind:{$a:'9'}})


s2> d.each({sql:"select * from t where
coalesce(a,'9')=$a",callback:'print(this)',bind:{$a:'9'}})
[null]


s2> d.each({sql:"select * from t where
coalesce(a,'9')=$a",callback:'print(this)',bind:{$a:'1'}})
result: Db@0x1eb4d20[scope=#1@0x7fffd16b3068 ref#=1] ==> Db@0x1eb4d20


s2> d.each({sql:"select * from t where
coalesce(a,'9')=$a",callback:'print(this)',bind:{$a:1}})
[1]


s2> print(d.selectValue("select 1='1'"))
0


-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Problem with coalesce in a where clause with bind variables

[Richard Hipp]

On Wed, Aug 6, 2014 at 11:29 AM, Martin Engelschalk <
engelsch...@codeswift.com> wrote:

> Hello List,
>
> I have a strange problem with a statement like
>
> select id from some_table where coalesce(some_col, 1) = :1
>
> where :1 is a bind variable which i bind in my program using
> sqlite3_bind_text.
>
> I get no records, even if there are no null values anywhere in some_col.
>
> I get the expected records if i replace "coalesce(some_col, 1)" with
> "some_col", and also if i replace the bind variable with a constant.
>


I am unable to reproduce the problem.  Everything works as expected when I
try it.

-- 
D. Richard Hipp
d...@sqlite.org
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] Problem with coalesce in a where clause with bind variables

[Martin Engelschalk]

Hello List,

I have a strange problem with a statement like

select id from some_table where coalesce(some_col, 1) = :1

where :1 is a bind variable which i bind in my program using 
sqlite3_bind_text.


I get no records, even if there are no null values anywhere in some_col.

I get the expected records if i replace "coalesce(some_col, 1)" with 
"some_col", and also if i replace the bind variable with a constant.
It does not seem to matter how the column was defined in the "create 
table" statement, and changing "coalesce(some_col, 1)" to 
"coalesce(some_col, '1')" did not help.


My version is 3.8.5, the database was created with this version.
I also tried with version 3.7.4, the result was the same.
I am quite sure that i use sqlite3_bind_text correctly, because i use my 
own C++ layer which is tested very well and has been working for several 
years.


Have I missed something?

Thank you
Martin



___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite version 3.8.6 coming soon

[jose isaias cabrera]

"Richard Hipp" wrote...



32-bit and 64-bit DLLs are the latest 3.8.6 beta are now available on the
download page.  http://www.sqlite.org/download.html


Thank you very much, Dr. Hipp.

josé



On Tue, Aug 5, 2014 at 11:11 PM, jose isaias cabrera <
jic...@cinops.xerox.com> wrote:



"Richard Hipp" wrote...


 Version 3.8.6 was originally scheduled for September.  But the change 
log

(
http://www.sqlite.org/draft/releaselog/current.html) is getting rather
long
and there are a number of important bug fixes.  So we might try to get
3.8.6 out the door sooner rather than later.

Please test!  Recent amalgamations are available on the download page (
http://www.sqlite.org/download.html).  Please compile your applications
use
the latest tip of trunk and let us know if you encounter any problems.

Please review the change log and speak up if you see anything amiss.

The status board (http://www.sqlite.org/checklists/3080600/index) for 
the

3.8.6 release is now on-line.  The usual rule applies:  When the
check-list
goes all-green, we will cut the release.  No check-list items have been
marked off yet, but we might start marking them off later this week, or
early next week.

Your feedback is greatly appreciated.



Are you planning in creating temporary binaries for Windows?  I use the
DLLs for our application.

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users





--
D. Richard Hipp
d...@sqlite.org
___
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

Re: [sqlite] SQLite version 3.8.6 coming soon

[Richard Hipp]

32-bit and 64-bit DLLs are the latest 3.8.6 beta are now available on the
download page.  http://www.sqlite.org/download.html


On Tue, Aug 5, 2014 at 11:11 PM, jose isaias cabrera <
jic...@cinops.xerox.com> wrote:

>
> "Richard Hipp" wrote...
>
>
>  Version 3.8.6 was originally scheduled for September.  But the change log
>> (
>> http://www.sqlite.org/draft/releaselog/current.html) is getting rather
>> long
>> and there are a number of important bug fixes.  So we might try to get
>> 3.8.6 out the door sooner rather than later.
>>
>> Please test!  Recent amalgamations are available on the download page (
>> http://www.sqlite.org/download.html).  Please compile your applications
>> use
>> the latest tip of trunk and let us know if you encounter any problems.
>>
>> Please review the change log and speak up if you see anything amiss.
>>
>> The status board (http://www.sqlite.org/checklists/3080600/index) for the
>> 3.8.6 release is now on-line.  The usual rule applies:  When the
>> check-list
>> goes all-green, we will cut the release.  No check-list items have been
>> marked off yet, but we might start marking them off later this week, or
>> early next week.
>>
>> Your feedback is greatly appreciated.
>>
>
> Are you planning in creating temporary binaries for Windows?  I use the
> DLLs for our application.
>
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>



-- 
D. Richard Hipp
d...@sqlite.org
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite Support for CE x32 FW 3.5

[Adam Devita]

Did you already read
https://system.data.sqlite.org/index.html/doc/trunk/www/downloads.wiki#sqlite-netFx35-binary-PocketPC-ARM-2008
?


On Tue, Aug 5, 2014 at 10:32 AM, Tobias Stüker 
wrote:

> Hello,
>
> I am developing an .NET Framework 3.5 application for a Windows CE x32 PC.
> Can I get a Library of SQLite for that System?
>
> Best regards,
> Tobias Stüker
>
> Beckhoff Automation GmbH | Managing Director: Dipl. Phys. Hans Beckhoff,
> Arnold Beckhoff
> Registered office: Verl, Germany | Register court: Gütersloh HRB 1803
>
> ___
> 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

Re: [sqlite] Producing RFC4180-compliant CSV output

[Peter Waller]

On 4 August 2014 16:39, Edward Lau  wrote:
> Specifically, if you are going to use SQL Server Integration Services (SSIS) 
> you can specify LF as the record delimiter.  It defaults to {CR}{LF} but you 
> can change it in the FlatFile Connection Manager under the Advance tab.

Thanks for the hint, we are not the one using the output CSVs or SSIS,
but self-service customers of ours, who won't necessarily want to have
to look at advanced tabs.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite Support for CE x32 FW 3.5

[Tobias Stüker]

Hello,

I am developing a .NET Framework 3.5 application for a Windows CE 32bit (x86) 
PC.
Can I get a Library of SQLite for that System?

Best regards,
Tobias

Beckhoff Automation GmbH | Managing Director: Dipl. Phys. Hans Beckhoff, Arnold 
Beckhoff
Registered office: Verl, Germany | Register court: Gütersloh HRB 1803

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] SQLite Support for CE x32 FW 3.5

[Tobias Stüker]

Hello,

I am developing an .NET Framework 3.5 application for a Windows CE x32 PC. Can 
I get a Library of SQLite for that System?

Best regards,
Tobias Stüker

Beckhoff Automation GmbH | Managing Director: Dipl. Phys. Hans Beckhoff, Arnold 
Beckhoff
Registered office: Verl, Germany | Register court: Gütersloh HRB 1803

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] Need Technical Support for Replicate SQLite with Oracle DB

[D Suvathi Priya]

Hi Team,

               We are using SQLite as a Client DB which is Local and Oracle
Db as a Server. We are trying to Copy SQLite DB to Oracle DB 11g Server
(Replication).Is this Possible?
 If so Can we get the right steps  for Replication.
how to replicate SQLite?

Thanks
Suvathi

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite version 3.8.6 coming soon

[Richard Hipp]

On Wed, Aug 6, 2014 at 3:26 AM, Dominique Devienne 
wrote:

>
> PS: backward compatibility, no s, no?
>

A google search shows that you see it both ways - with and without the
"s".  I've always used the "s".


-- 
D. Richard Hipp
d...@sqlite.org
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite version 3.8.6 coming soon

[Richard Hipp]

On Wed, Aug 6, 2014 at 6:34 AM, Tony Papadimitriou  wrote:

> Unless I'm misusing it, I believe the shell readfile() function reads a
> file as text, not binary.  I haven't checked writefile() for the same
> problem on writing.
>
> This is how I use it, is this not correct?
>
> create table t1(a blob);
> insert into  t1 values(readfile('binfile'));
> select * from t1;
>
> I always see text and I expect to see one of the following cases:
> 1. a hex sequence regardless of file type
> 2. text (if the file was text), or a hex sequence if it was binary.
>
> Instead, I see text when dealing with text files, and truncated text (up
> to the first zero) when dealing with binary.
>
> Am I misusing it?
>

To see hex output, use

SELECT quote(a) FROM t1;

The shell always prints BLOBs as just the bytes within the blob, not
translated to hex.  It has always done this.  For 14 years.  Example:

CREATE TABLE t1(a BLOB);
INSERT INTO t1(a) VALUES(x'78797a7a79');
SELECT a FROM t1;

The above prints: xyzzy



-- 
D. Richard Hipp
d...@sqlite.org
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite version 3.8.6 coming soon

[Tony Papadimitriou]

Unless I'm misusing it, I believe the shell readfile() function reads a file 
as text, not binary.  I haven't checked writefile() for the same problem on 
writing.


This is how I use it, is this not correct?

create table t1(a blob);
insert into  t1 values(readfile('binfile'));
select * from t1;

I always see text and I expect to see one of the following cases:
1. a hex sequence regardless of file type
2. text (if the file was text), or a hex sequence if it was binary.

Instead, I see text when dealing with text files, and truncated text (up to 
the first zero) when dealing with binary.


Am I misusing it?

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite version 3.8.6 coming soon

[Andy Ling]

> -Original Message-
> From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users-
> boun...@sqlite.org] On Behalf Of Richard Hipp
> Sent: 06 August 2014 01:58
> To: General Discussion of SQLite Database; sqlite-dev
> Subject: [sqlite] SQLite version 3.8.6 coming soon
> 
> Version 3.8.6 was originally scheduled for September.  But the change log (
> http://www.sqlite.org/draft/releaselog/current.html) is getting rather long
> and there are a number of important bug fixes.  So we might try to get
> 3.8.6 out the door sooner rather than later.
> 
> Please test!  Recent amalgamations are available on the download page (
> http://www.sqlite.org/download.html).  Please compile your applications
> use
> the latest tip of trunk and let us know if you encounter any problems.
> 

The amalgamation I've just downloaded (201408060029) doesn't appear to have the 
changes
I did with Jan to make it compile under vxWorks.

Regards

Andy Ling

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] [sqlite-dev] SQLite version 3.8.6 coming soon

[Bert Huijben]

"Richard Hipp" wrote...

> Version 3.8.6 was originally scheduled for September.  But the change log 
> (
> http://www.sqlite.org/draft/releaselog/current.html) is getting rather 
> long
> and there are a number of important bug fixes.  So we might try to get
> 3.8.6 out the door sooner rather than later.
>
> Please test!  Recent amalgamations are available on the download page (
> http://www.sqlite.org/download.html).  Please compile your applications 
> use
> the latest tip of trunk and let us know if you encounter any problems.
>
> Please review the change log and speak up if you see anything amiss.
>
> The status board (http://www.sqlite.org/checklists/3080600/index) for the
> 3.8.6 release is now on-line.  The usual rule applies:  When the 
> check-list
> goes all-green, we will cut the release.  No check-list items have been
> marked off yet, but we might start marking them off later this week, or
> early next week.
>
> Your feedback is greatly appreciated.

The new wrapping of InterlockedCompareExchange introduced in 3.8.6 breaks 
compilation in Visual C++ 2013 (and the "14" CTPs) for X86 and X64, as this 
function is implemented as an intrinsic in these compilers.

When linking the amalgamation to a program I get a linker error:
sqlite3.lib(sqlite3.obj) : error LNK2001: unresolved external symbol 
__InterlockedCompareExchange

In the newer SDK versions used by this compiler there is a:
#define InterlockedCompareExchange  _InterlockedCompareExchange
(via winbase.h)

Which triggers the use of the intrinsic. (Older versions of the compiler appear 
to have the intrinsic, but by default their SDKs don't use it)


As I assume this is required for the testing framework, an easy fix might be to 
just undefine 'InterlockedCompareExchange'.
(I haven't tested this myself yet)

Bert

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite version 3.8.6 coming soon

[tonyp]

src/func.c: The comment on top refers to sqliteRegisterBuildinFunctions() 
but the actual call seems to have been renamed to 
sqliteRegisterGlobalFunctions()


___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite version 3.8.6 coming soon

[Dominique Devienne]

On Wed, Aug 6, 2014 at 2:57 AM, Richard Hipp  wrote:
>
> Please review the change log and speak up if you see anything amiss.

The new doc mentioned by http://www.sqlite.org/draft/lang_expr.html#hexint
may have a 1-char typo:

However, for backwards compatibility, the "Ox" hexadecimal integer
notation

notice the "Ox" (capital letter o), instead of "0x" (zero digit). Confused
me on the first read. Hope this helps. --DD

PS: backward compatibility, no s, no?
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users