There was no error message. It was a segmentation fault.
Che,
On Thu, Jun 25, 2015 at 5:38 PM, Kees Nuyt wrote:
> On Thu, 25 Jun 2015 16:41:25 + (UTC), Ch?
> wrote:
>
>>After using sqlite3_prepare_v2 to prepare "BEGIN TRANSACTION", "END
>>TRANSACTION", and "ROLLBACK TRANSACTION", the system will fault at a delayed
>>time when calling
Dear list,
Harddrives can fail in the most remarkable, surprising ways imaginable, as
for instance reflected on
https://www.usenix.org/legacy/events/fast08/tech/full_papers/bairavasundaram/bairavasundaram_html/index.html
and https://blog.algolia.com/when-solid-state-drives-are-not-that-solid/ .
After using sqlite3_prepare_v2 to prepare "BEGIN TRANSACTION", "END
TRANSACTION", and "ROLLBACK TRANSACTION", the system will fault at a delayed
time when calling sqlite3_step. If I call prepare and step right away, there
is no fault. It runs fine. Thus, if I just execute "BEGIN
On 25 Jun 2015, at 11:49am, Mikael wrote:
> Harddrives can fail in the most remarkable, surprising ways imaginable, as
> for instance reflected on
> https://www.usenix.org/legacy/events/fast08/tech/full_papers/bairavasundaram/bairavasundaram_html/index.html
> and
Hi, Che,
On Thu, Jun 25, 2015 at 12:41 PM, Ch? wrote:
> After using sqlite3_prepare_v2 to prepare "BEGIN TRANSACTION", "END
> TRANSACTION", and "ROLLBACK TRANSACTION", the system will fault at a delayed
> time when calling sqlite3_step. If I call prepare and step right away, there
> is no
Donald Griggs tried to help this problem, and we looked at the Jean C's
advice. However the problem remains. The actual codes using are as follows:
===
string dataFile = "PC-Name\\C\\FolderName\\data.db
" ;
//
// For x32 target
Hi Marco,
it's true that sqlite seems to manage only epoch time up to seconds
precision: I have my timestamps with microseconds resolution and this is
what I have to do in order to have them in a human readable form:
SELECT COALESCE(datetime(TimeStamp/100, 'unixepoch',
Hello I tried to convert an epoch time with a timestamp in milliseconds like
1393732179010 to a correct date but it seems like that the function:
SELECT datetime(1393732179010, 'unixepoch', 'localtime');
is not able to detect ms resolution and incorrectly reports a negative date.
How can I tell
Hello, SOS
I want cr?ate base and
I want create table on sqlite3 ans script python .
Why import the phyton command in squilte?
My name table si BASE SIREN.db
144 colunn text real entier numeric, .. I want D?clare type and style .. Leng
...
HELP
Envoy? depuis mon mobile
Message original
On 6/25/15, Alessandro Tagliati wrote:
> Hi Marco,
> it's true that sqlite seems to manage only epoch time up to seconds
> precision: I have my timestamps with microseconds resolution and this is
> what I have to do in order to have them in a human readable form:
> SELECT
On 6/25/15, Marco Bambini wrote:
> Hello I tried to convert an epoch time with a timestamp in milliseconds like
> 1393732179010 to a correct date but it seems like that the function:
> SELECT datetime(1393732179010, 'unixepoch', 'localtime');
> is not able to detect ms resolution and incorrectly
12 matches
Mail list logo