Re: [sqlite] fixing time-warp

[Stephan Beal]

On Wed, Nov 5, 2014 at 7:07 AM, E. Timothy Uy  wrote:

> The problem is ultimately not time-warps. DRH can confirm - the problem is
> actually inside fossil and sqlite.fossil. Very early on in sqlite.fossil
> there are entries in the plink table where the parent id (pid) is greater
> than the commit id (cid). There are over a thousand of these.


Those IDs are _transient_, not part of the historical record. The "child ID
comes before parent ID" behaviour also appears on completely benign repos
(i've seen it before in my own while testing libfossil).



> If I had more brain cells, I could perhaps invent a way to efficiently use
> the plink table to generate the proper export list where parents always
> come before children regardless of mtime.
>

i've also attempted something similar in libfossil, but haven't been
successful. The RIDs cannot be used to figure it out, and neither can
mtime. The only 100% reliable way i know of traversing the history is to
read each manifest, as the P-cards give us that piece of context we need to
know the ordering.

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

[sqlite] ANN: SQLite PHP Generator 14.10 released

[SQL Maestro Group]

Hi!

SQL Maestro Group announces the release of SQLite PHP Generator 14.10, a 
powerful GUI frontend for Windows that allows you to generate feature-rich 
CRUD web applications for your SQLite database.

http://www.sqlmaestro.com/products/sqlite/phpgenerator/

Online demo:
http://demo.sqlmaestro.com/

SQLite PHP Generator comes in both Freeware and Professional editions. The 
feature matrix can be found at

http://www.sqlmaestro.com/products/sqlite/phpgenerator/feature_matrix/

Top 10 new features:


1. New and updated controls.
2. Enhanced JavaScript API.
3. New security-related features.
4. Extended template management.
5. Multi-group menus.
6. New application-level events.
7. Custom CSS and JavaScript.
8. Usability improvements.
9. PHP Generator UI enhancements.
10. Support for PHP 5.6 and other core features.

Full press-release is available at:
http://www.sqlmaestro.com/news/company/php_generators_advanced_to_version_14_10/

Background information:
---
SQL Maestro Group offers complete database admin, development and management 
tools for MySQL, SQL Server, PostgreSQL, Oracle, DB2, SQLite, SQL Anywhere, 
Firebird and MaxDB providing the highest performance, scalability and 
reliability to meet the requirements of today's database applications.


Sincerely yours,
The SQL Maestro Group Team
http://www.sqlmaestro.com 


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

Re: [sqlite] fixing time-warp

[E. Timothy Uy]

As I walked away to do the dishes, these verses from Matthew suddenly came
to mind:

The LORD said unto my Lord, Sit thou on my right hand, till I make thine
> enemies thy footstool? If David then call him Lord, how is he his son?


I think I'll just be quiet now.

Blessings,
Tim

On Tue, Nov 4, 2014 at 10:07 PM, E. Timothy Uy  wrote:

> I am not behind http://repo.or.cz/w/sqlite.git - though Kyle (the one
> behind it) has some good ideas that would be nice to get into fossil. But
> he doesn't care to try to get them into fossil. I do. Please don't
> misinterpret the answers below as any kind of disrespect for DRH, SQLite or
> fossil - they are all held in high regard.
>
>
>> 1. Why is it a good idea for you, E. Timothy Uy, to dump the SQLite code
>> repo into a Git repo?  What does this achieve, that keeping it in Fossil
>> does not?
>>
>
> Like fossil, I use SQLite code as part of a larger project. This larger
> project is using Git. I would like to reference all third-party code as Git
> submodules - this is already done for components that are SVN-based.
> Previously I had an untracked folder holding fossil repositories and I
> briefly considered some kind of macro or script to fossil clone - but I
> like how Git submodules also keep track of the particular commit that is
> used by the master repo.
>
>
>> 2. Why is it a good idea for our BDFL, D. Richard Hipp, to modify the
>> SQLite repo to make it easier for you to dump it into a Git repo?  Keep in
>> mind that the costs here are not just his time, but also the loss of a test
>> case.
>
>
> I don't think DRH needs modify the repo to make it easier to help _me_
> dump it into a Git repo. In fact, (see #3), I no longer think the
> time-warps should be fixed at all.
>
> However, I do want to point out that
>
> 1. There are two existing tags that fix the two time-warps. However, these
> have been un-fixed without deleting the fixing tags. This is confusing.
> Maybe the tags should be deleted? Or maybe there are two more tags
> somewhere that unfix the fixes?
>
> b. SQLite is the crown jewel example of the beauty of fossil. Fossil
> offers "fossil export --git repo.fossil | git fast-import". Why should this
> break for SQLite? It shouldn't.
>
> c. It is a matter of perception. If SQLite is good example of fossil,
> putting your code into fossil means never getting it out again. That is
> scary.
>
> I don’t think you can convince anyone that #2 is a good idea, but I’m
>> curious about why #1 is a good idea.
>>
>> Bonus persuasion point 3: Why not persuade the Git people to modify their
>> tool to cope with time warps?  Isn’t their major value proposition w.r.t
>> the other open source DVCSes that Git is more powerful and flexible?  Here
>> we see Fossil doing something Git cannot or will not do, and it’s not a
>> matter of mission scope, as with the bug tracker or wiki features of Fossil.
>
>
> The problem is ultimately not time-warps. DRH can confirm - the problem is
> actually inside fossil and sqlite.fossil. Very early on in sqlite.fossil
> there are entries in the plink table where the parent id (pid) is greater
> than the commit id (cid). There are over a thousand of these. I suspect
> that because of this, the --git export function sorts the commits by mtime
> instead of by objid. But ideally the export function should sort by objid
> with pid always less than cid. When sorting by mtime, time-warps cause the
> scenario where a commit is exported which refers to a parent which has not
> been mentioned. This is what causes the Git fast-import function to choke.
> The interim fix is to use a tag to change the time, then export.
>
> If I had more brain cells, I could perhaps invent a way to efficiently use
> the plink table to generate the proper export list where parents always
> come before children regardless of mtime.
>
> Respectfully,
> Tim
>
>
>
>
>
>
>
>
>
>
>
>> ___
>> 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] fixing time-warp

