Search on first table in database

[Eisso Atzema]

A search on the first table in a database using the search tab drops the WHERE "first_table" LIKE '...' part and consequently returns all entries in the database. Not a big deal as you can also search using the corresponding sql command, but somewhat problematic if you want non-technical people to search the database.

[phpLiteAdmin]

I cannot reproduce this. What I did:

• go to https://demo.phpliteadmin.org/ and login
• on the left, click the "Album" table, which is the first one
• click on the "Search" tab
• in the "AlbumID"-Field enter "1"
• click "search" --> It correctly queries: SELECT * FROM "Album" WHERE "AlbumId" = '1'

I checked on all tables of the example database, and search works perfectly everywhere.

Maybe it's a problem with the name of your table or something like that. Can you give the CREATE TABLE statement used to create your first table?

[Eisso Atzema]

Solved the problem. I think the name of the column was the culprit. Specifically, I think it was the fact that the name had a period at the end ('accession no.'). I don't think I would ever have put in a period myself, but this particular file is a CVS import of somebody else's work. This period had never been a problem with MesaSQlite on my mac or with actual direct SQL queries, so I had never given its use any thought. Anyway, after I changed the name of the column to 'accession code' everything worked as it should. So, perhaps I was a bit too quick at signalling a bug. Still, if you do not want to allow periods in the name of a column, some kind of warning would be nice---especially since SQlite does not have a way to easily change the name of a column.

Thanks, Eisso

[phpLiteAdmin]

Thanks a lot for your feedback. I can now confirm that the search does not work for columns that end with a period. This is definitely a bug. We want to support all column/table/... names that SQLite supports - even if my personal opinion is that it is a rather bad idea to have column/table names with a period.

So I will soon look into it and fix it. Thanks again for your feedback.

[phpLiteAdmin]

Search: form input fields don't use the column names as key anymore, as this causes problems if they contain spaces or dots. Instead, they are addressed by their number, just like when inserting into a table. This fixes issue #327.

→ <<cset c641b8220518>>

[phpLiteAdmin]

The problem is that the form used the column name as field-keys. PHP replaces spaces and dots in field-keys with underscore in $_POST and $_GET. phpLiteAdmin already handled the space-Problem by replacing spaces with underscores. The problem with this approach is that if you have one column "a_b" and one "a b", they will both get the same key and thus search works only on one of them. Therefore, phpLiteAdmin is now not using the column names any more for the form field-keys, but addresses the columns by their id. The same approach has already been used when inserting something into columns with spaces or dots in their name.

Can you please confirm that the issue is fixed in the development version: http://www.phpliteadmin.org/phpliteadmin-dev.zip

[phpLiteAdmin]

In case you are using the development version, please read: https://www.phpliteadmin.org/2017/08/17/security-alert-1-9-8-dev/