SQLite command-line queries

SQLite provides a nice command-line interface for managing databases, but what if we need to run queries from a script? If you have been trying to call SQLite from a Bash script with the “-init” argument, in quest of running SQL queries from a file to the database, you would have also found out that SQLite stays in interactive mode, forcing you to watch the console and exit each time. This becomes a problem once we have many (potentially large) query files that have to be run one after the other, such as when we need to build and rebuild a test database.

So if you are here, your script probably contains something like this:

sqlite3 -init query1.sql mydatabase.db
sqlite3 -init query2.sql mydatabase.db
sqlite3 -init query3.sql mydatabase.db

And each individual command would leave you in interactive mode, forcing you to close it each time with “.exit” for the script to resume its work.

SQLite also allows us to use the input redirection operator to direct file content (or a query directly written in single-quotes) as input. Like this:

sqlite3 mydatabase.db < query1.sql
sqlite3 mydatabase.db < query2.sql
sqlite3 mydatabase.db < query3.sql

This will redirect the content of each file directly into the database without any need for manual intervention.

If you need more information on using SQLite in command-line, then visit their official documentation at https://sqlite.org/cli.html.

Tk Grid Form Resize

Most of the places that explain how Tk’s grid works will tell you the following:

(The examples are made with Python but should work with any language that supports Tk.)

Use “columnconfigure” and “rowconfigure” with a “weight” of at least 1 on each column and row inside the frame. So for a 2×2 grid:

myFrame.columnconfigure(0, weight=1)
myFrame.columnconfigure(1, weight=1)
myFrame.rowconfigure(0, weight=1)
myFrame.rowconfigure(1, weight=1)

Use the “sticky” option for every widget that needs to stick to at least one side of its container. So let’s say we put a button into each cell created above and make them stick to all four sides of their cell:

myButton1.grid(column=0, row=0, sticky=(N,S,E,W))
myButton2.grid(column=1, row=0, sticky=(N,S,E,W))
myButton3.grid(column=0, row=1, sticky=(N,S,E,W))
myButton4.grid(column=1, row=1, sticky=(N,S,E,W))

But even after doing this, which can take quite some time on large interfaces, it still doesn’t seem to work. The missing element, which no one seems to tell, is that the “root” container also has to be set to a weight greater than 0 with “columnconfigure” and “rowconfigure”. In this case we just need to do it for the cell (0,0) because the frame takes care of all other divisions of the window. So as it is suggested in various places, you probably have something like this in your main file:

root = Tk()
root.title("My application")

Which means that “root”, too, has to be configured by adding:

root.columnconfigure(0, weight=1)
root.rowconfigure(0, weight=1)

And now, your widgets should stick to what you set them to.
Here’s the full code of the example:

#!/usr/bin/python

from tkinter import *
from tkinter import ttk

root = Tk()
root.title("My application")
root.columnconfigure(0, weight=1)
root.rowconfigure(0, weight=1)

frame = ttk.Frame(root)
frame.columnconfigure(0, weight=1)
frame.columnconfigure(1, weight=1)
frame.rowconfigure(0, weight=1)
frame.rowconfigure(1, weight=1)
frame.grid(column=0, row=0, sticky=(N,S,E,W))

button1 = ttk.Button(frame, text="Button1", command=lambda: print("Button1"))
button2 = ttk.Button(frame, text="Button2", command=lambda: print("Button2"))
button3 = ttk.Button(frame, text="Button3", command=lambda: print("Button3"))
button4 = ttk.Button(frame, text="Button4", command=lambda: print("Button4"))
button1.grid(column=0, row=0, sticky=(N,S,E,W))
button2.grid(column=1, row=0, sticky=(N,S,E,W))
button3.grid(column=0, row=1, sticky=(N,S,E,W))
button4.grid(column=1, row=1, sticky=(N,S,E,W))

root.mainloop()

Access Databases

I don’t know how it’s possible that someone at Microsoft decided that Access was still relevant in 2018. I can understand that at some point in the past, it could have been useful in some cases. But now that IT has evolved to what it is now, how can such aberration still exist?

Ok, I studied computer science a few years ago and worked in the field for a few years, so I consider that I have a respectable amount of knowledge and experience in IT, yet I still have a hard time doing the basic things with this software. I believe that Microsoft has great engineers that know a lot more about computers and programming than I’ll probably ever know, so how can something like Access even exist?

A little while ago, I had to get back into Access do to a few tasks that I would describe as “basic”, without getting into details about what I did exactly, let’s say that I had to build a database, and build forms and reports that made the data usable by the common mortal. And I almost failed at it! I would probably have done a better and faster job coding the whole thing in C# and SQL.

In the past, I also had to work with older versions, to as far as Access 97, and frankly, I don’t think anything changed in those 20 years, it just seems like the same software with a more modern user interface (mostly the top ribbon, the rest is just the same old gray color). The same old features and ways of doing things, without much improvement in overall usability.

I can understand that there is definitely a market for something in-between Excel and SQL Server, but why does it have to be this. If I can find my way into Excel and SQL Server, why would it be hard for me to understand how Access works? And I’ve never heard of any fellow coder having a favorable or even neutral opinion about that software, we all hate it.

There must be a reason, I guess it’s because it is a piece of s**t of a software. In general, as IT specialists, we can get around in pretty much any software, no matter if we have used it before or not. Because most applications follow similar guidelines when it comes to the features they provide. But Access seems to get away with doing its own thing and not caring about the rest. (not sure why I’m thinking of Internet Explorer at the moment…)

Maybe it still lives nowadays just to allow companies that are stuck with it to continue using their tools without investing in a real database server? But if it is so, why not scrap Access and do a user-friendly version of SQL Server and SQL Server Management Studio? Like some kind of standalone application that manages its own local server (if they haven’t already done it) that can live on a standard PC/workstation and be passed around, just like Access, but with the features and predictability of a real SQL server. Or just make a front-end for SQLite, which does a pretty good job at managing server-less databases.

I don’t expect any business owner or any non-IT worker to learn SQL, but if a software provided a user-friendly way of using databases like Access does while also having a real SQL engine under the hood, wouldn’t it be nice for all of us poor coders that will inevitably have to help those people at one time or another?