[E. Timothy Uy]

I am not behind http://repo.or.cz/w/sqlite.git - though Kyle (the one
behind it) has some good ideas that would be nice to get into fossil. But
he doesn't care to try to get them into fossil. I do. Please don't
misinterpret the answers below as any kind of disrespect for DRH, SQLite or
fossil - they are all held in high regard.


> 1. Why is it a good idea for you, E. Timothy Uy, to dump the SQLite code
> repo into a Git repo?  What does this achieve, that keeping it in Fossil
> does not?
>

Like fossil, I use SQLite code as part of a larger project. This larger
project is using Git. I would like to reference all third-party code as Git
submodules - this is already done for components that are SVN-based.
Previously I had an untracked folder holding fossil repositories and I
briefly considered some kind of macro or script to fossil clone - but I
like how Git submodules also keep track of the particular commit that is
used by the master repo.


> 2. Why is it a good idea for our BDFL, D. Richard Hipp, to modify the
> SQLite repo to make it easier for you to dump it into a Git repo?  Keep in
> mind that the costs here are not just his time, but also the loss of a test
> case.


I don't think DRH needs modify the repo to make it easier to help _me_ dump
it into a Git repo. In fact, (see #3), I no longer think the time-warps
should be fixed at all.

However, I do want to point out that

1. There are two existing tags that fix the two time-warps. However, these
have been un-fixed without deleting the fixing tags. This is confusing.
Maybe the tags should be deleted? Or maybe there are two more tags
somewhere that unfix the fixes?

b. SQLite is the crown jewel example of the beauty of fossil. Fossil offers
"fossil export --git repo.fossil | git fast-import". Why should this break
for SQLite? It shouldn't.

c. It is a matter of perception. If SQLite is good example of fossil,
putting your code into fossil means never getting it out again. That is
scary.

I don’t think you can convince anyone that #2 is a good idea, but I’m
> curious about why #1 is a good idea.
>
> Bonus persuasion point 3: Why not persuade the Git people to modify their
> tool to cope with time warps?  Isn’t their major value proposition w.r.t
> the other open source DVCSes that Git is more powerful and flexible?  Here
> we see Fossil doing something Git cannot or will not do, and it’s not a
> matter of mission scope, as with the bug tracker or wiki features of Fossil.


The problem is ultimately not time-warps. DRH can confirm - the problem is
actually inside fossil and sqlite.fossil. Very early on in sqlite.fossil
there are entries in the plink table where the parent id (pid) is greater
than the commit id (cid). There are over a thousand of these. I suspect
that because of this, the --git export function sorts the commits by mtime
instead of by objid. But ideally the export function should sort by objid
with pid always less than cid. When sorting by mtime, time-warps cause the
scenario where a commit is exported which refers to a parent which has not
been mentioned. This is what causes the Git fast-import function to choke.
The interim fix is to use a tag to change the time, then export.

If I had more brain cells, I could perhaps invent a way to efficiently use
the plink table to generate the proper export list where parents always
come before children regardless of mtime.

Respectfully,
Tim











> ___
> 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] fixing time-warp

