Closed GoogleCodeExporter closed 9 years ago
Thanks for reporting this issue. We should look at it and if we can confirm it,
which I think we will, we should fix it with 1.9.6.
Original comment by crazy4ch...@gmail.com
on 15 Jan 2014 at 9:48
I was able to reproduce this using SQLite 3.8.6.
We are using the ROWID column to identify a row, e.g. as parameter when
deleting or editing a row. We need to use the primary key instead for WITHOUT
ROWID tables. This means we cannot rely on it being integer and so on.
I will have a closer look at it and see how much effort it is.
Original comment by crazy4ch...@gmail.com
on 26 Dec 2014 at 11:47
With revision dbb1af5da0cb9b495c1d4bc33f77333c9eac5001 I started to fix this.
Just tried it with a table without rowid. It basically works.
There were still problems with SQLites weak type system which I addressed in
20279d45c6ab5e344a71ef9c25b04a2e2e6a5b8b.
One problem still remains: If the table is with rowid, SQLite allows primary
keys to be NULL. Even worse, multiple rows can exist with the primary key being
NULL. These rows currently cannot be distinguished by phpLiteAdmin. Therefore,
I guess we will use rowids when possible and only use primary keys if the table
is without rowid.
Original comment by crazy4ch...@gmail.com
on 27 Dec 2014 at 6:33
With revision 022cd162f9e003a697bf75de6062d5280d1118f7, phpLiteAdmin again uses
rowids to address rows if the table has one. If the table does not have one,
it uses the primary key.
In this case the primary key must not be NULL (enforced by SQLite), so there is
no problem with multiple rows having a NULL primary key anymore.
Original comment by crazy4ch...@gmail.com
on 27 Dec 2014 at 7:45
Original issue reported on code.google.com by
StephanB...@gmail.com
on 30 Dec 2013 at 7:36