On 7 Aug 2019, at 9:16pm, Thomas Kurz wrote:
> Well, that's why I asked for an *import* support. It's widely spread practice
> to offer at least import capabilities from other software.
This is what the .import function in SQLite's shell tool is for. It reads a
well-documented text format.
Yeah ok that makes more sense.
Sorry, that was a bit obvious - late night.
Thanks!
- Deon
-Original Message-
From: sqlite-users On Behalf Of
Richard Hipp
Sent: Wednesday, August 7, 2019 11:32 AM
To: SQLite mailing list
Subject: Re: [sqlite] Is rootPage a reasonable estimate for
Wednesday, August 07, 2019, 9:16:17 PM, Thomas Kurz
wrote:
>> I highly doubt the SQLite team will undertake this task. They
>> Surely have the skill to do so, but their priority is the one
>> software product you desire to use, undoubtedly due to its
>> high utility. I doubt that utility would
> I highly doubt the SQLite team will undertake this task. They
> Surely have the skill to do so, but their priority is the one
> software product you desire to use, undoubtedly due to its
> high utility. I doubt that utility would exist if they were
> to wander off tacking the conversion
Mr. Kurz writes:
> I suppose I am not the only one having to convert between
> MySQL/MariaDB and SQLite databases every now and then. I
> know there are converters for MySQL dumps but none of any
> I have ever tried did work nearly reliable.
If you dislike the available converters and do not wish
On 8/7/19, Deon Brewis wrote:
> If I have 2 indexes 'A' and 'B', can I use rootPage to determine which one
> of them is older?
>
> This seems to work for me, or is it just because my database has been
> vacuumed recently and if a database has a lot of empty pages it will add new
> indexes to
If I have 2 indexes 'A' and 'B', can I use rootPage to determine which one of
them is older?
This is for a dynamic index sweep to decide which one to drop.
It doesn't matter if it's sometimes wrong, if the index is needed again it will
be re-created. I just don't want to get into a situation
The BIGGEST problem I had with importing data from MySQL to SQLite is the
table definitions.
If you do two dumps, one specifically for table definitions, the other for
the actual data to be imported, you could get a script to handle the table
definition file to make it conform to what SQLite can
You can use the SQL files from OpenGeoDB as an example:
http://www.fa-technik.adfc.de/code/opengeodb/opengeodb-begin.sql
The result (see below) from the https://github.com/dumblob/mysql2sqlite
converter is completely useless as none of the create statements is complete. I
have observed severe
On 7 Aug 2019, at 5:13pm, Thomas Kurz wrote:
> So my suggestion would be to add an import feature to the CLI that allows to
> directly import MySQL/MariaDB dumps into an SQLite database keeping as many
> information as possible. As SQLite already has a complete SQL parser I expect
> much
Dear SQLite team,
I suppose I am not the only one having to convert between MySQL/MariaDB and
SQLite databases every now and then. I know there are converters for MySQL
dumps but none of any I have ever tried did work nearly reliable.
So my suggestion would be to add an import feature to the
Hi Richard, and others,
A neat little program with added in the context of Fossil SCM,
which asserts the version of the SQLite library used, and which
compile time option were used to compile it (statically or not, for that
matter).
See https://fossil-scm.org/fossil/info/350c627a52908458
I
And what about Decimal type? Because Decimals are converted to string. It's
a problem because it forces the programmer to format read values from
database and cannot use them directly...
Best regards
El mié., 7 ago. 2019 a las 10:15, Olivier Mascia ()
escribió:
> > Le 7 août 2019 à 09:43,
On 7/8/62 13:50, P Kishor wrote:
Using FTS5 (sqlite3 3.29.x), the following works
SELECT Count(id) AS c FROM t JOIN v ON t.id = v.id WHERE v MATCH 'Trematoda
awaiting allocation’;
but the following fails
SELECT Count(id) AS c FROM t JOIN v ON t.id = v.id WHERE v MATCH 'Trematoda
> Le 7 août 2019 à 09:43, Ainhoa B a écrit :
>
> So, in SQLite, it doesn't matter if I create a table with a column of int,
> smallint or long type, it will always be trated as a INTEGER type of 64
> bits?
Regarding integers, yes they are always signed 64 bits integers. See
So, in SQLite, it doesn't matter if I create a table with a column of int,
smallint or long type, it will always be trated as a INTEGER type of 64
bits?
Regards
El mié., 7 ago. 2019 a las 9:01, Clemens Ladisch ()
escribió:
> Ainhoa B wrote:
> > My database has tables with int values and
Ainhoa B wrote:
> My database has tables with int values and DateTime values. When I execute
> the scaffold command to convert the tables of the database to models in
> .NET Framework, my colums of type int are being converted to long
SQLite's INTEGER type has 64 bits. The framework assumes that
Using FTS5 (sqlite3 3.29.x), the following works
> SELECT Count(id) AS c FROM t JOIN v ON t.id = v.id WHERE v MATCH 'Trematoda
> awaiting allocation’;
but the following fails
> SELECT Count(id) AS c FROM t JOIN v ON t.id = v.id WHERE v MATCH 'Trematoda
> (awaiting allocation)’;
Error: fts5:
Hi all,
I'm working with SQLite and EntityFrameworkCore and I'm having problems.
My database has tables with int values and DateTime values. When I execute
the scaffold command to convert the tables of the database to models in
.NET Framework, my colums of type int are being converted to long
19 matches
Mail list logo
