Lorsqu'on lance l'application en mode ligne de commande via une autre application, le dialogue avec cette application pouvait provoquer des plantages.
Désormais, on utilise un canal dédié à chaque lancement que l'on indique avec le paramètre /Z=nom où nom est le nom de la zone mémoire partagée entre les deux applications.

Technique : 
- Désormais, on ouvre une zone mémoire différente par lancement de LDETLFB
- On protège la lecture / écriture via un sémaphore (SEM_ + <Nom zone mémoire>)
- Si on n'arrive pas à écrire sur le sémaphore au bout de 10 centièmes de seconde, on saute le message.

Il est désormais possible de renvoyer une valeur booléenne dans la fonction de renommage pour indiquer si le champ doit être actif ou non.
Il suffit simplement d'utiliser la syntaxe de retour multiple de WinDev.

Par exemple :
NomChamp est une chaine = "Nouveau nom"
Renvoyer (NomChamp, Vrai)

Si l'on ne précise pas de booléen, le champ est forcément actif. On peut mettre le booléen avant ou après le nom du champ. Le nouveau nom lui reste obligatoire.

LDETLFB autorise désormais l'accès aux données protégées par chiffrement (données personnelles) de LDPaye et LDNégoce dans le cadre du RGPD.

Dans le cas d'un entrepôt géré sous MariaDB, on avait un souci avec les champs déclarés en HyperFile en tant que Mémo Texte. On tentait de créer ces champs dans MariaDB avec le type BLOB SUB-TYPE TEXT. Or, cette syntaxe, comprise par une base Firebird, n'est pas compatible MySQL. Désormais, ces champs sont créés avec le type LONGTEXT si l'entrepôt est sous MariaDB

Quand on chargeait par LDETLFB dans un entrepôt sous MariaDB des rubriques de type Time ou DateTime, l'initialisation ne se faisait pas correctement.
Par exemple, pour les rubriques de type Time, la valeur passée était au format HHMMSSMMM qui n'est pas reconnu par MariaDB.
Les formats reconnus sont :
  - entre apostrophes : 'D HH:MM:SS', 'HH:MM:SS, 'D HH:MM', 'HH:MM', 'D HH', 'SS', 'HHMMSS'
  - en numérique : HHMMSS, MMSS, SS
C'est le format numérique HHMMSS que l'on utilise désormais.

De plus, les heures non renseignées dans la base HyperFile arrivaient dans MariaDB à la valeur 00:00:00. Désormais, on trouve la valeur Null, comme c'était déjà le cas pour les dates non renseignées.

Lors de la création d'une table cible en base HFCS (essentiellement pour les CLLAJ, car en dehors de ce cas d'utilisation, l'entrepôt de données est géré sous Firebird ou MariaDB), la table cible est désormais créée au travers d'une description de fichier dynamique Windev, et non plus par une commande SQL Create Table. Ainsi, le fichier est créé systématiquement avec l'attribut ..GrosFichier (alors que c'est impossible par un Create Table), ce qui permet de gérer une taille de fichier allant au-delà de 2 Go.

De plus, la taille maximale des rubriques de type Constante ou Champ compilé dynamiquement peut désormais être définie globalement via un paramètre TailleRubDyn à placer dans le fichier d'initialisation, section Données. En effet, pour ces rubriques, contrairement aux autres où la taille est reprise de la rubrique d'origine dans la requête source HFCS, LDETLFB ne sait pas déterminer la longueur optimale. Et celle-ci ne peut pas être définie rubrique par rubrique. Auparavant, elle était donc figée à 200 caractères. Cela ne pose pas de problème pour des tables Firebird ou MariaDB, les rubriques Texte étant créées en type VarChar. Mais pour une table HFCS, on ne dispose pas du type VarChar. On crée donc les rubriques texte avec une longueur fixe, et cette place est occupée systématiquement sur disque, même si la longueur effective de la rubrique est toujours plus faible. On peut donc désormais opter pour une longueur plus faible, 100 caractères par exemple, ce qui suffit amplement la plupart du temps, et peut diminuer significativement la place occupée sur disque.

Les modifications décrites plus haut ont porté principalement sur la méthode CreateTable de la classe MoteurHFSQL.
Mais au passage, de nombreuses autres modifications et simplifications ont été faites dans la classe TableCible :
 - on a retiré le préfixe fbt des noms de méthodes et champs de cette classe. Il était là pour des raisons historiques,
   mais prêtait à confusion aujourd'hui, la table cible n'étant pas toujours de type Firebird.
 - on a enlevé la gestion des clés primaires et des clés uniques, qui n'était nulle part utilisée.
   Seule demeure la gestion des clés secondaires, qui donnent lieu à des commandes Create Index.
Du coup, on a enlevé toute mention de « clé unique » sur la clé principale (sur l'écran de définition de celle-ci, et message de confirmation de cette clé principale) : depuis la version 2 des modèles, la clé principale est toujours gérée comme une clé secondaire, avec donc doublons autorisés.

Suite à la correction 14, les valeurs nulles n'étaient plus supportées dans les fichiers cibles gérés en base HF, fichiers qui sont désormais créés au travers d'une description de fichier. Pour que ces valeurs nulles soient autorisées, il faut ajouter la propriété NullSupporté dans la description de fichier et la propriété NullAutorisé dans les descriptions de rubriques.