What actually goes wrong in generated SQL
The conversion itself is trivial and the failure modes are always the same three. An apostrophe in a value ends the string literal early and the rest of the row becomes syntax; this doubles every apostrophe, which is the standard escape in every SQL dialect and the only one that is portable. An empty cell becomes an empty string when the column expects NULL, and now a column full of nothing is full of two-character strings that no NULL test will find. And a value that looked numeric is written unquoted, at which point 007 arrives as 7.
The counts above the output name the first two directly: how many values contained an apostrophe, and how many empty cells were converted. If the empty count is large and the column is meant to be NOT NULL, you will find out here rather than three minutes into a load.
NULL, empty string, or DEFAULT
| Setting | Emitted | Use when |
|---|---|---|
| NULL | NULL | The blank means unknown or not applicable |
| Empty string | '' | The column is NOT NULL and blank is a real value |
| DEFAULT | DEFAULT | The column has a default you want applied |
A CSV cannot distinguish between an empty string and a missing value, which is the honest reason this is a setting rather than a detection. The file has nothing but two adjacent delimiters, and what that means depends on the schema. Choose per file, not per row; if two columns need different treatment, generate twice with different column selections, or fix it with an UPDATE after loading.
Quoting values as text is the safe default
Every value is quoted unless you ask otherwise, and the database casts on the way in. That costs nothing on a load of this size and removes the entire class of bug where a string that looks like a number stops being itself. The unquoted option is offered because it makes the output easier to read, and it applies only to a column where every non-empty value is a plain number with no leading zero and no more than fifteen digits. A postcode column, an account number, a phone number and a long identifier all fail that test and stay quoted, which is the behaviour you want.
The one thing quoting does not fix is a target column typed wrongly in the first place. Loading 007 into an INTEGER column stores 7 regardless of how the literal was written. Quoting protects the transport; the schema decides the destination.
Batch size, transactions and identifiers
A multi-row VALUES list is dramatically faster than one statement per row, because the cost is dominated by round trips rather than by rows. A hundred rows per statement is a reasonable default almost everywhere. Very large batches eventually hit a statement size or packet limit, and when they do the failure is one giant statement rejected rather than a partial load, so err smaller on an unfamiliar target. One row per statement is the most portable option and the only one some older tools accept.
Identifier quoting differs by dialect — double quotes are the standard form, backticks and square brackets are the two common alternatives — and none is offered as a default because bare names work when they are simple. Anything in a table or column name that is not a letter, digit, underscore, dollar or dot is replaced with an underscore and the change is reported, since a header of Order Date cannot be an identifier as it stands. Wrapping the whole load in a transaction means a failure halfway through leaves nothing behind, which is what you want on a re-runnable import and not what you want if the load is so large that a rollback would be painful.
Read the output before you run it
This page writes literal SQL for data you already have and have looked at. That is a completely different activity from accepting values from a user and building a query out of them, which is how SQL injection happens and which no amount of escaping in a generator makes safe. Use a parameterised query for anything that arrives from outside.
Before running the result, skim the first statement and the last: check the column order matches the schema, that the value types look right, and that the row count matches what you pasted. Then run it against a copy first. Once the data is in, the SQL formatter tidies the query you write next, and if the CSV needs work before it reaches this page, the column profiler and the quoting fixer come first. As with every tool of this kind, keep production extracts of personal or regulated data out of any web page — including this one — unless your own policy says that is fine.
Questions people ask
Which SQL dialect does this target?
The output is plain multi-row INSERT with single-quoted literals and doubled apostrophes, which every mainstream engine accepts. The dialect-specific part is identifier quoting, offered as double quotes, backticks or square brackets, plus DEFAULT for empty cells, which not every engine allows in a VALUES list. If your target rejects DEFAULT, switch to NULL or an empty string.
Why is my number column still quoted?
Because at least one value in it is not a plain number. A leading zero, a currency symbol, a thousands separator, a run of more than fifteen digits or a stray space anywhere in the column disqualifies the whole column, and it stays quoted. That is deliberate: unquoting a column of identifiers is how leading zeros get lost, and the database will cast a quoted numeric literal into a numeric column anyway.
Can I insert into only some of the columns?
List the ones you want in the columns box, by header name or by 1-based number, separated by commas. They come out in the order you list them and the column list in the statement matches, so this doubles as a reordering step when the file and the table disagree about column order. Names that match nothing are reported and skipped.
How do I handle a header that is not a valid identifier?
Anything outside letters, digits, underscore, dollar and dot is replaced with an underscore, so "Order Date" becomes order_Date and the substitution is listed in the warning. It is a guess at what you meant. When the real column name differs, edit the generated column list once at the top of the statement rather than changing the CSV, or rename the headers before pasting.
Is it safe to run this against production?
The generated text is only as safe as the data you pasted and the review you gave it. This is a literal SQL generator, not a parameterised interface, so it belongs in the loading-a-file-you-inspected workflow and not in any path where values arrive from users. Run it against a copy first, wrap it in a transaction if a partial load would be awkward, and read the first and last statements before executing anything.