Import Dbf vers AC-2013

Version imprimable

24/11/2014, 19h03
Msuuo

Import Dbf vers AC-2013

Bonjour à tous.

Je poste ici après avoir pas mal cherché dans plein de forums pour réaliser ce que je veux faire et je vous remercie de votre attention.
Je voudrais disposer de l'ensemble de la base de données DADS fournie par l'INSEE à cete adresse : http://www.insee.fr/fr/themes/detail...chargement.htm
Ceci étant dans le but d'étudier plus de 5 variables croisées sur 2millions de lignes sur le marché du travail.
Seulement l'export permis par l'Insee ne se fait qu'en format dbf au motif je cite "Ce format assure une compatibilité la plus large possible avec les gestionnaires de bases de données du marché (Access, Paradox par exemple,...),".

Le problème est que je n'ai que la version 2013 d'office sur mon poste de travail et qu'access 2013 n'accepte plus l'import de fichier dbf... Excel l'accepte toujours mais étant limité en nombe de ligne (près d'un million quand ma base en fait plus de deux...) je ne peux passer par excel pour étudier cete base.
J'ai donc essayé de passer par openoffice avec base mais je ne peux pas non plus exporter cette base même si je parviens à l'afficher partiellement.
J'ai essayé après de m'aventurer dans des SGBD plus complexes avec Mysql toujours dans le but de pouvoir utiliser mon format dbf sous access mais n'étant pas du tout programmeur, j'ai pas compris grand chose (pareil pour les normes ODBC...).

Je suis donc à l'écoute de vos conseils pour m'aider à faire ce qui me semblait simple si j'avais access 2010...
Merci d'avance pour votre lecture et vos réponses.
26/11/2014, 18h42
marot_r
Bonjour

Apparement ont ne peut plus importer de fichier dbf avec Access 2013 ... pas cool mais compréhensible vu l'âge du format.

J'ai croisé la suggestion d'installer le runtime A2010 et d'utiliser MySQL (ici : http://stackoverflow.com/questions/2...s-to-dbf-files).

En réalité les fichiers DBF sont des fichiers texte avec des enregistrements et des champs de longueur fixe et une entête qui décrit sa structure.

Si tu connais la structure de la base, tu peux aller lire les en passant par la lecture binaire de fichier.

L'algorithme est assez simple :
1. Ouvrir le fichier en mode binaire
2. Sautrer l'entête de description
3. Lire jusqu'à la la longueur du fichier des blocs de X octets,
4. Découper ces blocs en champs.
  Ajouter un enregistrement dans la table de destination et complétre ses champs.
5. Fermer le fichier
Est-ce que l'INSEE décrit le format de ses données ?
Si oui, la solution par lecture directe est sans doute jouable.

Est-ce que tu as contacter l'INSEE pour savoir si il pévoyait un autre format (ex : xml) ?

A+
27/11/2014, 08h18
pyloupylou

et en passant par un connecteur odbc ?
05/12/2014, 15h02
Msuuo
Citation:
Envoyé par marot_r

Bonjour

Apparement ont ne peut plus importer de fichier dbf avec Access 2013 ... pas cool mais compréhensible vu l'âge du format.

J'ai croisé la suggestion d'installer le runtime A2010 et d'utiliser MySQL (ici : http://stackoverflow.com/questions/2...s-to-dbf-files).

En réalité les fichiers DBF sont des fichiers texte avec des enregistrements et des champs de longueur fixe et une entête qui décrit sa structure.

Si tu connais la structure de la base, tu peux aller lire les en passant par la lecture binaire de fichier.

L'algorithme est assez simple :

Ouvrir le fichier en mode binaire
Sautrer l'entête de description
Lire jusqu'à la la longueur du fichier des blocs de X octets,

Découper ces blocs en champs.
Ajouter un enregistrement dans la table de destination et complétre ses champs.
Fermer le fichier

Est-ce que l'INSEE décrit le format de ses données ?
Si oui, la solution par lecture directe est sans doute jouable.

Est-ce que tu as contacter l'INSEE pour savoir si il pévoyait un autre format (ex : xml) ?

A+
Merci pour ta réponse et désolé pour le retard de ma réaction ;)

J'ai insallé le runtime d'access 2010 mais comme j'ai déja ACCess 2013 il ne me le prend pas et puis runtime a des fonctionnalités limitées.

Je connais la structure de ma base telle que définie par l'insee à cette page : http://www.insee.fr/fr/ppp/bases-de-...salaries10.pdf
En gros deux types de champs du caractère et du numérique.
Mais ensuite, je ne sais pas trop quels traitements réaliser : j'ai transformé mon dbf en txt via le bloc notes mais l'import marche pas mieux. J'ai telechargé hexa editor pour faire un fichier binaire mais autant je comprends un petit peu les fichiers texte autant les fichiers binaires je ne comprends pas la structure (à part du 0 et 1 ). Serait-ce possible d'avoir plus en détail la procédure à suivre. Merci d'avance.

