SQL Correctness

We want SQLEditor to produce absolutely correct SQL on export and to import as much as possible from SQL files.

However it doesn't always work as well as might be hoped.
This page offers some tips on how to report problems with SQL handling.

If you use Help->Send Suggestion, information about the SQLEditor version number and some simple machine details will be included automatically in your email.

• SQLEditor produces incorrect output SQL
• SQLEditor won't import something
• What if I don't want to send in my super secret database?
• But (some problem) is totally obvious, don't you already know about it?

SQLEditor produces incorrect output SQL

Please report this, we would really like to hear about it.

if you can include the following it really speeds things up.

• A sample SQLEditor saved document (sqs extension) that exports incorrectly
  (ideally the smallest possible sample file, containing only the stuff that doesn't export)
• The exact output that you receive from SQLEditor
  (By copying from the source sidebar or by using Export to File)
• What you expect to receive
  What should SQLEditor be producing instead?
  This is really useful to have because it's not always obvious what the output should be.
• The exact version of SQLEditor and details of the machine that you're using.

SQLEditor won't import something

SQL parsing is more complicated than SQL export because there are lots of dialects and the scope is much larger.
But the eventual aim is for SQLEditor to parse any SQL presented to it.

If you find a piece of SQL that doesn't import then we'd really like to hear about it.

The things to send, if you can, are the following:

• A sample of the code that doesn't import
• The name and version of the database system that the SQL is from.
  (e.g SQL from Postgres 7.2)
• The exact version of SQLEditor and details of the machine that you're using.

What if I don't want to send in my super secret database?

Please don't send in anything confidential. If you can, edit or reduce the sample to remove anything confidential.

If this isn't possible then please report as much as you can, better for us to have a limited report that identifies a problem than not knowing about it at all.

But (some problem) is totally obvious, don't you already know about it?

Possibly not, there are lots of SQL dialects and an enormous number of features and combinations.
We may well not know about particular cases and even if we do then it helps to get an idea of how many people are affected by issues in case they need to be prioritised.