Bonjour,
Un très grand merci pour la réponse ultra-raide! Je suis impressionné et
il m'a fallu nettement plus de temps pour me représenter ce que cela
signifiait concrètement!
La suggestion m'intéresse effectivement. Je la comprends comme ça: je
regroupe toutes mes requêtes/instructions SQL dans un fichier spécifique
que Base peut exécuter ligne par ligne. Si le principe m'apparaît
presque clair, j'ai encore des questions:
* Quels formats de fichiers Base peut-il lire et exécuter de cette
manière, et comment indiquer à base de lire ce fichier pour en
exécuter les commandes?
Habitué au QBE d'Access, je ne sais pas très bien comment enchaîner les
instructions SQL dans ce fichier. Dans mon projet, je pensais enchaîner
les requêtes dans une logique de "pas à pas", chaque groupe traitant un
niveau de cas particuliers dont mon fichier d'origine est truffé,
aboutissant sur une table intermédiaire avant de passer au niveau
suivant.Pour schématiser, il s'agissant de d'abord repérer les
références de lignes (dont la longueur varie), puis repérer les types
d'écriture (groupes de 18 lignes) dont l'identifiant varie, puis repérer
les blocs d'info élémentaires dont la longueur et la place, voire la
ligne, varient. Chaque niveau demande plusieurs requêtes faisant parfois
appel à des tables de référence spécifiques pour d'abord repérer les
éléments déterminants des cas particuliers, puis les identifier et enfin
les exploiter. Je me suis vite familiarisé avec la commande CASEWHEN!
* Est-ce que je peux reproduire une telle cascade de requêtes dans un
fichier d'instructions SQL? Pour cela, il me faut au moins nommer
chaque requête (ce que je ne sais pas faire avec une commande SQL)
ou envoyer les résultats de chaque instruction SELECT dans une
table. Comment cela se fait-il avec HSQLBD, que j'utilise avec Base?
La clause SELECT INTO marche-t-elle dans ce cas?
* Ou alors me faut-il adopter une logique de sous-requêtes imbriquées?
Je suis prêt à faire ce pas méthodologique (un poil audacieux vu mon
niveau en SQL), mais je pense que je n'éviterai pas de devoir passer
par des tables intermédiaires - ou des vues - vu que je change de
niveau dans mon décorticage, passant de l'analyse des lignes à celle
des blocs ce qui me force à passer par celui des écritures (groupes
de lignes). J'utilisais beaucoup les tables intermédiaires dans ce
type de situations sur ACCESS. La question de savoir envoyer les
résultats des requêtes SELECT dans des tables se pose donc de toutes
façons.
Merci encore pour vos lumières, j'ai décidément besoin d'éclairages!
Étienne
Étienne Dollfus
20 rue du Village
CH-1273 Arzier
022 366 08 79
077 421 60 70
Le 26.02.2018 à 18:28, Thierry Jeanneret a écrit :
Bonjour,
Si vous décortiquez de toutes façons les fichiers reçus, puis-je vous suggérer de générer ligne à
ligne les requêtes SQL d'insertion et de les mettre dans un fichier dédié ?
Vous pouvez ensuite l'exécuter par l'option SQL offerte par Base, ou par une macro qui le lira
ligne à ligne et exécutera les commandes qu'il y trouvera.
J'ai au cours de ma carrière chargé des tables de plusieurs milliers de lignes ainsi, lorsque la source était
vraiment "bizarre".
Thierry
Le 26 févr. 2018 à 18:09, demande_aide_fr@libreoffice.org a écrit :
Bonjour
Voici une nouvelle question envoyée à l'aide du formulaire de demande d'aide
(http://fr.libreoffice.org/get-help/poser-une-question/).
Si vous répondez, merci de penser à utiliser la fonction "répondre à tous" de votre logiciel de
courrier électronique de façon que le demandeur reçoive une copie de votre réponse.
Email:: atn@bluewin.ch
Sujet:: Base : mise à jour des vues
OS:: Windows 7
Version:: 5.4.x
Question:: Bonjour,
Pour me lancer dans l’utilisation de LibO Base, j’ai décidé d’importer des fichiers bruts (en
format MT940 de mon e-banking, format texte qui demande un gros travail de traitement) auxquels je
souhaite faire subir une série de transformations pour sortir des données à intégrer dans ma
comptabilité sur calc. A chaque importation c’est entre un et quatre fichiers qu’il faut importer,
une opération que je veux pouvoir répéter, régulièrement ou pas. J’ai fait ce genre d’opération sur
Access, sur d’autres types de fichiers, mais j’ai très envie de basculer du côté libre !
Pour le traitement des données j’ai une cascade de requêtes, comptez autour de quinze, ce que LibO
n’aime pas. J’ai compris que je peux faire des vues qui stabilisent la cascade et lui permettent de
se dérouler comme je veux… Très bien pour la première fois. Mais comment faire quand je passe à une
nouvelle importation ? Je pensais n’avoir qu’à indiquer à la première requête de reprendre les
données d’une autre table. En SQL (que je balbutie), il me suffit de changer le nom de la table
dans la clause FROM.
Oui, mais comment la suite du processus se met-elle à jour avec les données de la nouvelle table
brute ? Dois-je refaire toutes les vues ? Y a-t-il moyen de monter une macro pour cela ? Il est
essentiel, dans un tel projet, que le traitement soit simple à faire et je veux donc limiter les
manips au strict nécessaire.
Merci pour vos lumières !
Étienne
--
Envoyez un mail à users+unsubscribe@fr.libreoffice.org pour vous désinscrire
Les archives de la liste sont disponibles à https://listarchives.libreoffice.org/fr/users/
Tous les messages envoyés sur cette liste seront archivés publiquement et ne pourront pas être
supprimés
--
Envoyez un mail à users+unsubscribe@fr.libreoffice.org pour vous désinscrire
Les archives de la liste sont disponibles à https://listarchives.libreoffice.org/fr/users/
Tous les messages envoyés sur cette liste seront archivés publiquement et ne pourront pas être
supprimés
Context
Privacy Policy |
Impressum (Legal Info) |
Copyright information: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License.
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (
MPLv2).
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our
trademark policy.