17 Feb
2021
17 Feb
'21
8:26 a.m.
On 2/16/21 7:43 PM, Grant Taylor via TUHS wrote:
On 2/16/21 6:16 PM, Will Senn wrote:
Oops. That's right, no username & password, but you still need to bring
it up and interact with it... accept, as you say, you can enter your sql
as an argument to the executable. OK, I suppose ... grump, grump... Not
quite what I was thinking, but I'd be hard pressed to argue the
difference between creating a handful of files in the filesystem (vs
tables in sqlite) and then using some unix filter utilities to access
and combine the file relations (vs passing sql to sqlite) other than,
it'd be fun if there were select, col, row (grep?), join (inner, outer,
natural), utils that worked with text without the need to worry about
the finickiness of the database (don't stone me as a database
unbeliever, I've used plenty in my day).
Will
Nice! Thanks Doug. Too bad, though... one gets
ever tired of having
to log into db's and a simple text db system would be useful. Even
sqlite, which I love, requires login to get at information... I'm
already logged in, why can't I just ask for my info and have it
returned?
What do you mean by "log into db's" in relation to SQLite? I've
never
needed to enter a username and password to access SQLite.
If you /do/ mean username and password, I believe that some DBs will
allow you to authenticate using Kerberos. Thus you should be able to
streamline DB access along with access to many other things.
If you /don't/ mean username and password, then what do you mean? Are
you referring to needing to run a command to open and access the
SQLite DB? Taking a quick gander at sqlite3 --help makes me think
that you can append the SQL(ite) command that you want to run to the
command line.