Hi Scott,
It is not such a big deal for us but since I saw the subject "whish
list" I thought to add something that I was surprised that it isn't
there in sqlite (since it is so complete in many other ways), but that i
use on regular basis.
I agree that SELECT * in production code is bad, but
Hi,
I am getting the following error on a database. The database
is 78GB large when this started. I am adding data to it via insert statements.
I believe that this is the second time that I have seen this. It has been
running for about 2 weeks adding data to it constantly.
Indeed those two possibilities! And perhaps also to MODIFY a column. We
alter tables all the time :)
The possibility to specify at which place an added column should appear
when I do a "SELECT * ..." would be a nice extra, in MySQL it is done
like: ALTER TABLE table_name ADD COLUMN col_name1
On 5 January 2016 at 00:14, Yuri wrote:
> Please consider this example:
.
.
.
> The 'order by' clause doesn't work, because if it did the result would have
> been:
> 1|x,y
> 2|x,y
>
> sqlite3-3.9.2
>
> Yuri
See http://www.sqlite.org/lang_aggfunc.html last sentence
"
group_concat(X)
Alright, accepted. NFS isn't exactly the proper terminology, however, RFS
(Remote File System) might be a better fit for that particular question.
Basically, as soon as another OS handles the files directly, you're looking
at a possible collision of requests against a SQLite database, which is
All of what Richard asked and said, plus, my question of where the file
stored in relation to the application? (Network attached storage?)
On Tue, Jan 5, 2016 at 10:22 AM, Richard Hipp wrote:
> On 1/5/16, Andrew Stewart wrote:
> > Hi,
> > I am getting the following error on a
On 1/5/16, Andrew Stewart wrote:
> Hi,
> I am getting the following error on a database. The
> database is 78GB large when this started. I am adding data to it via insert
> statements. I believe that this is the second time that I have seen this.
> It has been running for about
> On Tuesday, 5 January, 2016 08:33, gunnar said:
> Regarding views, I don't know how sqlite handles them but I know that
> they can drastically slow down queries in MySQL for example.
While this is true in many cases, using a view rather than a select on the
underlying table should not
NB: This format of the select only works co-incidentally. Presently, the
SQLite query planner "believes" that the order by is significant to the result
and preserves it at some expense. This may not always be the case. Thus using
this method to obtain the desired result is relying on an
Your example is fundamentally flawed because you are not changing the order of
the data fed *into* group_concat. Although the documentation (which I am sure
someone will point you to) indicates that group_concat ordering is arbitrary,
it is not (it cannot be).
It concatenates the data fed
Maybe one option would be to add a layer to affect that explicitly, so that
instead of the problem being that the existing rows can't be reordered
without re-writing the entire table, the problem is to just change the
schema to indicate where the columns should appear in "SELECT *" statements.
On 2016/01/04 6:11 PM, Bernardo Sulzbach wrote:
> On Mon, Jan 4, 2016 at 1:50 PM, Stephen Chrzanowski
> wrote:
>> I did the test to compare SSD vs 5200rpm and 7200rpm drives. I should
>> throw this at my 7200rpm hybrid at this app and see what happens.
>>
> Could you please share any
12 matches
Mail list logo