[Richard Hipp]

Maybe E. Timothy Uy is the person behind http://repo.or.cz/w/sqlite.git ?

On Tue, Nov 4, 2014 at 7:15 PM, Warren Young  wrote:

> On Nov 3, 2014, at 7:01 PM, E. Timothy Uy  wrote:
>
> > Is that a philosophical question? :)
>
> No, it’s a persuasion challenge.
>
> I’ll propose it in two parts:
>
> 1. Why is it a good idea for you, E. Timothy Uy, to dump the SQLite code
> repo into a Git repo?  What does this achieve, that keeping it in Fossil
> does not?
>
> 2. Why is it a good idea for our BDFL, D. Richard Hipp, to modify the
> SQLite repo to make it easier for you to dump it into a Git repo?  Keep in
> mind that the costs here are not just his time, but also the loss of a test
> case.
>
> I don’t think you can convince anyone that #2 is a good idea, but I’m
> curious about why #1 is a good idea.
>
> Bonus persuasion point 3: Why not persuade the Git people to modify their
> tool to cope with time warps?  Isn’t their major value proposition w.r.t
> the other open source DVCSes that Git is more powerful and flexible?  Here
> we see Fossil doing something Git cannot or will not do, and it’s not a
> matter of mission scope, as with the bug tracker or wiki features of Fossil.
> ___
> 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] x64 vs x32 DLL

[Warren Young]

On Nov 4, 2014, at 5:25 PM, Keith Medcalf  wrote:

> Assuming that you do rebuild the entire application as 64-bit, it will 
> consume at least twice the amount of memory as the x86 version and run slower 
> in user code.

[citation needed]

On 32-bit Cygwin:

$ ls -lh `which sqlite3`
-rwxrwxr-x 1 Warren None 66K Nov  4 03:00 /usr/bin/sqlite3

And on 64-bit Cygwin:

$ ls -lh `which sqlite3`
-rwxrwxr-x 1 Warren None 65K Nov  4 01:16 /usr/bin/sqlite3

I know you said “memory” and not “disk space,” but part of memory use is the 
size of the code loaded.

Run time RAM use also shows no significant difference for the two versions of 
sqlite3.exe on Cygwin.  If I say `sqlite3 nonexistent.db`, Windows Task Manager 
reports the same RAM usage (0.9 MB) on my machine for both executables.

I then loaded up a 284 MB DB instead of the empty one.  Initially, both builds 
of sqlite3.exe consumed about the same amount of RAM.  After a few big SELECT 
calls, the 64-bit one was using 3.4 MB of RAM, while the 32-bit one was a bit 
slimmer, at 3.2 MB, a difference of only 6-8%, depending on whether you factor 
out the 0.9 MB constant or not.

Note that the on-disk usage difference for the DB is always 0%, since SQLite’s 
DB format is platform-independent.  That means the explanation for the RAM size 
difference probably comes down entirely to pointer size differences, which is 
swamped by the size of the actual data being managed.

It’s also debatable whether the user space code will run slower.  Every 
benchmark I’ve seen puts the difference down in the single-digit range, with 
the 64-bit code sometimes being the faster version.

(64-bit code is sometimes a bit faster despite the single-digit percentage RAM 
hit because you don’t have to go through the WOW64 layer, the compiler can use 
wider data transfer instructions in some cases, etc.)

You can wipe these tiny differences away by waiting for a few weeks’ worth of 
Moore’s Law improvements.

> ...open to kernel mode code injection exploits when running x64 applications, 
> just like x86 applications on x86 kernels are open to such exploits, because 
> the kernel is mapped into the process address space.  Such injection exploits 
> against x64 kernel code and processes being impossible from an x86 process.

If you’re trying to protect against that, you should probably just be running 
your programs in a restricted VM, rather than depend on the WOW64 compatibility 
layer to break the exploit code.

You’ve also left an implication here, that 32-on-32 and 64-on-64 have the same 
level risk.  The 64-bit Windows kernel is a fair bit more secure than the 
32-bit one, if only because Microsoft was finally able to remove some 
long-deprecated exploit paths.

