Thanks, It works now.
On Mon, Mar 14, 2016 at 10:06 PM, syl leo wrote:
> Hi,
> In your c++ program, if you use directly sqlite.c and .h and not the
> dll+lib, you should remove the sqlite3.lib in your link.(project properties
> -> linker -> input)
> No ?
> Regards.
> Sylvain.
>
> De :
Hi,
I'm not a expert but i played few days ago with that.What i have seen is :?1?)-
I open a database with?sqlite3_open(..)- create a table and add record -> no
problem- close the base
2?)- I open the same database with?sqlite3_open(..)- Add a user
with?sqlite3_user_add( user, password.)- Close
Tthe documentation says to use the flag as?
-DSQLITE_USER_AUTHENTICATION
whereas in your message you said you used?
-D_SQLITE_USER_AUTHENTICATION
So unless cl ignores a leading underscore (seems unlikely), you're defining
something the code doesn't care about.
On Monday, March 14, 2016
Hi,
I have downloaded the SQLITE amalgamation folder along with the entire
source code.
Followed the steps mentioned here
http://www.sqlite.org/src/doc/trunk/ext/userauth/user-auth.txt
Using the following command to build the sqlite3.exe:-
cl -D_SQLITE_USER_AUTHENTICATION shell.c sqlite3.c
On Mon, 14 Mar 2016 13:25:09 +0100
Clemens Ladisch wrote:
> > that ``SELECT CAST(col AS INTEGER);'' should return (not so) random
> > result set, and receiving any INTEGER should mean that a source
> > string could have trillion or more possible values?
>
> The documentation does not specify
Hi,
In your c++ program, if you use directly sqlite.c and .h and not the dll+lib,
you should remove the sqlite3.lib in your link.(project properties -> linker ->
input)
No ?
Regards.
Sylvain.
De?: siddharth kotian
??: sqlite-users at mailinglists.sqlite.org
Envoy? le : Lundi 14 mars
Hello,
On 2016-03-14 13:25, Clemens Ladisch wrote:
> Cezary H. Noweta wrote:
>> Is your opinion
>
> Why would my opinion matter, as opposed to what SQLite actually does?
Because, SQLite behaves in a bit strange manner, which is opposite to
extreme carefulness of SQLite in other areas. I'm
On Mon, Mar 14, 2016 at 12:02 PM, Clemens Ladisch wrote:
> Then the obvious explanation is that there is a bug in your insertion
> code. (Which you have not shown.)
Shame on me, the insert was fine (null value against timestamp column)
but later on an update of such column was issued as:
Cezary H. Noweta wrote:
> On 2016-03-14 12:03, Clemens Ladisch wrote:
>> The documentation is quite clear that INTEGERs have 64 bits. So trying
>> to use integers above 9223372036854775807 is something that is better
>> not to be done.
>
> How could somebody use integers above 9223372036854775807
Hello,
On 2016-03-14 12:03, Clemens Ladisch wrote:
> The documentation is quite clear that INTEGERs have 64 bits. So trying
> to use integers above 9223372036854775807 is something that is better
> not to be done.
How could somebody use integers above 9223372036854775807 if they do not
exist?
On Mon, Mar 14, 2016 at 12:03 PM, Clemens Ladisch
wrote:
> Cezary H. Noweta wrote:
> > Is there some more-or-less official list posted somewhere with things
> which is better not to be done?
>
> The documentation is quite clear that INTEGERs have 64 bits. So trying
> to use integers above
Cezary H. Noweta wrote:
> Is there some more-or-less official list posted somewhere with things which
> is better not to be done?
The documentation is quite clear that INTEGERs have 64 bits. So trying
to use integers above 9223372036854775807 is something that is better
not to be done.
Luca Ferrari wrote:
> On Mon, Mar 14, 2016 at 10:52 AM, Richard Hipp wrote:
>> I think your system clock was set incorrectly when you did the initial
>> insert.
>
> I'm running on localhost and did not touch the clock.
Then the obvious explanation is that there is a bug in your insertion
code.
On Mon, Mar 14, 2016 at 10:52 AM, Richard Hipp wrote:
> I think your system clock was set incorrectly when you did the initial insert.
I'm running on localhost and did not touch the clock.
The following is the result of a just inserted row:
SELECT strftime('%s', ts ), ts, strftime( '%s',
Hello,
On 2016-03-14 11:15, Simon Slavin wrote:
> I would never write code which depended on the answer to that
> question. There are many too many ways for it to fail.
Hmmm... The longest paragraph in ``CAST expressions'' section in the
documentation is about STRING => INTEGER. Nice to know
Hello,
What ``SELECT CAST('1' AS INTEGER);'' should give?
(String of one and 20 zeroes). Actually, preceding ``SELECT'' gives
``7766279631452241920''. Should it be ``9223372036854775807'' (MAXINT64)
or ``100'' (String of one and 18 zeroes --- maximum
length
Hi all,
I suspect I've a wrong timezone, even if I cannot understand how and why.
I've got atable with a column defined as follows:
ts timestamp DEFAULT CURRENT_TIMESTAMP
this should get default values in GMT. Now if I try to compare a row
inserted a few minutes before (without the ts value,
On 14 Mar 2016, at 10:12am, Cezary H. Noweta wrote:
> What ``SELECT CAST('1' AS INTEGER);'' should give?
> (String of one and 20 zeroes). Actually, preceding ``SELECT'' gives
> ``7766279631452241920''. Should it be ``9223372036854775807'' (MAXINT64) or
>
On 3/14/16, Luca Ferrari wrote:
> Hi all,
> I suspect I've a wrong timezone, even if I cannot understand how and why.
> I've got atable with a column defined as follows:
>
> ts timestamp DEFAULT CURRENT_TIMESTAMP
>
> this should get default values in GMT. Now if I try to compare a row
>
On 13 Mar 2016, at 11:39pm, Peng Yu wrote:
> Is there a syntax to disambigurate the duplicated
> column names?
You can use the table names in your SELECT in the same way as you use them in
the JOIN:
select * from A join B on A.a=B.a;
a b c a b
On 2016-03-13 23:14, jungle Boogie wrote:
> Hi Keith,
> On 13 March 2016 at 13:31, Keith Medcalf wrote:
>> On Sunday, 13 March, 2016 13:36 -07:00, jungle Boogie > gmail.com> wrote:
>>> Here it is in decimal: (select code from sidemeters)
>>> "0"
>>> "1"
>>> "2"
>>> "5"
>>> "6"
>>> "7"
>>> "28"
21 matches
Mail list logo
