Requêtes avec la ligne de commande SQLite

SQLite fournie une interface en ligne de commande pour gérer nos bases de données, mais qu’arrive-t-il lorsque nous voulons exécuter des requêtes à partir d’un script? Si vous avez esssayé d’appeller SQLite à partir d’un script Bash en utilisant l’argument «-init», dans l’intention d’exécuter les requêtes SQL contenues dans un fichier sur la base de données, vous avez aussi remarqué qu’SQLite reste en mode interactif, nous forçant donc à surveiller la console et à la quitter à chaque fois. Cela devient un problème lorsque nous avons plusieurs (potentiellement gros) fichiers de requêtes à exécuter les uns après les autres, comme lorsqu’on doit construire et reconstruire une base de données de tests.

Si vous êtes ici, votre script contient probablement ces quelque chose comme suit:

sqlite3 -init requetes1.sql ma_base_de_donnees.db
sqlite3 -init requetes2.sql ma_base_de_donnees.db
sqlite3 -init requetes3.sql ma_base_de_donnees.db

Chaque commande individuelle nous laisse en mode intéreactif, ce qui nous force à utiliser la commande «.exit» pour permettre au script de continuer son exécution.

SQLite nous permet aussi d’utiliser l’opérateur de redirection d’entrée (input redirection operator) pour envoyer le contenu d’un fichier (ou d’une requête écrite entre guillemets simples) comme entrée (input) à une base de données. Comme ceci:

sqlite3 ma_base_de_donnees.db < requetes1.sql
sqlite3 ma_base_de_donnees.db < requetes2.sql
sqlite3 ma_base_de_donnees.db < requetes3.sql

Ce qui va rediriger le contenu de chaque fichier directement dans la base de données sans besoin d’intervention manuelle.

Si vous avez besoin de plus d’information sur l’utilisation de SQLite en ligne de commande, visitez la documentation officielle à https://sqlite.org/cli.html (en anglais).

Redimensionnement formulaire Tk avec Grid

La plupart des endroits qui contiennent des explications sur le fonctionnement de Tk et de son gestionnaire de géométrie «grid» vont vous donner les informations suivantes:

(Les exemples sont écrits en Python mais le principe devrait fonctionner avec n’importe quel langage supportant Tk.)

On doit utiliser «columnconfigure» et «rowconfigure» et définir un «weight» d’au moins 1 pour chaque «column» et «row» à l’intérieur du «Frame». Donc, pour une grille 2×2:

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

On doit aussi utiliser l’option «sticky» pour chaque widget qui doit se coller à au moins un côté de son conteneur. Alors, si on décide de placer un bouton à l’intérieur de chaque cellule créée dans l’exemple plus haut et qu’on les fait coller sur les quatres côtés de leur cellule respective, nous aurons le code suivant:

bouton1.grid(column=0, row=0, sticky=(N,S,E,W))
bouton2.grid(column=1, row=0, sticky=(N,S,E,W))
bouton3.grid(column=0, row=1, sticky=(N,S,E,W))
bouton4.grid(column=1, row=1, sticky=(N,S,E,W))

Mais même après avoir fait tout cela, ce qui peut être relativement long pour des interfaces complexes, rien ne semble fonctionner. L’élément manquant, dont personne ne semble parler, est que le conteneur racine («root») doit aussi avoir un «weight» de plus de 0 pour «columnconfigure» et «rowconfigure». Dans ce cas, tout ce que nous devons faire est d’ajouter les commandes pour la cellule (0,0) puisque le cadre s’occupe du reste des divisions de la fenêtre. Comme il est suggéré à plusieurs endroits, vous avez probablement du code semblable dans votre fichier principal:

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

Cela signifie que «root» aussi doit être configuré en ajoutant les instructions suivantes:

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

Et maintenant, vos widgets devraient s’ajuster automatiquement selon leur configuration.
Voici le code complet de l’exemple:

#!/usr/bin/python

from tkinter import *
from tkinter import ttk

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

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

