How to search a SQLite database?

[Anonymous]

Apparently, the developers of database software have decided that a friendly GUI for searching an entire database (for a text string) is unimportant.  I found a couple of tools for sql server but my Plant 3D files of interest are SQLite.  How do the rest of you get around this limitation?  The same issue occurs with exporting an entire database to something like an Excel file, so I can't just export to Excel and use its ability to search the entire workbook.

There are "Execute SQL" ways of searching, but this apparently will only search a single table at any one time. (i.e. SELECT etc. FROM etc.)

In fact, there are many, many internet alternatives for searching (or exporting) a single table, but a single database could have hundreds of tables, so this isn't practical.

To be clear, if I had a good search method, I would still make the actual edits using software like SQLite Manager or SQLite Expert.

[dave.wolfe]

Sqlite expert professional lets you export/import the whole dB to excel I think.

[Anonymous]

Thanks for the suggestion, Dave, because it's true I'd only tried the free version, but the developer has since confirmed to me in an email that while the pro version can search and export, it can't search or export the entire database all at once, though he did note my idea as a feature request.

[dave.wolfe]

But yes, database people in general view searching everywhere for a text string as a bad idea...

[Anonymous]

Is that just a general feeling you've picked up over the years or have you come across specific situations that would suggest why?

[dave.wolfe]

It's pretty much a rule of thumb. If you have to search the entire database than it's not scalable for millions of records (which is the type of scale db designers consider). 

Plant 3d wise if it's a repeatable type search you want to perform, perhaps you customizing the import/export properties would get you columns you need. Without more information about the search it's hard to give more direction.

[Anonymous]

Interesting. Sounds like they like to keep the number of tables low and the number of table entries high, rather than vice-versa. Thanks for the info.