> Unless there is a specific reason for converting the entire application to 
> x64 (such as a requirement to access more than 3.9 GB of per-process memory) 
> or to take advantage of other specific architectural differences (which are 
> almost all entirely dependent on the compiler you choose) there is no 
> advantage to x64 applications over x86 applications on an x64 Operating 
> System.

This is all true, as far as it goes.  Security, speed, and RAM usage just 
aren’t good justifications.

Want a good justification?  Opportunity cost.  Effort *not* spent converting is 
effort you can spend on something that gets you a benefit you *will* notice.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] x64 vs x32 DLL

[Keith Medcalf]

On Tuesday, 4 November, 2014 12:35, jose isaias cabrera 
 asked:

>I have an application that is written for x32 machines.  However, we now
>have a few machines that are x64 and all is well when we are using the
>precompiled x32 DLLs provided by http://www.sqlite.org/download.html.
>Changing the x32 DLLs to x64 DLLs, will it show any difference in speed
>on the x64 machines?  Thanks.

You did not specify the Operating System.  Very Few Operating Systems support 
intra-process thunking between x86 and x64 code segments.  This means that in 
order to use the x64 load library, your entire application will have to be 
re-compiled as x64.  Since you refer specifically to DLLs, one would assume you 
are speaking of Windows as the Operating System.

Assuming that you do rebuild the entire application as 64-bit, it will consume 
at least twice the amount of memory as the x86 version and run slower in user 
code.  Calling into kernel space will be slightly quicker because the x64 
kernel space is a DCSS (like the x86 kernel) which can be called directly, 
versus using the system trampoline and thunk code used to run x86 applications 
under an x64 version of Windows.  The application and operating system (and its 
services) will be open to kernel mode code injection exploits when running x64 
applications, just like x86 applications on x86 kernels are open to such 
exploits, because the kernel is mapped into the process address space.  Such 
injection exploits against x64 kernel code and processes being impossible from 
an x86 process.

Unless there is a specific reason for converting the entire application to x64 
(such as a requirement to access more than 3.9 GB of per-process memory) or to 
take advantage of other specific architectural differences (which are almost 
all entirely dependent on the compiler you choose) there is no advantage to x64 
applications over x86 applications on an x64 Operating System.  In truth, there 
may be significant reasons why it is preferred to keep an x86 userland, 
especially on Windows.

---
Theory is when you know everything but nothing works.  Practice is when 
everything works but no one knows why.  Sometimes theory and practice are 
combined:  nothing works and no one knows why.




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

Re: [sqlite] fixing time-warp

[Warren Young]

On Nov 3, 2014, at 7:01 PM, E. Timothy Uy  wrote:

> Is that a philosophical question? :)

No, it’s a persuasion challenge.

I’ll propose it in two parts:

1. Why is it a good idea for you, E. Timothy Uy, to dump the SQLite code repo 
into a Git repo?  What does this achieve, that keeping it in Fossil does not?

2. Why is it a good idea for our BDFL, D. Richard Hipp, to modify the SQLite 
repo to make it easier for you to dump it into a Git repo?  Keep in mind that 
the costs here are not just his time, but also the loss of a test case.

I don’t think you can convince anyone that #2 is a good idea, but I’m curious 
about why #1 is a good idea.

Bonus persuasion point 3: Why not persuade the Git people to modify their tool 
to cope with time warps?  Isn’t their major value proposition w.r.t the other 
open source DVCSes that Git is more powerful and flexible?  Here we see Fossil 
doing something Git cannot or will not do, and it’s not a matter of mission 
scope, as with the bug tracker or wiki features of Fossil.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] How to check if a record exists

[James K. Lowden]

On Tue, 4 Nov 2014 21:47:20 +
"Drago, William @ CSG - NARDAEAST"  wrote:

> I've been pulling my hair out trying to figure how to use EXISTS.

I have several examples at
http://www.schemamania.org/sql/#missing.table.  

> Is there a better/recommended way in SQLite to check if a record
> exists?
> 
> static bool IDisDuplicate(string dbFileName, int id)

Yes.  Assert, don't check!  

Your function is checking for duplicates.  I could be wrong of course,
but I suspect that you're checking for duplicates to do something about
it in the database.  If so, between the time you check and the time you
"do something" that duplicate could have gone away and another arisen.
Cache coherency folks call that a write-after-read error.  

The way to avoid that is to put everything on the broad shoulders of
SQLite, viz, 

