About SQL Fiddle

How does it work?

The Schema DDL that is provided is used to generate a private database on the fly. If anything is changed in your DDL (even a single space!), then you will be prompted to generate a new schema and will be operating in a new database.

All SQL queries are run within a transaction that gets immediately rolled-back after the SQL executes. This is so that the underlying database structure does not change from query to query, which makes it possible to share anonymously online with any number of users (each of whom may be writing queries in the same shared database, potentially modifying the structure and thus -- if not for the rollback -- each other's results).

As you create schemas and write queries, unique URLs that refer to your particular schema and query will be visible in your address bar. You can share these with anyone, and they will be able to see what you've done so far. You will also be able to use your normal browser functions like 'back', 'forward', and 'reload', and you will see the various stages of your work, as you would expect.

What differences are there between the various database options?

Aside from the differences inherent in the various databases, there are a few things worth pointing out about their implementation on SQL Fiddle.

MySQL only supports queries which read from the schema (selects, basically). This is necessary due to some limitations in MySQL that make it impossible for me to ensure a consistent schema while various people are fiddling with it. The other database options allow the full range of queries that the back-end supports.

SQLite runs in the browser; see below for more details.

What's up with that [ ; ] button under each panel?

This obscure little button determines how the queries in each of the panels get broken up before they are sent off to the database. This button pops open a dropdown that lists different "query terminators." Query terminators are used as a flag to indicate (when present at the end of a line) that the current statement has ended. The terminator does not get sent to the database; instead, it merely idicates how I should parse the text before I execute the query.

Oftentimes, you won't need to touch this button; the main value this feature will have is in defining stored procedures. This is because it is often the case that within a stored procedure's body definition, you might want to end a line with a semicolon (this is often the case). Since my default query terminator is also a semicolon, there is no obvious way for me to see that your stored procedure's semicolon isn't actually the end of the query. Left with the semicolon terminator, I would break up your procedure definition into incorrect parts, and errors would certainly result. Changing the query terminator to something other than a semicolon avoids this problem.

Why are there two strange-looking options for SQLite?

SQLite is something of a special case amongst the various database types I support. I could have implemented it the same way as the others, with a backend host doing the query execution, but what fun is that? SQLite's "lite" nature allowed for some interesting alternatives.

First, I found the very neat project SQL.js, which is an implementation of the engine translated into javascript. This means that instead of using my servers (and my limited memory), I could offload the work onto your browser! Great for me, but unfortunately SQL.js does have a few drawbacks. One is that it taxes the browser a bit when it is first loaded into memory. The other is that it doesn't work in all browsers (so far I've seen it fail in IE9 and mobile Safari).

The other option is "WebSQL." This option makes use of the SQLite implementation that a few browsers come with built-in (I've seen it work in Chrome and Safari; supposedly Opera supports this too). This feature was considered part of the W3C working draft for HTML5, but they depricated it in favor of IndexedDB. Despite this, a few browsers (particularly mobile browsers) still have it available, so I figured that this would be a useful feature to grab onto. The advantage over SQL.js is that it is quite a bit faster to load the schema and run the queries. The disadvantage is that it isn't widely supported, and likely not long for this world.

Together, these two options allow SQLite to run within any decent browser *cough*IE*cough*. If someone links you to a SQLite fiddle that your browser doesn't support, just switch over to the other option and build it using that one. If neither works, then get a better browser.

What platform is it running on?

This site uses many different technologies. The primary ones used to provide the core service, in order from client to server are these: