> If you consider the design space, “resetting the state every time” is exactly how basically every other “fiddle” app works. This app's design space is exposi

> If you consider the design space, “resetting the state every time” is exactly how basically every other “fiddle” app works. This app's design space is exposing the sqlite3 shell app via the web, not to emulate every other fiddle environment. sqlite shell app's doesn't (with very good reason) behave that way and the fiddle frontend is just passing state between the user and that app. > The idea is to let you build up a reproducible, shareable outcome. Because this app has no server-side state, we have no way of _sharing_ the outcome. Large fiddle sites give you a short URL which refers to state in their server-side storage. This app completely lacks that (and we're definitely not going to add server-side state to this app). What we _might_ eventually do is offer the ability to base64-encode the SQL into a URL argument which can be shared, but URL length limits are very server-dependent so it would be impossible to portably share "large" fiddles that way. > (and confusingly easy to discover on accident when you get weird errors as SQLite tries in vain to execute some invalid SQL fragment you accidentally had selected before you hit the run button). There's a comment in the initial example SQL explaining that feature, so it'll _hopefully_ be noticed by people new to the app. (Noting that that's not, as of this writing, yet deployed on the production server.) Another feature under consideration is having it intermittently spit out random tips/reminders to the output area (when the db is not working - the app knows when that's happening), and the exec-selection feature would be one such tip.