J'ai envoyé un mail à l'insee pour savoir les possibilités d'evolution et ils m'ont uniquement répondu "les fichiers détails sont uniquement disponibles aux formats dBase et Beyond 20/20®."...
05/12/2014, 16h43
marot_r

OK au temps pour la modernité.

Je vais regarde ce que je peux faire pour toi ce weekend.

Je t'envoi mon adresse perso par message privé.

A+
05/12/2014, 16h55
chrtophe

Beaucoup plus simple : passer par Excel, Excel ouvre le dbf, avec un peu de bol, ils l'ont pas enlevé d'excel 2013, (je l'ai pas, je peux pas vérifier).
08/12/2014, 09h46
Msuuo

Citation:

Envoyé par chrtophe

Beaucoup plus simple : passer par Excel, Excel ouvre le dbf, avec un peu de bol, ils l'ont pas enlevé d'excel 2013, (je l'ai pas, je peux pas vérifier).

Ca aurait été une solution mais ma base contient plus de 2 millions de lignes et même avec l'amélioration récente d'excel cela ne suffit pas puisque excel2013 supporte 1 048 576 lignes (contre 56000 auparavant).
Comme je ne sais pas quelle partie de la base est tronquée et quelle partie est gardée je ne peux me satisfaire de cette solution. Merci quand même !

Citation:

Envoyé par marot_r

OK au temps pour la modernité.

Je vais regarde ce que je peux faire pour toi ce weekend.

Je t'envoi mon adresse perso par message privé.

A+

Je t'ai répondu, Merci ;)

Pour le découpage :

module mdlChargerDonneesBrute

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
Option Compare Database
Option Explicit
 
Public Sub ChercherDonneesBrutes()
    Dim db As DAO.Database: Set db = CurrentDb
    Call db.Execute("delete * from tblDonneesBrut", dbFailOnError) 'Vide la table de destination
 
    Dim r As DAO.Recordset: Set r = db.OpenRecordset("tblDonneesBrut", dbOpenDynaset)
 
    Dim cheminFic As String: cheminFic = CurrentProject.Path
    Dim nomFic As String: nomFic = "salaries10.dbf"
    Dim numFic As Long: numFic = FreeFile()
 
    Dim lf73 As String * 73 'Les données font 73 de long apparament
    Dim lf1 As String * 1
 
    Dim cptLigne As Long
 
    Open cheminFic & "\" & nomFic For Binary As numFic
 
    Get #numFic, 961, lf1 'Saute l'entête
 
    Do While Loc(numFic) < LOF(numFic)
        Get #numFic, , lf73 'Lit les données
        cptLigne = cptLigne + 1
        Debug.Print cptLigne, lf73: DoEvents
        r.AddNew
        r![NumLigne] = cptLigne
        r![Donnees] = lf73
        r.Update
    Loop
 
    Close #numFic
    r.Close: Set r = Nothing
    db.Close: Set db = Nothing
 
End Sub

La table de réception est :

tblDoneesBrut
* NumLigne, entier long
* Donnees, mémo (mais on pourrait utiliser un champ texte)

A+

09/12/2014, 18h32
marot_r

Pour le découpage du champ on peut utiliser Mid(Texte, PositionDebut, Longueur) et les fonctions de conversion si ce n'est pas du texte :
CDate(), CLng(), CDbl(), CBool().

ex : CDate(Mid([Donnees]),1,10) va convertir les 10 premiers caracatères en date.

On peut faire cela avec une requête d'ajout ou un bout de code VBA.

Les fonctions de conversions sont les mêmes qu'en Excel.

A+

1 pièce(s) jointe(s)

Bonjour,

Tout d'abord merci pour ce code qui m'avait bien aidé pour l'edition 2010.
Mais après changement par l'Insee de sa structure, il s'avère que pour l'édition 2011, certains champs sont vides et cela fausse le champs données puisque chaque ligne ne fait plus forcement 73 de long (voir fichier xls joint)
Une piste pour un nouveau code serait de se servir du dernier champ (collonne AD) de pondération puisqu'il est toujours égal à 12 et qu'il ya un espace après dans les données brutes d'access
Il faudrait donc garder le meme code sauf que dans la boucle où on lui demande de changer de ligne à chaque fois qu'il atteint 73, là on lui demande de changer de ligne à chaque fois qu'il trouve 12 et un espace. Sauf que je pense bien que c'est après le do while qu'il faut changer quelque chose mais je ne connait pas la fonction qui peut trouver ou lire la chaine "12 ".
Merci encore d'avance.
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 Option Compare Database Option Explicit Public Sub ChercherDonneesBrutes() Dim db As DAO.Database: Set db = CurrentDb Call db.Execute("delete * from tblDonneesBrut", dbFailOnError) 'Vide la table de destination Dim r As DAO.Recordset: Set r = db.OpenRecordset("tblDonneesBrut", dbOpenDynaset) Dim cheminFic As String: cheminFic = CurrentProject.Path Dim nomFic As String: nomFic = "salaries10.dbf" Dim numFic As Long: numFic = FreeFile() Dim lf73 As String * 64 'Les données font 64 de long maximum apparement Dim lf1 As String * 1 Dim cptLigne As Long Open cheminFic & "\" & nomFic For Binary As numFic Get #numFic, 961, lf1 'Saute l'entête Do While Loc(numFic) < LOF(numFic) Get #numFic, , lf73 'Lit les données cptLigne = cptLigne + 1 Debug.Print cptLigne, lf73: DoEvents r.AddNew r![NumLigne] = cptLigne r![Donnees] = lf73 r.Update Loop Close #numFic r.Close: Set r = Nothing db.Close: Set db = Nothing End Sub

26/08/2015, 16h50
marot_r

Citation:

Mais après changement par l'Insee de sa structure, il s'avère que pour l'édition 2011, certains champs sont vides et cela fausse le champs données puisque chaque ligne ne fait plus forcement 73 de long (voir fichier xls joint)

Je suis surpris, car normalement les enregistrements dans le fichier sont tous de la même longueur champ vide ou pas.
Il faut prendre un éditeur hexadécimal ou binaire pour regarder le contenu du fichier et ainsi déduire sa structure.

En mode binaire on ne peut pas facilement gérer des enregistrements de taille variable.
Pour les enregistrements de taille variable, la seule méthode que je connaisse c'est de lire caractère par caractère pour reconstituer en mémoire l'enregistrement puis le traiter.
Cela suppose qu'on a un indicateur de fin d'enregistrement ou quelque chose qui permet de savoir qu'on vient de changer.

Pour tester certain caractères on peut utiliser ASC() qui donne le code ascii (entre 0 et 255) du caractère.

Et je n'ai pas le temps de travailler à cela.

A+
26/08/2015, 18h20
rnd

Bonjour,

je viens apporter ma petite suggestion, à tu essayé d'exporter les dbf avec DBFViewer puis importer tes export dans Access.

page de DBFViewer http://www.alexnolan.net/software/dbf.htm

Je ne savais pas nom plus qu'il avait aussi supprimer l'import (et j'imagine aussi la liaison) avec les DBF; je sens que je vais rester encore un certain temps avec 2010 moi :mouarf:

Ce qui est drôle c'est que j'ai découvert il y a peu de DBASE est officiellement toujours vivant en version 10 sur win 32/64 http://www.dbase.com/

Cdt, Renaud.
26/08/2015, 19h28
Msuuo

2 pièce(s) jointe(s)

Merci, effectivement, ce n'est pas les champs vides qui faussaient le calcul et rendaient la table illisible (cela donnait la première pièce jointe)

Mais plutot un changement dans la longueur d'un champ entre la version 2010 et 2011 que j'ai trouvé car je trouvais ca surprenant aussi. Du coup en faisant des données d'une longueur de 75 et non pas de 73 tout marche bien !
(voir ci dessous)
Pièce jointe 186457

Merci de la réponse en tout cas !
26/08/2015, 19h34
Msuuo

Citation:

Envoyé par rnd

Bonjour,

je viens apporter ma petite suggestion, à tu essayé d'exporter les dbf avec DBFViewer puis importer tes export dans Access.

page de DBFViewer http://www.alexnolan.net/software/dbf.htm

Je ne savais pas nom plus qu'il avait aussi supprimer l'import (et j'imagine aussi la liaison) avec les DBF; je sens que je vais rester encore un certain temps avec 2010 moi :mouarf:

Ce qui est drôle c'est que j'ai découvert il y a peu de DBASE est officiellement toujours vivant en version 10 sur win 32/64 http://www.dbase.com/

Cdt, Renaud.

Merci de ta réponse, je vais étudier de plus près DBFviewer surtout si c'est une License Free. Sinon, les codes fournies par marot_R marchaient bien mais les calculs étaient très long.
Ce que je trouve navrant par contre c'est que l'Insee se borne à utiliser ce format alors que leurs données sont des mines d'or peu exploitables. (Utiliser beyond pour faire des requetes c'est du sport^^)

Merci en tous cas pour vos réponses :)