insert/update/delete T as t
-- ... --
where exists ( 
select 1 from T
where something = t.something
group by something
having count(*) > 1 
);

HTH.  Exists is confusing at first, and consequently
under-appreciated.  

(BTW, I dis duplicates, too.  Despise them, in fact.) 

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

Re: [sqlite] How to check if a record exists

[Igor Tandetnik]

On 11/4/2014 4:47 PM, Drago, William @ CSG - NARDAEAST wrote:

 "SELECT count(1) DatasetID FROM UUT_Info where DatasetID = " + 
id + ";";


You could do

select exists (select 1 from UUT_Info where DatasetID = :id);

This returns 0 or 1 (record absent/present). May work faster than the 
variant using count() if there are many records satisfying the condition 
(EXISTS stops as soon as it finds the first matching record), but that 
may not be a consideration in your case (DatasetID sounds like primary key).

--
Igor Tandetnik

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

Re: [sqlite] x64 vs x32 DLL

[James K. Lowden]

On Tue, 04 Nov 2014 22:20:23 +0200
RSmith  wrote:

> The best way to think of the 64 bit upgrade in normal programming is:
> "Able to do larger accuracy calculations at more or less the same
> speed".

Eh, more accurate how?  Every 32-architecture I compiled for supported
64-bit long integers.  Floating point is unchanged.  

The change is bigger address space, and consequently somewhat larger
and slower code.  "Able to address more memory" [virtual or real] is
how I'd put it.  

That makes some problems feasible that formerly were not.  And I'm not
so sure such problems are rare.  I remember when allocation 1 GB of
memory (virtual or not) was pure fantasy.  Nowadays laptops with 8 GB
of RAM are pretty pedestrian.  

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

Re: [sqlite] How to check if a record exists

[Darren Duncan]

If all you want to know is whether a record matching a particular field value 
exists, then what you did is appropriate.  The EXISTS construct is generally for 
filtering one table with another.  That being said, you should be using bind 
parameters rather than stitching id into the SQL string itself, as that practice 
generally leads to huge security problems / SQL injection (although if your 
language is strongly typed an int wouldn't do it, but a string would). -- Darren 
Duncan


On 2014-11-04 1:47 PM, Drago, William @ CSG - NARDAEAST wrote:

All,

I've been pulling my hair out trying to figure how to use EXISTS. I've had no 
luck with it (syntax errors) and I've resorted to this. Is there a 
better/recommended way in SQLite to check if a record exists?


static bool IDisDuplicate(string dbFileName, int id)
 {
 int count;
 string connectionString = String.Format("Data Source={0}", 
dbFileName);
 using (SQLiteConnection connection = new 
SQLiteConnection(connectionString))
 {
 using (SQLiteCommand command = connection.CreateCommand())
 {
 connection.Open();
 command.CommandText =
 "SELECT count(1) DatasetID FROM UUT_Info where DatasetID = " + 
id + ";";
 count = Convert.ToInt32(command.ExecuteScalar());
 }
 }

 if (count > 0)
 {
 return true;
 }
 else
 {
 return false;
 }
 }


Thanks,
--
Bill Drago
Senior Engineer
L3 Communications / Narda Microwave East
435 Moreland Road
Hauppauge, NY 11788
631-272-5947 / william.dr...@l-3com.com


CONFIDENTIALITY, EXPORT CONTROL AND DISCLAIMER NOTE:This e-mail and any 
attachments are solely for the use of the addressee and may contain information 
that is privileged or confidential. Any disclosure, use or distribution of the 
information contained herein is prohibited. In the event this e-mail contains 
technical data within the definition of the International Traffic in Arms 
Regulations or Export Administration Regulations, it is subject to the export 
control laws of the U.S.Government. The recipient should check this e-mail and 
any attachments for the presence of viruses as L-3 does not accept any 
liability associated with the transmission of this e-mail. If you have received 
this communication in error, please notify the sender by reply e-mail and 
immediately delete this message and any attachments.
___
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] How to check if a record exists

[Drago, William @ CSG - NARDAEAST]

All,

I've been pulling my hair out trying to figure how to use EXISTS. I've had no 
luck with it (syntax errors) and I've resorted to this. Is there a 
better/recommended way in SQLite to check if a record exists?


