#1 Thu 05 April 2018 15:06
- ChristopheV
- Membre
- Lieu: Ajaccio
- Date d'inscription: 7 Sep 2005
- Messages: 3195
- Site web
données MAJIC 2017 BATI
Bonjour,
Le fichier descriptif des données bâti 2017 fourni par la DGFiP comporte une grossière erreur.
Le champ valeur locative de l'année, (ou DVLPERA de l'enregistrement 21 pour les fans d'acronymes incompréhensibles et autres ), n'est pas codé sur 9 mais 7 caractères .......
Bref comme d'habitude c'est la faute à personne ... (c'est quand qu'il embauche des pro dans leur service informatique à la DGFiP ?).
Dernière modification par ChristopheV (Thu 05 April 2018 21:22)
Christophe
L'avantage d'être une île c'est d'être une terre topologiquement close
Hors ligne
)#3 Thu 05 April 2018 21:33
- ChristopheV
- Membre
- Lieu: Ajaccio
- Date d'inscription: 7 Sep 2005
- Messages: 3195
- Site web
Re: données MAJIC 2017 BATI
Bonjour,
@christian : lol en plus il y en a (avait) des gens compétents non ? (mais ceux là c'est pas des gens formatés "centrale").
Mais quand tu passes ta journée a reprendre un code qui fonctionnait, en mode debugg car tu sais pas quelle bêtise tu vas trouver, et qu'en plus t"es dans l'urgence car les ministres (oui les vrais) arrivent et qu'il faut des chiffres sur la situation foncière, t'as juste une envie, c'est de faire comme avec ton animal de compagnie préféré, lui mettre le nez dedans pour qu'il comprenne ...
Alors mauvais caractère peut-être, mais dans n'importe quelle boite privée une perte de productivité pareille en raison d'un fournisseur donnerait des débats autrement plus incisifs et je parle pas des conséquences financières. Tant que dans la fonction publique les mecs qui prennent des décisions ne seront pas responsables (donc virables) de celles ci ...
Dernière modification par ChristopheV (Thu 05 April 2018 21:38)
Christophe
L'avantage d'être une île c'est d'être une terre topologiquement close
Hors ligne
#4 Fri 06 April 2018 08:52
- Alban NOIR
- Participant occasionnel
- Date d'inscription: 7 Sep 2005
- Messages: 32
Re: données MAJIC 2017 BATI
Bonjour,
J'ai vérifié des matrices 2017 de plusieurs départements. Pour l'article 21, DVLPERA est bien stocké sur 9 caractères.
Dernière modification par Alban NOIR (Fri 06 April 2018 09:01)
Alban
Hors ligne
#5 Fri 06 April 2018 08:54
- yartostout
- Participant assidu
- Lieu: Bretagne
- Date d'inscription: 24 Jun 2015
- Messages: 173
Re: données MAJIC 2017 BATI
Profite-en pour en parler directement aux ministres Christophe 
Sans déc, comment ça se passe pour la correction de ce type d'erreur ? Ils refont un millésime ?
Dernière modification par yartostout (Fri 06 April 2018 08:54)
Hors ligne
#6 Fri 06 April 2018 09:21
- ChristopheV
- Membre
- Lieu: Ajaccio
- Date d'inscription: 7 Sep 2005
- Messages: 3195
- Site web
Re: données MAJIC 2017 BATI
Bonjour,
J'ai vérifié des matrices 2017 de plusieurs départements. Pour l'article 21, DVLPERA est bien codé stocké sur 9 caractères.
Merci d'avoir vérifié sur d'autres départements. (je n'en ai pas la possibilité).
En revanche je n'invente rien, et dans mes données, si je fais un substring(maligne,69,9) je récupère comme "EP" pour les deux derniers caractères, qui correspondent à l'exonération, donc au champs suivant (NB en VB une chaîne commence à 0 pas à 1 d'où le 69 et pas 70). Comme je le cast() direct en entier forcément ça plante.
Après plusieurs heures de contrôle, il s'avère que c'est uniquement UN enregistrement qui est incorrect. Pourquoi ? Peut-être une anomalie dans l'export. Sachant que mon fichier provient du CD-ROM officiel et que je n'ai fait que le copier puis l'extraire avec l'outil fourni.
D'une manière ou d'une autre c'est pas la première fois que nous constatons une différence entre ce qui est écrit dans le fichier descriptif et la réalité informatique du fichier. Jusqu'à ce jour c'était des arguties de spécialistes, mais cela n'avait jamais été un truc aussi gros. D'où ma mauvaise humeur.
Christophe
L'avantage d'être une île c'est d'être une terre topologiquement close
Hors ligne
#7 Fri 06 April 2018 17:48
- Alban NOIR
- Participant occasionnel
- Date d'inscription: 7 Sep 2005
- Messages: 32
Re: données MAJIC 2017 BATI
Si tu parles de
Code:
substring(maligne,69,9)
c'est probablement qu'on est déjà dans une base de données. Le fichier à donc déjà été manipulé/converti au moins une fois.
Pour être certain de l'origine de l'erreur il faudrait vérifier directement dans le fichier du bâti à la ligne concernée car on peut aussi imaginer qu'il y ait un bug dans la/les premières étapes de traitement que tu réalises.
Alban
Hors ligne
#8 Fri 06 April 2018 22:16
Re: données MAJIC 2017 BATI
Bonsoir,
Je suppose que Christophe charge le fichier brut dans une table comportant une seule colonne (un enregistrement pour chaque ligne). Donc pas d'autre traitement que la lecture du fichier texte et l'INSERT de chaque ligne.
Jean-Marie
Azimut
Hors ligne
#9 Mon 09 April 2018 09:37
- ChristopheV
- Membre
- Lieu: Ajaccio
- Date d'inscription: 7 Sep 2005
- Messages: 3195
- Site web
Re: données MAJIC 2017 BATI
Bonjour,
Merci du suivi.
Je suis reparti depuis le CD d'origine. Extraction directement avec 7-zip. Apparemment pas de soucis, il n'y a plus la ligne en erreur.
J'ai manifestement travaillé sur un fichier corrompu la première fois.
Pour répondre à Jmarsac et Alban Noir la première phase se réalise en .NET. Ouverture des fichiers textes en mode lecture ligne à ligne, chargement dans des tables temporaires avec réplication des liens hiérarchiques de la base MAJIC, par exemple templocaux avec temppev. Donc c'est bien une lecture directe du fichier mais pour une inscription temporaire légèrement plus évoluée.
L'ensemble est ensuite transformé dans le modèle final par un script SQL.
Je profite du sujet pour une remarque (apaisée), dans le cadre d'une programmation efficace, il serait plus simple lors de l'ajout de nouveau champs dans les données MAJIC de ne pas le faire par insertion mais par ajout à la fin.
Ceci permet de garantir le fonctionnement de code plus anciens.
Christophe
L'avantage d'être une île c'est d'être une terre topologiquement close
Hors ligne
