I've been thinking about this a bit more and from a different perspective. First, there's no money to be made by messing with my little tool or the work others build in it; so, I'm not expecting to attract people who can reverse engineer complex programs. I'm just trying to prevent the clever jackass from messing with the work of others and discouraging people from sharing content. The database itself is no more useful outside of the tool than an Excel file is outside of Excel. So, it doesn't matter if someone can read the data externally, but just that they can't edit certain areas from within the tool or open it at all. But, of course, there has to be a value or values within each database indicating which areas can be edited. The question seemed to be how can they be protected, obfuscated, hidden; but maybe there's an additional step. Before considering SQLite, the data that would be shared was in a flat file that contained a set of maps required to read different areas of that data to be parsed, some of which also contained internal maps for further parsing. Values that were related to functionality weren't simply 0 for false and 1 for true; but were of different lengths, such that, if they were to be modified external to the tool, the data and the maps wouldn't be consistent and parseable. That wasn't for security but was just the way it was set up from the beginning. The time it would take to find and alter the maps, which would also alter the data layout further requiring other maps to be altered, just made it not worth the effort for some joker to figure out. Is there an equivalent in relational databases? For example, could a set of triggers be used such that if one of those values that determines when the build side is displayed in the UI is altered, a trigger alters something else in the database which instructs the tool to no longer function on that database period and/or delete important sections of data? Perhaps, it could be set up such that if one knew which triggers were significant, they still couldn't be deleted because they would also be required for normal valid operation in some manner. That may be a ridiculous example but I'm just trying to give an example of what I'm asking. Is it possible to sort of wire a database to self destruct if off-limit areas are tampered with? At least to make it a ball of yarn tangled up enough to discourage the jerks from messing with it? Each mistake would "ruin" the database to the extent that it couldn't be opened in the tool again without rebuilding it, requiring the user to obtain another copy to try it again. Thanks.