bouton1 = ttk.Button(cadre, text="Bouton1", command=lambda: print("Bouton1"))
bouton2 = ttk.Button(cadre, text="Bouton2", command=lambda: print("Bouton2"))
bouton3 = ttk.Button(cadre, text="Bouton3", command=lambda: print("Bouton3"))
bouton4 = ttk.Button(cadre, text="Bouton4", command=lambda: print("Bouton4"))
bouton1.grid(column=0, row=0, sticky=(N,S,E,W))
bouton2.grid(column=1, row=0, sticky=(N,S,E,W))
bouton3.grid(column=0, row=1, sticky=(N,S,E,W))
bouton4.grid(column=1, row=1, sticky=(N,S,E,W))

root.mainloop()

Bases de données Access

Je ne sais pas comment il est possible que quelqu’un chez Microsoft aie décicé qu’Access soit encore pertinant en 2018. Je peux comprendre qu’à un certain point dans le passé, il a été utile dans certains cas. Mais maintenant que l’informatique a évoluée au point où elle est en ce moment, comment une telle abberation peut-elle encore exister?

J’ai étudié l’informatique il y a quelques années et j’ai travaillé dans le domaine pendant quelques années par la suite, alors je considère avoir un niveau respectable de connaissances et d’expérience dans le domaine, et j’ai toujours de la difficulté à accomplir des tâches basiques dans ce logiciel. Je crois que Microsoft emploie de bons ingénieurs qui en connassaient beaucoup plus sur les ordinateurs et la programmation que je n’en connaîtrai de toute ma vie, alors comment Access peut-il encore exister?

Il y a quelques temps, j’ai eu à retourner dans Access pour accomplir quelques tâches que je décrirais de «simples», sans entrer dans les détails de ce en quoi cela consistait, disons que je devais bâtir une base de données et construire quelques formulaires et rapports qui rendraient les données utilisables pour le commun des mortels. Et j’ai presque échoué! J’aurais probablement obtenu un meilleur résultat plus rapidement en ayant codé le tout en C# et SQL.

Dans le passé, j’ai aussi eu à travailler avec d’autres versions plus vieilles, jusqu’à Access 97, et sincèrement, rien n’a changé durant ces 20 années, le logiciel est resté le même, seulement l’interface a évoluée (le ruban dans le haut, car le reste est toujours le même vieux gris). Les même fonctionnalités et façons de faire, sans amélioration en terme de convivialité.

Je suis en mesure de comprendre qu’il existe un marché pour un logiciel situé entre Excel et SQL Server, mais pourquoi est-ce que ce logiciel devrait être Access? Si je suis capable de me débrouiller dans Excel et dans SQL Server, pourquoi est-il si difficile de comprendre Access? Je n’ai jamais entendu parler d’un programmeur ayant une opinion favorable, ni même neutre par rapport à Access, nous le détestons tous.

Il doit bien y avoir une raison, c’est probablement parce que c’est un mauvais logiciel. En général, en tant que spécialistes de l’informatique, nous sommes en mesure d’utiliser la majorité des logiciels, que nous les connaissions déjà ou non. Parce que la majorité des applications suivent des règles similaires pour les fonctionnalités qu’elles fournissent. Mais Access réussi à s’en tirer en faisant les choses à sa façon sans se soucier des autres. (certains se souviendront peut-être d’un certain «Internet Explorer»…)

Peut-être que le logiciel survit malgré lui parce qu’il permet aux entreprises qui sont coincées avec celui-ci de continuer de fonctionner sans investir dans un vrai serveur de base de données? Malgré tout, pourquoi ne pas éliminer Access et le remplacer par une version plus conviviale de SQL Server et SQL Server Management Studio? Comme une sorte d’application autonome qui gère son propre serveur SQL local (s’il ne l’ont pas déjà fait) qui peut vivre sur un poste de travail et être transféré entre ordinateurs à volonté, exactement comme Access, mais avec les fonctionnalités et la prédictibilité d’un vrai serveur SQL. Ou sinon qu’ils développent leur propre interface pour SQLite, qui fait déjà un très bon travail à gérer des bases de données sans serveur.

Je ne m’attends pas à ce qu’un propriétaire d’entreprise ou que n’importe lequel employé non-informaticien apprennent SQL, mais si un logiciel offrait la convivialité d’Access couplée à un vrai moteur SQL sous le capot, à quel point cela serait-il génial pour nous pauvres programmeurs qui auront sans aucun doute à aider ces gens de toute façon tôt ou tard?