static bool IDisDuplicate(string dbFileName, int id)
{
int count;
string connectionString = String.Format("Data Source={0}", 
dbFileName);
using (SQLiteConnection connection = new 
SQLiteConnection(connectionString))
{
using (SQLiteCommand command = connection.CreateCommand())
{
connection.Open();
command.CommandText =
"SELECT count(1) DatasetID FROM UUT_Info where 
DatasetID = " + id + ";";
count = Convert.ToInt32(command.ExecuteScalar());
}
}

if (count > 0)
{
return true;
}
else
{
return false;
}
}


Thanks,
--
Bill Drago
Senior Engineer
L3 Communications / Narda Microwave East
435 Moreland Road
Hauppauge, NY 11788
631-272-5947 / william.dr...@l-3com.com


CONFIDENTIALITY, EXPORT CONTROL AND DISCLAIMER NOTE:This e-mail and any 
attachments are solely for the use of the addressee and may contain information 
that is privileged or confidential. Any disclosure, use or distribution of the 
information contained herein is prohibited. In the event this e-mail contains 
technical data within the definition of the International Traffic in Arms 
Regulations or Export Administration Regulations, it is subject to the export 
control laws of the U.S.Government. The recipient should check this e-mail and 
any attachments for the presence of viruses as L-3 does not accept any 
liability associated with the transmission of this e-mail. If you have received 
this communication in error, please notify the sender by reply e-mail and 
immediately delete this message and any attachments.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] x64 vs x32 DLL

[David Woodhouse]

>
> On 2014/11/04 21:34, jose isaias cabrera wrote:
>> Greetings!
>>
>> I have an application that is written for x32 machines.  However, we now
>> have a few machines that are x64 and all is well when we are using the
>> precompiled x32 DLLs provided by http://www.sqlite.org/download.html.
>> Changing the x32 DLLs to x64 DLLs, will it show any difference in speed
>> on the x64 machines?  Thanks.
>
> Yeah, might even be slower, but so negligibly that you won't notice.
>
> Important to note (which many people seem to miss) is that the step up
> from 32 to 64 bit computing is an increase in computing
> accuracy and capacity, not in speed, though computations on historic 64
> bit variables (which used to be split up into two or more
> values to work) might be faster, but they generally make up less than 1%
> of the computations in any sane software system (though
> exceptions do exist) and so the speed increase is usually miniscule.  On
> the downside, a 64-bit system uses 64 bit values for all
> registers even where 32-bit values could have sufficed, and so all
> internal looping through bits or register shifts take longer, but
> generally by negligible amounts. (All modern processors are 64 bit anyway
> - 32 bit OSes still exist for legacy reasons only).
>
> It isn't a magic boost - The best way to think of the 64 bit upgrade in
> normal programming is: "Able to do larger accuracy
> calculations at more or less the same speed".


However, the switch from i386 to x86_64 isn't *just* a switch from 32-bit
to 64-bit like ppc32/ppc64 is. It *also* gives you a bunch more registers,
which certainly can make things significantly faster.

If you are looking at precompiled binaries then compatibility issues also
might be relevant. Code built for i386 might literally be compatible with
the 80386, using *no* new instructions added since then. Even if it
doesn't go that far but only supports i586, that still precludes some
important instructions like cmov.

Code built for x86_64, on the other hand, will have a 'lowest common
denominator' CPU feature set which is distinctly more modern. And which
even includes SSE2. So it might be faster for that reason too.

-- 
dwmw2

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

Re: [sqlite] x64 vs x32 DLL

[jose isaias cabrera]

"Stephan Beal" wrote...


On Tue, Nov 4, 2014 at 9:20 PM, RSmith  wrote:


miniscule.  On the downside, a 64-bit system uses 64 bit values for all
registers even where 32-bit values could have sufficed, and so all 
internal

looping through bits or register shifts take longer, but generally by
negligible amounts.



To add to that: the doubling of the size of a (void*) in 64-bit costs many
types of applications/libraries notably more memory, up to twice as much
for pointer-only structures.


Thank you both.  As we say in the beautiful Spanish language: muchas 
gracias.


josé 


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

Re: [sqlite] x64 vs x32 DLL

[Stephan Beal]

On Tue, Nov 4, 2014 at 9:20 PM, RSmith  wrote:

> miniscule.  On the downside, a 64-bit system uses 64 bit values for all
> registers even where 32-bit values could have sufficed, and so all internal
> looping through bits or register shifts take longer, but generally by
> negligible amounts.
>

To add to that: the doubling of the size of a (void*) in 64-bit costs many
types of applications/libraries notably more memory, up to twice as much
for pointer-only structures.

-- 
- 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] x64 vs x32 DLL

