Certaines applications utilisent des fichiers HFSQL classic en local lorsqu'elles ne sont pas connectées aux données de la base centrale de l'application. Le plus souvent ces données locales sont synchronisées avec le serveur par la réplication.

Ces données HFSQL classic sont parfois "découpées" en de multiple fichiers d'une même structure, par exemple un fichier par mois, par semaine, voir par jour. Par exemple pour un logiciel de caisse on pourra avoir choisi de créer un fichier (inaltérable) de tickets par jour :

Si ce choix offre certains avantages comme un espace de stockage minimal, il a part contre l'inconvénient pour le développeur de ne pas faciliter les interrogations lorsque l'on veut par exemple trouver une donnée pouvant être dans plusieurs fichiers physiques. Dans l'exemple de la caisse avec un fichier de tickets par jour, on pourrait vouloir trouver les tickets d'un certain montant créés entre deux dates, et cela depuis le logiciel de caisse, donc avant d'avoir remonté l'ensemble des données dans la base centrale.

C'est là que le type source de données s'avère des plus pratiques, puisqu'il peut s'utiliser comme un tableau. On peut donc à partir d'une liste de fichiers énumérés sur disque dans le dossier local des données, créer un tableau de source de données :

Comme le montre la trace ci-dessus avec la récupération du nombre d'enregistrement, les éléments du tableau permettent donc d'accéder directement à l'un des fichiers sur disque. On peut donc avoir tout type de traitement utilisant ces fichiers...

Recherches directes dans les fichiers :

Création d'un interrogation via une UNION ALL d'une requête SQL :

Autres billets sur le thème source de données :

• Nommage automatique des sources de données : quel choix utiliser dans vos projets ?
• Lire le contenu d'un fichier de données HFSQL, sans qu'il ne soit inclus dans l'analyse.
• Utilisation d'une requête exécutée via le type requête SQL, dans une nouvelle requête ...