No further suggestions yet, but just reporting back my own findings here.
I tried your script (with similar command lengths) using the /usr/bin version of sqlite3, a simple test database with a single table and a couple of rows, and a sql script consisting of "SELECT * FROM mytable;"
That ran OK from Applescript, and via Word VBA Macscript, and populated the temp.csv file.
I downloaded sqlite3, unzipped into the r4w/Temp folder, renamed, modified the script and tried again.
That also ran OK from Word VBA and populated the temp file.
I also tried running from Excel VBA and that was OK too (unlike the other problem I mentioned).
So it does not seem that there is anything about sqlite3 itself, or the length of your command (unless it's down to a length difference of a couple of characters or so) that is causing the problem. If you can run a simple one-liner .scpt from Word VBA
successfully then it isn't an obvious problem with Word invoking applescript.
The only thing I can think of right now is that...
AFAICS, when Word runs the script, the script should in effect behave as if it is wrapped as follows:
tell application "Microsoft Word"
end tell
you should be able to verify that scripts are "telling" Microsoft Word by running a one-liner like
set appname to the
name of the current application
instead of your script.
If the current application actually turns out to be something else, that would be need to be looked at (but wouldn't necessarily solve the problem). I'm not sure that in a more complex scenario, Word would necessarily be the current application,
but I would expect it to be when you execute macscript from the VBE immediate window.