If I start with Precompiled Binaries for Windows - 32-bit DLL (x86) for SQLite version 3.38.2, what dio I need to do to execute this script successfully?

Start over and obtain the file named "sqlite-tools-win32-x86-3380200.zip". That DLL you wanted to start with is made to be loaded into an application that needs direct access to the SQLite library API. What you need is the command line shell that is in the archive I named.

load ./csv If I understand correctly, this is loading an extension. Does 3.38.2 need this step?

The command line shell is able to import CSV without the aid of an extension. However, people have published extensions that offer more flexibility for such imports. I suggest that you defer worrying about where to find and how to use such extension until you find the shell's built-in .import insufficient.

With the CLI

.import -csv './mycsv.csv' myTable

will create/persist myTable in the database that is open, will it not? So, myTable will NOT be a virtual table, correct?

As I mentioned, I am trying to get a handle on Virtual Tables.

I seem to have misread part of your post. A closer reading makes me think you wish to use this extension, which you will need to compile before it can be used. (My advice to start over still applies to what you were starting with.)

You may find this section on compiling extensions helpful.

In answer to your last question: The shell's .load command will be needed to load the csv extension, regardless of the shell version.

A closer reading makes me think you wish to use this extension, which you will need to compile before it can be used.

Failed to compile CSV.C

I am wondering whether what we discussed here applies.

Failed to compile CSV.C

I am wondering whether what we discussed here applies.

My advice to use the batch files provided with a Visual Studio install stands. If not for social issues associated with repeating the other advice, (now that you are revealed as a particular Anonymous), I would say again to study the compiler's complaints. (I have found that to be worthwhile, and easier to do after having learned what those complaints usually means.)

We do want the docs to provide useful tips on building project images, so if you are seeing errors that do not result from failure to use one of those batch files, they may be of interest and welcome here. I take from your reticence about specific compiler complaints that you are still figuring out what they mean. Good, and if that ends up being too difficult, help can had here.

now that you are revealed as a particular Anonymous

As it seems to matter, and in the interest of transparency, I'll use this identity ...

The question "So, myTable will NOT be a virtual table, correct?" is irritating and I wonder if the concept of virtual tables is understood.

Virtual tables are such ones which appear as tables in SQLite3 but are not stored in native SQLite3 table format. As such the content of a csv file is NOT a table, it is just a text file. By using a csv extension (by usage of the .load command or already built-in in the executable) the text file becomes understood and formatted and transformed into an SQLite3 table format. The .import command uses that format and saves it as table myTable, which persists then in real SQLite3 table format; myTable itself is not virtual but an imported real copy of the text file in csv format understood as a table format.

See also introduction into virtual tables.

A virtual table is an interface to an external storage or computation engine that appears to be a table but does not actually store information in the database file.

You said:

The .import command uses that format and saves it as table myTable, which persists then in real SQLite3 table format;

Hence my statement

So, myTable will NOT be a virtual table

Because, as you said:

Virtual tables are ... not stored in native SQLite3 table format.

Therefore, I don't understand your assertion

is irritating and I wonder if the concept of virtual tables is understood.

Actually I am wondering too.