2009/12/2 Ubirajara Marques da Cruz :
> To Support,
>
>
>
> I am trying to develop a data base what need to specify foreign key to
> preserve problems with insertion of datas.
>
>
>
> I have four tables like i describe below:
>
.
.
.
>
> When i start sqlite3 and inside
To Support,
I am trying to develop a data base what need to specify foreign key to
preserve problems with insertion of datas.
I have four tables like i describe below:
1st) (Projects) with this structure/fields :
índex(primary key) int
ent_project varchar(50)
On Dec 2, 2009, at 3:07 PM, Ralf Junker wrote:
> With the latest FTS3 changes, fts3b-4.9 no longer passes. This short
> SQL
> emulates the test:
>
> DROP TABLE IF EXISTS t4;
> CREATE VIRTUAL TABLE t4 USING fts3(c);
> INSERT INTO t4 (docid, c) VALUES (12, 'still testing');
> UPDATE t4
In x86 the specification of "=A" is EDX:EAX, however in x86-64 is RAX.
And, rdtsc always store EDX:EAX.
In a word, the code of sqlite3Hwtime is opposite.
diff -u sqlite-source-3_6_20/hwtime.h sqlite-source-3_6_20.1/hwtime.h
--- sqlite-source-3_6_20/hwtime.h Wed Nov 4 08:54:16 2009
+++
On Wed, Dec 2, 2009 at 9:42 AM, Nick Shaw wrote:
> Ok, my mistake. But would AUTOINCREMENT imply NOT NULL?
No.
> Could you have
> an AUTOINCREMENT field with post-updated null values?
>
Yes, unless you also specify NOT NULL
> Nick.
>
> -Original Message-
>
Ok, my mistake. But would AUTOINCREMENT imply NOT NULL? Could you have
an AUTOINCREMENT field with post-updated null values?
Nick.
-Original Message-
From: sqlite-users-boun...@sqlite.org
[mailto:sqlite-users-boun...@sqlite.org] On Behalf Of Jay A. Kreibich
Sent: 02 December 2009 15:02
Bump. One bump limit met :-)
Didn't know if this got lost in the holiday rush, but the bug remains. I have a
work-around (see below) that does work, but didn't know if there was a better
solution.
Regards,
-Allan
> -Original Message-
> From: sqlite-users-boun...@sqlite.org
On Dec 2, 2009, at 4:38 AM, Nick Shaw wrote:
> You don't need to define the PRIMARY KEY as NOT NULL - it's implied.
> The column constraint flow diagram in the documentation in fact
> doesn't
> allow it:
> http://www.sqlite.org/syntaxdiagrams.html#column-constraint
>
That diagram is the
On Wed, Dec 02, 2009 at 09:38:54AM -, Nick Shaw scratched on the wall:
> You don't need to define the PRIMARY KEY as NOT NULL - it's implied.
Yes, you do. You shouldn't, but you do:
http://sqlite.org/lang_createtable.html
According to the SQL standard, PRIMARY KEY should imply
On Wed, Dec 2, 2009 at 3:38 AM, Nick Shaw wrote:
> You don't need to define the PRIMARY KEY as NOT NULL - it's implied.
> The column constraint flow diagram in the documentation in fact doesn't
> allow it:
> http://www.sqlite.org/syntaxdiagrams.html#column-constraint
>
>
Your Access query doesn't have good equivalent in SQLite. Your options are:
1. Execute SELECT separately and then for each row in the result issue
an UPDATE with necessary values (UPDATE can be prepared and you can
just bind all values).
2. Insert results of SELECT into some temporary table and
Could you provide some example data? I'm particularly interested in the
values of the Minute field.
-R.
npearson99 wrote:
> I had another question before about moving averages via sql statement and the
> response I got was great.
>
> Now I'm trying to "sample" the data. I guess it would be a
You don't need to define the PRIMARY KEY as NOT NULL - it's implied.
The column constraint flow diagram in the documentation in fact doesn't
allow it:
http://www.sqlite.org/syntaxdiagrams.html#column-constraint
Maybe that's the problem? Try recreating the table without the NOT NULL
constraint on
With the latest FTS3 changes, fts3b-4.9 no longer passes. This short SQL
emulates the test:
DROP TABLE IF EXISTS t4;
CREATE VIRTUAL TABLE t4 USING fts3(c);
INSERT INTO t4 (docid, c) VALUES (12, 'still testing');
UPDATE t4 SET docid = 14 WHERE docid = 12;
Note that SQLite 3.6.20
14 matches
Mail list logo