| Accueil WEB JCS| Sommaire| Avertissement | Historique des Versions | Installation |
Quelques conseils pour mieux utiliser Rescue for 4D Data |
| Menus | Préferences | Navigator | Doctor | Editor | Viewer |
| 4th Dimension | Structure du Data 4ème Dimension |
4ème Dimension est un Système de Gestion de Base de Données Relationnelles (SGBDR) édité par la société ACI SA.
4ème Dimension crée 2 fichiers distincts :
- l'un contenant les données saisies par les utilisateurs et éventuellement les index des rubriques,
- l'autre contenant la structure de la base de données, c'est-à-dire tous les objets créés par le développeur.
La maintenance de la base s'en trouve largement simplifiée puisque le fichier contenant la programmation et le fichier contenant les données saisies sont totalement distincts.
Malheureusement et trop souvent, il arrive qu'un problème (Bug, plantage machine, coupure de courant,...) puisse rendre inutilisable soit :
- le fichier de structure : La cause principale en est un mauvais enregistrement des ressources internes de 4D
Ce problème provoque, dans le meilleur des cas, des réactions "bizarres" de la base, et, dans le pire des cas, lors de l'ouverture de la structure, l'affichage d'un message "tentative de lecture au-delà de la fin du fichier" et... la perte d'une journée (ou plus) de travail. Les données d'une base sont entièrement à la merci d'une bonne structure. Une structure endommagée peut endommager les données. Nous avons Rescue For 4D.
- le fichier de données : ce sont principalement les index qui sont touchés. La cause première est la présence de caractères interdits dans le contenu des champs. Ces caractères interdits provoquent, dans le meilleur des cas, des résultats de recherche erronés, l'impossibilité de stocker des fiches (ou leurs modifications), et dans le pire des cas... une bombe!
A noter que 4D Util est alors... inutile!
Pour vous éviter de vérifier votre base trop souvent, nous avons créé
Rescue for 4D Data.
![]()
Structure du Data 4D
Le graphe ci dessus montre, en résumé, la structure d'un data 4D.
DSH Data Segment Header. Entête du fichier de données. Il contient les informations principales de la base ainsi que les liens vers les autres objets.FIT File Information Table. Contient les informations sur les tables et leur organisation. FI Contient le détail de chaque table (nombre de fiches, position, delete table, etc...). PRA Primary Record Address. Adresse primaire des enregistrements. Pointe sur les SRA. Une PRA peut pointer sur 4096 SRA. SRA Secundary Record Address. Adresse secondaire des enregistrements. Pointe sur les enregistrements. Une SRA peut pointer vers 1024 enregistrements en v5 ou 512 en v6. IHT Index Headers Table. Contient les informations sur les index et leur organisation. II Index Informations. Contient les détails de chaque Index (nombre d'index, position, etc...). PIAT Primary Index Address Table. Adresse primaire des index. Pointe sur les SIAT. Une PIAT peut pointer sur 4096 SIAT. SIAT Secondary Index Address Table. Adresse secondaire des index. Pointe sur les pages d'index. Une SIAT peut pointer vers 4096 Page d'index. IP Index Page. Les index sont contenus et classés dans ces pages. - Structure d'un Enregistrement
![]()
Header Record Cette zone contient des informations sur la fiche (Checksum, numéro de fiche, taille, etc).Field Information Contient la position et le type de chaque champ sauf les champs de taille variable 'Texte, Picture, Blob, et Sous-fiche'. Data Of Fixed Fields On trouve ici les données des champs de taille fixe (alpha, num, entier, etc)... Data Of SubFields Ici, on peut trouver sous forme de "sous-enregistrement" toutes les fiches d'une sous-structure, voire même toutes les fiches de la sous- structure de la sous-structure de la... Data Of Variable Fields Les données des champs à taille variable comme les 'Textes, Blobs, Pictures'. Cependant, il n'y a pas de pointeur sur ces champs, ce qui force 4D à les parcourir tous avant d'arriver à celui de votre choix. Commentaire sur les Sous-structures :
Vu du Développeur :
- 4D ne sait pas construire des états semi-automatiques sur les sous-structures.
- Il ne sait pas non plus construire des graphes sur les sous-structures sans passer par un tableau.
- Les Import/Export de sous-structures passent forcément par de la programmation.
- Une fois créées, les sous-structures deviennent indestructibles.
- Il est impossible de faire des sous-sélections de sous-structures.
- Il est impossible d'afficher dans une liste de sous-structures plus de 32000 lignes : c'est une limite du List Manager de 4D.
Vu de 4D :
- Les sous-structures sont des fiches dans les fiches. Donc, si une fiche est endommagée, vous perdez toutes les sous-fiches.
- Comme il n'y a pas de pointeur de sous-fiches, 4D est obligé de parser l'ensemble des sous-fiches avant d'arriver à celle que vous désirez consulter.
- Si une seule de vos sous-fiches est endommagée, c'est la fiche entière qui ne pourra pas être lue.
- Les champs de taille variable se trouvent après les sous-fiches ; pour y accéder, 4D devra lire la totalité des sous-fiches.
- 4D ne sait pas lire une partie de fiche quand vous demandez des données ou quand vous faites une recherche ou un tri.
Ce défaut oblige 4D à charger en mémoire la fiche entière, et donc, ses sous-fiches. Cela demande du temps et bien sûr, de la place mémoire.
Si la place n'est pas disponible dans le cache à ce moment là, 4D le Flushe. Nous vous laissons imaginer la perte de temps pour accéder à un simple champ...- La modification d'un seul champ, dans ce genre de fiche, provoque d'abord la réorganisation mémoire, puis disque, de TOUTE la fiche.
- Lorsque dans une liste 4D, on affiche un champ de taille variable, type Texte par exemple, l'affichage est CONSIDERABLEMENT ralenti par la présence de sous- fiches.
- Si on multiplie le nombre de PIAT(512) * SIAT(512) * IP(64) = 16 777 216 d'index sur un champ. Soit le nombre maximum de fiches par table.
Or, une fiche peut contenir de 0 à x sous-fiches. Imaginons une base de 1,2 Millions d'enregistrements contenant chacuns 20 sous-fiches : cela donne 24 millions de sous- fiches. Si un champ des sous-fiches est indexé, 4D NE POURRA PAS CREER L'INDEX.
Ces remarques ne démontrent-elles pas qu'ACI :
- Ne pensait pas aux sous-fiches comme une solution vraiment viable ????
- N'a pas pensé qu'il y aurait, un jour, des bases avec des tailles aussi importantes ;-))
- N'a pas fait les sous-fichiers pour durer dans le temps ;-)))))))
Avancée | Aide
| Accueil WEB JCS| Sommaire| Avertissement | Historique des Versions | Installation |
Quelques conseils pour mieux utiliser Rescue for 4D Data |
| Menus | Préferences | Navigator | Doctor | Editor | Viewer |
| 4th Dimension | Structure du Data 4ème Dimension |