[RSmith]

On 2014/11/04 21:34, jose isaias cabrera wrote:

Greetings!

I have an application that is written for x32 machines.  However, we now have a 
few machines that are x64 and all is well when we are using the precompiled x32 
DLLs provided by http://www.sqlite.org/download.html.  Changing the x32 DLLs to 
x64 DLLs, will it show any difference in speed on the x64 machines?  Thanks.


Yeah, might even be slower, but so negligibly that you won't notice.

Important to note (which many people seem to miss) is that the step up from 32 to 64 bit computing is an increase in computing 
accuracy and capacity, not in speed, though computations on historic 64 bit variables (which used to be split up into two or more 
values to work) might be faster, but they generally make up less than 1% of the computations in any sane software system (though 
exceptions do exist) and so the speed increase is usually miniscule.  On the downside, a 64-bit system uses 64 bit values for all 
registers even where 32-bit values could have sufficed, and so all internal looping through bits or register shifts take longer, but 
generally by negligible amounts. (All modern processors are 64 bit anyway - 32 bit OSes still exist for legacy reasons only).


It isn't a magic boost - The best way to think of the 64 bit upgrade in normal programming is: "Able to do larger accuracy 
calculations at more or less the same speed".



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

[sqlite] x64 vs x32 DLL

[jose isaias cabrera]

Greetings!

I have an application that is written for x32 machines.  However, we now have a 
few machines that are x64 and all is well when we are using the precompiled x32 
DLLs provided by http://www.sqlite.org/download.html.  Changing the x32 DLLs to 
x64 DLLs, will it show any difference in speed on the x64 machines?  Thanks.

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

Re: [sqlite] Random locking errors using Sqlite.NET

[Mike King]

Are you accessing data off the share as well? The Sqlite website is quite
categoric that this is not a recommended mode of operation. Also given the
database locks when a record is written it is entirely possible one user is
locking the table.

Cheers,
Mike

On Tuesday, 4 November 2014, Mike McWhinney  wrote:

> Hello,
>
> I continue to have random errors on SQLite.NET (ADO provider).  I have the
> version 3.8.6 (System.Data.SQLite.dll with version 1.0.94.0).
>
> I am getting random locking errors during the execution of my program. The
> program resides on a network and each client has a mapped share
> with full read/write access to the folder as well as the .db file used by
> SQLite.
>
> In my connection string I have the following:
>
> public static string OMconnectionString = "URI=file:oslermedicine.db;
> Default Timeout=10; Pooling=True; Max Pool Size=100;";
>
>
>
> What might I be doing wrong? I am disposing of all objects (data readers,
> tables, commands) after use.
>
> Thanks
> Mike
> ___
> 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] Random locking errors using Sqlite.NET

[Simon Slavin]

On 4 Nov 2014, at 5:45pm, Mike McWhinney  wrote:

> I am getting random locking errors during the execution of my program. The 
> program resides on a network and each client has a mapped share
> with full read/write access to the folder as well as the .db file used by 
> SQLite.

I don't know if this is what's causing your specific problem, but ...



"SQLite will work over a network filesystem, but because of the latency 
associated with most network filesystems, performance will not be great. Also, 
the file locking logic of many network filesystems implementation contains bugs 
(on both Unix and Windows). If file locking does not work like it should, it 
might be possible for two or more client programs to modify the same part of 
the same database at the same time, resulting in database corruption. Because 
this problem results from bugs in the underlying filesystem implementation, 
there is nothing SQLite can do to prevent it.

A good rule of thumb is that you should avoid using SQLite in situations where 
the same database will be accessed simultaneously from many computers over a 
network filesystem."

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

[sqlite] Random locking errors using Sqlite.NET

[Mike McWhinney]

Hello,

I continue to have random errors on SQLite.NET (ADO provider).  I have the 
version 3.8.6 (System.Data.SQLite.dll with version 1.0.94.0).

I am getting random locking errors during the execution of my program. The 
program resides on a network and each client has a mapped share
with full read/write access to the folder as well as the .db file used by 
SQLite.

In my connection string I have the following:

public static string OMconnectionString = "URI=file:oslermedicine.db; Default 
Timeout=10; Pooling=True; Max Pool Size=100;";
   


What might I be doing wrong? I am disposing of all objects (data readers, 
tables, commands) after use.

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

Re: [sqlite] sqlite3.8.7 crashes when creating an index with WAL mode disabled

[James K. Lowden]

