heir conditions was met in
DEBUG-mode.
/Michael
From: Dennis Cote [mailto:[EMAIL PROTECTED]
Sent: Fri 2006-05-26 20:19
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] Possible bug in sqlite3_prepare
Michael B. Hansen wrote:
>
> Of course I suspe
Michael B. Hansen wrote:
Of course I suspected some error in my program - but there aren't any.
There aren't *ANY*.
I highly doubt that. :-) All programs of any significant size contain
errors.
I have run SQLite in both runtime and debug - and know that the
sqlite3_prepare has
-05-26 19:07
To: sqlite-users@sqlite.org
Subject: RE: [sqlite] Possible bug in sqlite3_prepare
Hi Joel,
I too have suspected Finisar.SQLite wrapper - and yes I have updated the SQLite
library to a newer version than the one Finisar.SQLite ships with.
However, I have dug pretty deep into the
:[EMAIL PROTECTED]
Sent: Fri 2006-05-26 17:42
To: sqlite-users@sqlite.org
Subject: RE: [sqlite] Possible bug in sqlite3_prepare
> - Original Message -
> From: "Michael B. Hansen" <[EMAIL PROTECTED]>
> To: <sqlite-users@sqlite.org>
> Sent: Friday, May 2
> - Original Message -
> From: "Michael B. Hansen" <[EMAIL PROTECTED]>
> To: <sqlite-users@sqlite.org>
> Sent: Friday, May 26, 2006 8:23 AM
> Subject: [sqlite] Possible bug in sqlite3_prepare
>
>
> Hi,
>
> For the last month I've
On 5/26/06, Michael B. Hansen <[EMAIL PROTECTED]> wrote:
This all works very well for some time - then suddenly after 250 - 1
calls to my function sqlite3_prepare returns "Object reference not set
to an instance of an object" - which is a .NET exception I interpretate
as a
Hi,
For the last month I've been troubled by an apparent bug in SQLite 3.3.5
which has been very hard to track down. After extensive debugging and
bug-tracking it seems there must be a bug/feature somewhere in SQLite -
propably in sqlite3_prepare because this is where the symptom of the bug
Thursday, May 11, 2006, 09:36:17, Preston & Chrystie wrote:
> if your first statement after creating the database is:
> PRAGMA encoding = "UTF-16";
> then the error you get is slightly different:
sqlite>> ALTER TABLE test1 ADD straße VARCHAR(255);
> SQL error: malformed database schema - near
ot a
developer at that level :(
Thanks,
Andreas
-Original Message-
From: Clay Dowling [mailto:[EMAIL PROTECTED]
Sent: Mittwoch, 10. Mai 2006 18:42
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] Possible bug with non-standard characters in column names
[EMAIL PROTECTED] said:
> CREAT
Not sure- I've tried this through JDBC and the command line client, I'm not a
developer at that level :(
Thanks,
Andreas
-Original Message-
From: Clay Dowling [mailto:[EMAIL PROTECTED]
Sent: Mittwoch, 10. Mai 2006 18:42
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] Possible bug
[EMAIL PROTECTED] said:
> CREATE TABLE test1 (loader_id INTEGER PRIMARY KEY, loader_status
> VARCHAR(255));
> ALTER TABLE test1 ADD name VARCHAR(255);
> ALTER TABLE test1 ADD straße VARCHAR(255);
> ALTER TABLE test1 ADD plz VARCHAR(255);
>
> Raises an SQL error: malformed database schema - near
Creating a table like this:
CREATE TABLE test1 (loader_id INTEGER PRIMARY KEY, loader_status VARCHAR(255));
ALTER TABLE test1 ADD name VARCHAR(255);
ALTER TABLE test1 ADD straße VARCHAR(255);
ALTER TABLE test1 ADD plz VARCHAR(255);
Raises an SQL error: malformed database schema - near "plz":
On Fri, 17 Feb 2006, DennisCote wrote:
Thomas Chust wrote:
[...]
I'm maintaining bindings to SQLite3 for the CHICKEN Scheme compiler /
interpreter and I got a bug report from a user about the following
problem: Creating a table with the
CREATE TABLE IF NOT EXISTS table_name(...);
Thomas Chust wrote:
Hello,
I'm maintaining bindings to SQLite3 for the CHICKEN Scheme compiler /
interpreter and I got a bug report from a user about the following
problem: Creating a table with the
CREATE TABLE IF NOT EXISTS table_name(...);
syntax or dropping a table with the
Hello,
I'm maintaining bindings to SQLite3 for the CHICKEN Scheme compiler /
interpreter and I got a bug report from a user about the following
problem: Creating a table with the
CREATE TABLE IF NOT EXISTS table_name(...);
syntax or dropping a table with the
DROP TABLE IF EXISTS
Thanks. Thats what I thought but wanted to be sure.
On Fri, 11 Nov 2005, Guillaume MAISON wrote:
Tenkawa a écrit :
Query 1 (correct behavior)
sqlite> select id,nick,last from nicks where nick = 'Nick';
sqlite>
Query 2 (incorrect?)
sqlite> select id,nick,last from nicks where nick =
Tenkawa a écrit :
Query 1 (correct behavior)
sqlite> select id,nick,last from nicks where nick = 'Nick';
sqlite>
Query 2 (incorrect?)
sqlite> select id,nick,last from nicks where nick = "Nick";
4|Her|99
5|Her|99
6|Her|99
7|Him|99
8|You|99
When dealing with STRING values, use only single
Is this a bug or something I'm missing with the logical handling of ''
versus ""
version 2.8.16 on Linux
schema
create table nicks (id integer primary key , nick TEXT, last integer(5));
Contents
sqlite> select * from nicks;
4|Her|99
5|Her|99
6|Her|99
7|Him|99
8|You|99
Query 1 (correct
L.S.
In order to wrap this up: apparently there's a feature / bug (choose one) in
any ARM core earlier than v5 due to which a float will be stored in big
endian quad order. The processor in this particular case is an SA1110, which
is default little endian while having a v4 core. (and thus
> Od: D. Richard Hipp [mailto:[EMAIL PROTECTED]
> Wysłano: 18 sierpnia 2005 20:11
> Do: sqlite-users@sqlite.org
> Temat: Re: [sqlite] Possible bug regarding endiannes and
> realstorageclass (sqlite3)
>
> On Thu, 2005-08-18 at 09:40 -0700, Robert Simpson wrote:
> >
On Thu, 2005-08-18 at 23:08 +0200, Frank van Vugt wrote:
> > Right. So for your ARM FP library, the code goes from
>
> Yep, will try that patch tomorrow morning, the soft-float cross-compiler
> should be ready then as well, so we'll see if that makes any difference as
> well.
The code shown
> Right. So for your ARM FP library, the code goes from
Yep, will try that patch tomorrow morning, the soft-float cross-compiler
should be ready then as well, so we'll see if that makes any difference as
well.
--
Best,
Frank.
Thursday, August 18, 2005, 3:18:56 PM, Frank wrote:
> I repeated the test using the value 1.2345678 in order to be
> able to identify the position of each byte:
> linux i386:
> 1bde8342cac0f33f
> 0100
> linux arm:
> cac0f33f1bde8342
> 0100
> So, it indeed looks like
I repeated the test using the value 1.2345678 in order to be able to identify
the position of each byte:
linux i386:
1bde8342cac0f33f
0100
linux arm:
cac0f33f1bde8342
0100
So, it indeed looks like 32bits based middle-endian or something
--
Best,
Frank.
sqlite-users@sqlite.org
> Subject: Re: [sqlite] Possible bug regarding endiannes and
> realstorageclass (sqlite3)
>
> On Thu, 2005-08-18 at 14:10 -0400, D. Richard Hipp wrote:
> > On Thu, 2005-08-18 at 09:40 -0700, Robert Simpson wrote:
> > > http://www.psc.edu/g
> ARM has at least two FL formats.
Yes, I'm currently rebuilding my crosscompiler with specific soft-float
options, but it'll take a while.
Also, it seems that apart from the endiannes of the processor, there's also
'endiannes of peripheral wiring', i.e. the way the memory is connected to the
See http://lists.debian.org/debian-arm/2003/10/msg00030.html
ARM has at least two FL formats.
> from the ARM Architecture Reference Manual, Page C2-4:
>
> "The word order [for DP format] defined here for the VFP architecture
> differs from that of the earlier FPA floating-point architecture. In
Richard,
As of interest, I've modified your code below and ran on two systems:
a) Sun Ultra-Enterprise SPARC (gcc)
b) Windows XP AMD (VS .NET 2003)
Code snippet:
union utest {
double r;
long long i;
unsigned char z[8];
};
float test_2;
int main(int argc, char **argv){
union utest x;
Hi,
> My test code is below. Please run this on your ARM and let
> me know what you get.
# ./test
f03f
0100
It's getting smelly.. 32 bits only?
--
Best,
Frank.
On Thu, 2005-08-18 at 14:10 -0400, D. Richard Hipp wrote:
> On Thu, 2005-08-18 at 09:40 -0700, Robert Simpson wrote:
> > http://www.psc.edu/general/software/packages/ieee/ieee.html
> >
> > The way I interpreted this site, is that the IEEE standard for floating
> > point numbers was processor
On Thu, 2005-08-18 at 09:40 -0700, Robert Simpson wrote:
> http://www.psc.edu/general/software/packages/ieee/ieee.html
>
> The way I interpreted this site, is that the IEEE standard for floating
> point numbers was processor agnostic and the storage of the bits went from
> left to right.
>
I
>SQLite tries to store everything on disk as big-endian. That
>means it always byte swaps on little-endian machines (basically,
>ix86) and omits byte swapping for big-endian machines (which is
>to say, everything other than ix86.) The byte swapping happens
>for integers *and* floating-point
On Thu, 2005-08-18 at 12:24 -0400, D. Richard Hipp wrote:
> On Thu, 2005-08-18 at 18:04 +0200, Frank van Vugt wrote:
> > L.S.
> >
> > It looks like there's something wrong with the endiannes when using sqlite3
> > (v3.2.2) on an ARM architecture (SA1100 nanoboard) while storing floating
> >
Original Message -
From: "D. Richard Hipp" <[EMAIL PROTECTED]>
To: <sqlite-users@sqlite.org>
Sent: Thursday, August 18, 2005 9:24 AM
Subject: Re: [sqlite] Possible bug regarding endiannes and real storageclass
(sqlite3)
On Thu, 2005-08-18 at 18:04 +0200, Fran
On Thu, 2005-08-18 at 18:04 +0200, Frank van Vugt wrote:
> L.S.
>
> It looks like there's something wrong with the endiannes when using sqlite3
> (v3.2.2) on an ARM architecture (SA1100 nanoboard) while storing floating
> point data.
>
SQLite assumes float point values are stored in the IEEE
L.S.
It looks like there's something wrong with the endiannes when using sqlite3
(v3.2.2) on an ARM architecture (SA1100 nanoboard) while storing floating
point data.
Databases created on i386 can basically be read and used on the ARM device and
viceversa. However, data that is stored using
I think there might be a bug in this code in lockBtree:
if( sqlite3pager_pagecount(pBt->pPager)>0 ){
u8 *page1 = pPage1->aData;
if( memcmp(page1, zMagicHeader, 16)!=0 ){
goto page1_init_failed;
The problem is if you are trying to open a non-sqlite file that is
smaller than
> I tried to download sqlite3-3.1.1beta.bin.gz to see if
> this problem still exists, but my browser and wget both
> report that the file is empty.
I get that too. Not sure why, the file is there on the server.
> The following is from version 3.1.0. It is perhaps an
> unusual use of a
I tried to download sqlite3-3.1.1beta.bin.gz to see if
this problem still exists, but my browser and wget both
report that the file is empty.
The following is from version 3.1.0. It is perhaps an
unusual use of a correlated subquery. If it's a bug that
someone wants to address, let me know and
201 - 239 of 239 matches
Mail list logo
