So here’s the latest on my plan to come up with the easiest, simplest way to write an intuitive, nice looking Woo-related browser app that’s able to connect in a very simple way to a local datastore on the desktop.
There is only one problem: unlike, say, C, JS has no built-in file I/O capabilities.
In the case of wanting to access SQLite, you have to use SQLite3 + node + npm, All this to accomplish what can be done in one line of code in C or a C++ program that uses ODBC to connect to SQL Server.
And if you ever had to write a JS script that uses SQLite3, you will soon begin to rue the absolutely maddening error-prone tedium of the unnecessary complexities of error handling when using SQLite3.
All I want to be able to tell JS to (1) connect to SQLite then (2) open a DB then (3) retrieve data from a table.
This is not exactly rocket science. I don’t think the user would mind waiting for a split second while a few hundred rows are retrieved in blocking, synchronous mode.
Instead of just being able to connect to SQLite synchronously, as you would if you were writing your app in C, you’re forced to deal with SQLite3 + node.js + npm in order to access SQLite.
Adding all these massive dependencies (over which you have little control, results in a situation where you have no idea what is really going on on your machine behind the scenes): massive security hole, obviously.
Why on earth was SQLite3 not built to also support synchronous I/O?
After all, remember the SQLite mantra: “open-source, zero-configuration, self-contained, stand-alone… ” etc etc?
And remember, too, that the intended number of simultaneous end users is exactly 1. In this scenario, it is RIDICULOUS to be forced to make asynchronous calls to a local db.
Plus which, when it comes to SQLite3, does it ever mentioned (gulp)
in the documentation? Well, does it, punk?
This NJS (NPM + JS + SQLITE3) Rube Golberg jive is the antithesis of that stated SQLite ideal, or am I wrong?
Then, I thought… why not ODBC?
For a moment, I allowed myself to fondly remember those MS Access days wayback in the 90s when I was able to use ADO to grab data from almost any source, no fuss, no muss, and thank you very much.
My mood began to turn increasingly dark, at the unfairness of Life, as I googled frantically. Then, the clouds parted, and I found… this.
I found it!
An ODBC driver that’s MIT licensed and recommended by no less a reputable source than Microsoft.
I quickly added it to my ODBC data sources in the Administrative Tools of the Control Panel in Windows.
Then I tested it with Libre Base. It worked, with some minor fiddling (see below), like a charm.
Then I tested it again, this time with Microsoft Power BI (which I noticed, by the way, is developing connectivity to Stripe as a data source).
That worked fine, also.
So the driver ran as advertised.
But I was not out of the woods yet.
And I did.
So all I had to do now is figure out how to get my JS StoreBoss DB function library to work like this.
Now that is what I call beautiful. Except that it turned out to be a really bad idea (see Postword below).
Postword: After installing this complex JS chromium runtime extension (which requires you to use an elevated Admin CLI), I could not get the example code to work, and left a call for help in its git page. I say bag this native extension stuff; too much of a headache. But if you can follow what Gabriel Schulhof says about native add-ons in this YouTube bid, please leave a comment!
UPDATE #2: Hello, hello. What’s this? Let’s first look at the Trouble Shooting guide. On Windows, as opposed to UNIX derivatives, things are more complicated (as always). Let’s see… hmmm.
- Start an Admin PowerShell: Right-click the start icon, then pick
Windows PowerShell (Admin)
- Install both vs2015 and vs2017 libraries. Each line will take ~5-10 minutes.
npm install --global --production --vs2015 --add-python-to-path windows-build-tools npm install --global --production --add-python-to-path windows-build-tools node-gyp
That is what I had to with the native extension, and it trashed my setup. I’ll not be installing anything again that forces me to use Admin privileges, so bag that. Too dangerous, and what if an end-user has to change his or her machine’s configuration to get this package to run? StoreBoss would be dead in the water. Troubling issues page, too.