I'm expanding my comments to an answer, the main point being that while I agree with Alex on everything he writes, I recognize that a Windows user might be better off using graphical tools.
How to open, browse and edit a Sqlite .DB file
Sqlite databases are not plaintext files, and need to be handled with specific software. If you are using Firefox, I would recommend the SQLite Manager Add-on, otherwise there is the excellent standalone DB Browser for SQLite, which is available for Windows, Mac and Linux and even as a Portable App. This is what the OP already is using.
With either of these programs, you can connect to (or open) a SQLite file and then browse, search and edit its contents. If you made any changes, you can save them back to the original file and you are done.
How to find a value in a database
Simple searches in databases are done on a column in a table. This means that you have to know beforehand which table contains the data you are looking for, select it and then run the query against one of its columns. Database manager software, both graphical and command-line, will usually follow this pattern.
But what if you don't know in advance where the string you are looking for could be? How to look for a specific sequence anywhere in the whole database? The easiest way is to transform the database into a flat text file and search within it. This could reveal all occurrences of a certain string and will let us know which tables and columns are relevant so that we can go back and work on them with the manager tool of our choice. Alternatively, we could carefully edit the exported database and then reimport it to the original .DB file format.
Nearly every database manager tool has an export (or dump) and import function that will do exactly that.
Specific: finding "SCROLL in this file -- failed
By following the aforementioned methods, I was unable to find the string "SCROLL in the file provided by the OP. What dazzles me is that the original .DB file contains it (when viewed as text) and the exported SQL does not contain it; when however it is reimported back to the .DB format, the new file contains it (again, when viewed as text). The explanation is beyond me at the moment.