As Simon points out there is no SQL solution to your issue. Some sort of
external utility processing with things like awk, sed or even cut may
assist or for a quick and dirty method you could set the sqlite3 command
line utility .separator value to a blank string which may (or may not)
provide a
On 20 Nov 2018, at 11:54pm, Shane Dev wrote:
> Is there an SQL statement to concatenate all columns into a single column
> without explicitly naming them?
No. And I can't think of any short-cut way to do what you want.
Simon.
___
sqlite-users
Hello,
An asterisk in the result-column represents all columns from the FROM
clause without explicitly naming them,
https://www.sqlite.org/syntax/result-column.html Is there an SQL statement
to concatenate all columns into a single column without explicitly naming
them? If it existed, I could
On Nov 20, 2018, at 12:41 PM, Jens Alfke wrote:
> On Nov 20, 2018, at 11:44 AM, Bill Hashman
> wrote:
>
>> The timestamp from iOS systems is not compliant with ISO 8601/Unix or other
>> common timestamps. It appears apple has their start date offset 31 years.
>
> Yes, the ‘epoch’ in
> On Nov 20, 2018, at 21:49, Thomas Kurz wrote:
>
>> (Does SQL itself have a numeric timestamp type, or explicitly endorse the
>> POSIX epoch for numeric timestamps?)
>
> SQL has an explicit TIMESTAMP type since SQL-92, one thing that I'm heavily
> missing in SQlite ;-)
DATE '1998-12-25’ &
Well dang. I don't think I've used .executescript() before, but that is
definitely broken, yes.
-Original Message-
From: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] On
Behalf Of Keith Medcalf
Sent: Tuesday, November 20, 2018 3:30 PM
To: SQLite mailing list
> (Does SQL itself have a numeric timestamp type, or explicitly endorse the
> POSIX epoch for numeric timestamps?)
SQL has an explicit TIMESTAMP type since SQL-92, one thing that I'm heavily
missing in SQlite ;-)
___
sqlite-users mailing list
> On Nov 20, 2018, at 11:44 AM, Bill Hashman
> wrote:
>
> The timestamp from iOS systems is not compliant with ISO 8601/Unix or other
> common timestamps. It appears apple has their start date offset 31 years.
Yes, the ‘epoch’ in Apple’s own APIs (CoreFoundation, Foundation) is 1/1/2001,
Change the executed SQL to be executed using .executescript(...) and make sure
that the executed SQL is a multi-statement batch consisting of
BEGIN TRANSACTION; COMMIT; that is
cur1.execute(createSQL) -> cur1.executescript('BEGIN TRANSACTION; ' + createSQL
+ ' COMMIT;')
and see what
Short version of my opinion for this is: An application can store whatever it
wants in a database. The job of the database software, or the ODBC software is
to give you "what they actually stored", not to give you "what they meant by
it." So putting this at the ODBC driver level would be bad.
As an aside, it works properly written in python using apsw. It does not work
when using Pythons sqlite3 wrapper (but then, since that wrapper "buggers
about" with no way to tell what it is doing, I find that unsurprising).
Works fine for me anyway. What I wrote for an equivalent is below.
Hello to all, I was delving into a SQLite db3 that is a backup from a iOS
application when I came across a timestamp translation challenge.
The timestamp from iOS systems is not compliant with ISO 8601/Unix or other
common timestamps. It appears apple has their start date offset 31 years.
after adding in the obviously missing #include's for and
the provided code does not compile. It is looking for an undefined something
called EXPECT_EQ ...
Kind of hard to reproduce if incomplete code is presented.
As an aside, it works properly written in python using apsw. It does not
On 11/20/18, Albert Banaszkiewicz wrote:
> I was expecting that modifying a DB via a certain connection should also be
> visible for all other opened connections.
That is correct.
>
>
> In my test example, I am creating a table via connection no. 1 and drop it
> via connection no. 2.
The
Hi,
On Tue, Nov 20, 2018 at 10:32 AM Dominique Devienne wrote:
>
> On Tue, Nov 20, 2018 at 5:28 PM Simon Slavin wrote:
>
> > On 20 Nov 2018, at 3:34pm, Albert Banaszkiewicz <
> > albert.banaszkiew...@tomtom.com> wrote:
> >
> > > ExecuteInTransaction(writeDb1, KCreateTable);
> >
> > I can't
On 20 Nov 2018, at 4:32pm, Dominique Devienne wrote:
> Hmmm, DDL is transactional in SQLite, AFAIK... --DD
I was wrong. Thanks for the correction.
Simon.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
> On Nov 20, 2018, at 10:27 AM, Simon Slavin wrote:
> On 20 Nov 2018, at 3:34pm, Albert Banaszkiewicz
> wrote:
>
>> ExecuteInTransaction(writeDb1, KCreateTable);
>
> I can't answer your question but the above line shows a misunderstanding of
> SQL. Transactions are for commands which
On Tue, Nov 20, 2018 at 5:28 PM Simon Slavin wrote:
> On 20 Nov 2018, at 3:34pm, Albert Banaszkiewicz <
> albert.banaszkiew...@tomtom.com> wrote:
>
> > ExecuteInTransaction(writeDb1, KCreateTable);
>
> I can't answer your question but the above line shows a misunderstanding
> of SQL.
On 20 Nov 2018, at 3:34pm, Albert Banaszkiewicz
wrote:
> ExecuteInTransaction(writeDb1, KCreateTable);
I can't answer your question but the above line shows a misunderstanding of
SQL. Transactions are for commands which modify tables: INSERT, UPDATE,
DELETE. Commands which modify the
Hi everybody,
I have a question regarding multiple connections to the same DB from the same
process.
I was expecting that modifying a DB via a certain connection should also be
visible for all other opened connections. Is my assumption incorrect ? (both
operations being transactions).
In
Hi,
thanks for giving access to the snapshot. I paste below output from the
CLI. The pragma compile_options now works, but there is an error in the
coordinates returned from applying geopoly_ccw those produced by a
simple mirror about x axis.
SQLite version 3.26.0 2018-11-17 14:26:45
Enter
21 matches
Mail list logo
