Skip to content

Add Intellrise CSV to SQL converter to SQLite Web Services - #47

Open
MiyaN-ishere wants to merge 3 commits into
planetopendata:masterfrom
MiyaN-ishere:add-intellrise-csv-to-sql
Open

MiyaN-ishere wants to merge 3 commits into
planetopendata:masterfrom
MiyaN-ishere:add-intellrise-csv-to-sql

Conversation

@MiyaN-ishere

@MiyaN-ishere MiyaN-ishere commented Sep 7, 2026

Copy link
Copy Markdown

Adds the Intellrise CSV to SQL converter under SQLite Web Services.

Upfront, so you can judge it fairly: this is a multi-dialect generator — PostgreSQL, MySQL, SQL Server, SQLite and generic ANSI — and it opens on PostgreSQL, not SQLite. So it is not an SQLite-only tool. I have worded the entry to say exactly that; if a multi-dialect tool is out of scope for this list, that is a completely fair reason to close this, and I would rather you close it than have the entry oversell.

Why COMMERCIAL.md rather than README.md: it is a hosted, closed-source tool. README line 13 routes "closed source / proprietary free or non-free sqlite tools & services" to this page. It is free to use with no account, but it is not open source — so the README's Text-to-SQLite section (whose three entries are all open-source CLIs) did not look like the right home.

What it actually does when you pick SQLite — these are the parts that are not just "we also print SQLite":

  • Types map to SQLite's real vocabulary — TEXT / INTEGER / REAL, booleans emitted as 1/0, dates as TEXT — rather than emitting BOOLEAN and DATE, which SQLite will accept and then store as something else.
  • Identifier quoting, CREATE TABLE IF NOT EXISTS and multi-row INSERT batching are per-dialect.
  • Column types are inferred from the values, not the header, sampling the first 500 data rows. A value with a significant leading zero (00501, 007) keeps the column TEXT, so ZIP codes, SKUs and account numbers do not silently lose their zeros. Slash dates (03/04/2024) also stay TEXT, because day/month order is not recoverable from the file — typing them as a date would hand that guess to the target database, and the mistake would be invisible in the DDL.
  • An Excel workbook becomes one table per worksheet, named after the sheet.
  • Parsing runs in the browser tab, so there is no upload step and no account.

Two things I corrected in the second commit, after re-checking the code rather than trusting my own first draft: SQLite is one of five dialects and not the default (the first version of the entry implied otherwise), and the leading-zero rule is scoped to the sampled rows, not the whole file.

Disclosure: I work on Intellrise, so this is a self-submission. If self-submissions are not welcome here, or if you would rather it sat somewhere other than SQLite Web Services, say the word and I will amend or close.

Live page: https://intellrise.com/tools/csv-to-sql-converter/

…cope the leading-zero rule to the sampled rows
The previous wording said a leading zero "in the first 500 rows" keeps the
column TEXT so ZIP codes and SKUs do not silently lose digits. The qualifier
was on the antecedent while the promise stayed universal, and the promise was
false: a zero first appearing at row 501 typed the column integer, and 00501
into an integer column reads back 501 on both SQLite and PostgreSQL.

That is fixed in the tool rather than talked around -- the leading-zero
question is now asked of every row in the column, and asked before the boolean
and date branches, which were skipping it entirely. The entry now also states
the sampling limit that remains, and the one residual worth knowing: on SQLite
a 20-digit reference number becomes a float, and two that differ in the last
digit compare equal.

Also corrected: worksheets that are empty produce no table, and the fifth
dialect is labelled "Generic SQL" in the picker, not "ANSI".
@MiyaN-ishere

Copy link
Copy Markdown
Author

Before anyone spends time reviewing this: one sentence in the entry was false, and I would rather tell you than have you find it. Pushed a correction in 3a53fae.

What was wrong. The entry said a leading zero "in the first 500 rows keeps the column TEXT so ZIP codes and SKUs do not silently lose digits." An earlier review of my own draft caught that the guarantee needed the "first 500 rows" qualifier, so I added it — and left the promise after it universal. The promise was still false. Measured:

  • data row 500 → column typed text; data row 501 → typed integer
  • '00501' into an INTEGER column: 501 on sqlite 3.50.4, 501 on PostgreSQL 18.3. No error either way.

What I did about it. Fixed the tool, not the sentence. The leading-zero question now reads every row in the column, and it is asked before the boolean and date branches — those two were skipping the check entirely, so a column whose sampled cells happened to be no/yes or ISO dates lost the zero anyway. Live now; you can check it on the page: paste 700 rows where only row 601 has 00501 and the DDL says "zip" text. A column with no leading zero anywhere still comes out integer.

Two more corrections in the same commit, both things a reviewer would have hit:

  • "one table per worksheet""one table per non-empty worksheet". An empty sheet yields no rows and is skipped. (Separately, and not claimed in the entry: two sheet names that sanitize to the same identifier collide — Q1 Sales and Q1-Sales both become q1_sales. I would rather you know that from me.)
  • "or ANSI""or generic SQL", which is what the picker actually says.

What the entry now admits, because it is true. Types are sampled from the first 500 data rows, so a value that contradicts the inferred type and first appears after row 500 is still written into the column. And identifiers that already read as numbers are typed as numbers — on SQLite a 20-digit reference number becomes a float, and two that differ only in the last digit compare equal (count(distinct) returns 1). That is a worse failure than the one I just fixed, and it is not fixed; it is disclosed.

If a multi-dialect tool is out of scope for this list, or if a self-submission is not welcome, closing this is a completely fair call and I will not push back. I would just rather it be closed for the right reason than merged on a sentence that was not true.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant