Version imprimable
Bonjour,
Je cherche à remplacer une chaine de caractères #toto# dans un ordre SQL que je ne peux pas convertir en majuscules ou minuscules (à cause par exemple de l'utilisation de "format").
exemple :Et forcément, je peux avoir #toto# ou #Toto# ou autres joyeusetés.Code:select #toto# from LaTable where format(LaDate, 'yyyyMM') = format(getdate()-1, 'yyyyMM')
Quelqu'un aurait-il une solution ?
Merci
Salut
Dans "SELECT #toto# FROM...", #toto# est le nom d'un des champs de la table (ce n'est pas une variable). Du coup, difficile de comprendre ce que vous cherchez à faire.
- W
Il s'agit d'un exemple, mais l'idée est de remplacer #toto# par un nom de champ (ou une variable dans la clause where : where LeChamp = #toto#)
#toto# peut donc valoir 2, titi, 'tut', '2023-12-21', ...
Mais malheureusement, #toto#peut être écrit #Toto#, #TOTO#, #ToTo#, ...
Bonjour,
Quel est le rapport avec Python ? En plus on ne voit pas de code Python...
Si vous souhaitez utiliser une fonction SQL de remplacement dans votre requête SQL, il faudrait connaître votre SGBD, car cela peut varier concernant la solution à employer.
Ce que vous essayez de faire peut-être, car je trouve votre prose pas très compréhensible, c'est d'utiliser une variable python dans une requête SQL qui serait placée à l'endroit où se trouve #toto# ?
Pour PostgreSQL ou MySQL ou SQLite3
Code:
2
3
Dans une requête SQL il y a la partie chaine de caractères et la partie données où il faudra convertir un type python en type de la colonne de la table.Citation:
Envoyé par Kloun
Du coup, on ne va pas remplacer le xyz d'un "SELECT xyz" de la même façon que le xyz dans "WHERE le_champ=xyz" (et côté Python, on va utiliser d'autres moyens).
Tout ça est expliqué dans la documentation de sqlite3 qui est la référence de l'API Python pour les bases de données (i.e. interface utilisée aussi par les autres SGDB-R)
Normalement quand vous venez ici, vous êtes supposé avoir ouvert un tuto., lu la documentation, histoire d'utiliser un vocabulaire technique compréhensible (ça aide de savoir de quoi qu'on cause!).
- W
S'il s'agit de remplacer le nom d'une colonne :
Comme la plupart des SGBS ne sont pas sensible à la casse lorsqu'il s'agit de nom de colonnes, il n'y pas nécessairement de raison de s'en soucier.
Et si les nom des colonnes sont sensible à la casse, il est toujours possible d'établir un dictionnaire dont la clé est le nom de la table en minuscule et où la valeur est le véritable nom de la table.
Sil s'agit de remplacer une valeur texte dans une clause WHERE :
La plupart des SGBD possède des routines pour minimiser ou maximiser une valeur.
Exemple avec SQLite :
Code:
2
Bonjour
Postgres, lui, il l'est. Mais cela dépend aussi de la façon de nommer les choses. Si par exemple on crée une table create table "Facture" (...) la table se nommera "Facture". Si maintenant on la crée dans cette syntaxe create table Facture (...) la table se nommera "facture". Et il en va de même avec les noms des colonnes, vues, index, fonctions et autres.Citation:
Envoyé par popo
Là je suis plus réservé. C'est quand-même un détail assez important...Citation:
Envoyé par popo
Cela fait perdre l'avantage des index. S'il y a un index sur "myfield", il ne sera pas pris en compte.Citation:
Envoyé par popo
Notez que j'ai écrit "la plupart" et "pas nécessairement"...
Cela dépend du SGBD.
Exemple :
SQL Server n'est pas sensible à la casse et il n'est donc pas nécessaire de s'en soucier, et donc ce n'est pas important
MySQL peut se paramétrer pour ne pas l'être donc en s'en souciera au besoin, et donc cela aura une importance ou non selon le paramétrage.
Postres est sensible à la casse, donc ici, oui c'est important.
Bref, merci de ne pas faire d'un cas spécifique une généralité.
De toute façon, le PO n'a toujours pas dit quel système, il utilise.
Pour l'index, je dirais qu'il fait éviter de faire n'importe quoi.
Indexer une colonne où la casse est importante ce n'est pas anodin.
De mon côté je n'ai même pas compris comment il pouvait ne pas connaître le champ qu'il veut sélectionner.Citation:
Envoyé par popo
Oui ça c'est vrai. Et de façon plus générale, avoir un champ non normalisé rend difficile ensuite de bien le gérer. Par exemple pour mes tables, les noms sont toujours en majuscules. Et je mets des triggers before insert or update qui convertissent les valeurs en majuscule. Ainsi un insert into personne values('popo') devient automatiquement insert into personne values('POPO').Citation:
Envoyé par popo
Mais ça c'est une option sympa de Postgres et je ne sais pas si sqlite connait cette notion de trigger.
C'est géré : https://sqlite.org/lang_createtrigger.html