On Tue, 4 Nov 2014 12:06:35 +
Simon Davies  wrote:

> > And watch as it crashes when creating the index.
> 
> From https://www.sqlite.org/compile.html:
> 
> Important Note: The SQLITE_OMIT_* options do not work with the
> amalgamation or with pre-packaged C code files. SQLITE_OMIT_*
> compile-time options only work correctly when SQLite is built from
> canonical source files.

Perhaps this could be caught at compile time.  The process that creates
the amalgamation could add a preprocessor macro defining e.g.
_SQLITE_AMALGAMATION_.  The SQLITE_OMIT_* macros could test for that
definition and #pragma error if found.  

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

Re: [sqlite] sqlite3.8.7 crashes when creating an index with WAL mode disabled

[Simon Davies]

On 4 November 2014 04:17, RP McMurphy  wrote:
> Consider the following build cmd line:
>
> gcc -o sqlite3.exe -DSQLITE_OMIT_WAL sqlite3.c shell.c
>
> The build succeeds when using MinGW on Windows.
>
> Now start the built exe with a memory database:
>
> sqlite3 :memory:
>
> And execute the following query:
>
> create table v(y);
> with recursive cnt(x) as (select 1 union all select x+1 from cnt 
> limit 10)
> insert into v select * from cnt;
> create index w on v(y);
>
> And watch as it crashes when creating the index.

>From https://www.sqlite.org/compile.html:

Important Note: The SQLITE_OMIT_* options do not work with the
amalgamation or with pre-packaged C code files. SQLITE_OMIT_*
compile-time options only work correctly when SQLite is built from
canonical source files.

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

[sqlite] sqlite3.8.7 crashes when creating an index with WAL mode disabled

[RP McMurphy]

Consider the following build cmd line:

gcc -o sqlite3.exe -DSQLITE_OMIT_WAL sqlite3.c shell.c

The build succeeds when using MinGW on Windows.

Now start the built exe with a memory database:

sqlite3 :memory:

And execute the following query:

create table v(y);
with recursive cnt(x) as (select 1 union all select x+1 from cnt limit 
10)
insert into v select * from cnt;
create index w on v(y);

And watch as it crashes when creating the index.

I tracked the problem down to the following missing library bindings:

CreateFileMappingA
CreateFileMappingW
MapViewOfFile
UnmapViewOfFile

All four of those library bindings are disabled by the existence of 
SQLITE_OMIT_WAL. sqlite tries to execute code at address 0 when the table to 
larger than some value. If I use 96255 instead of 10 in the above query 
there is no crash. And increasing by one to 96256 the crash occurs.

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

Re: [sqlite] sqlite_column_table_name() and table alias name

[Jose F. Gimenez]

Hi,

any chance that this or a similar sqlite3_column_table_alias_name() were 
added to SQLite?


TIA,
Jose F. Gimenez
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Index without backing table

[Paul]

> On Mon, 03 Nov 2014 11:50:17 +0200
> Paul  wrote:
> 
> > > > Would be nice to have ability to store both key and payload in the
> > > > index. (Let's call it index-only table)
> > > > This could be a feature that sets some limitations on a table,
> > > > like being unable to have more than one index or inefficient
> > > > table scans, but it will also give some advantage in special
> > > > cases like mine.
> > > 
> > > What you're describing sounds very much to me like a SQLite table.
> > > See http://www.sqlite.org/fileformat2.html, section 1.5, the
> > > reference to "index b-tree". 
> > 
> > So, to be clear, WITHOUT ROWID table will have it's PRIMARY KEY 
> > as a replacement for ROWID and table itself is an index?
> 
> Yes, approximately. http://www.sqlite.org/withoutrowid.html says: 
> 
> > CREATE TABLE IF NOT EXISTS wordcount(
> > word TEXT PRIMARY KEY,
> > cnt INTEGER
> > ) WITHOUT ROWID;
> > 
> > In this latter table, there is only a single B-Tree which uses the
> > "word" column as its key and the "cnt" column as its data. 
> 
> That is, the table is stored as a B-tree with the declared primary key
> as the B-tree key. 
> 
> I wouldn't say, "the table is an index". I reserve the word "index" in
> this sense to mean "something that speeds up searching in something
> else", and in this case there's no "else". 
> 
> The table is stored on disk as a tree. A tree can be used as an index,
> and an index may be implemented as a tree. But not every tree is an
> index. 
> 
> HTH. 
> 
> --jkl

Thank you for your answer, James! 

Regards,

Paul

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