Sortir de HFSQL fait-il baisser ma facture PC SOFT ?

Non. Depuis la vidéo de PC SOFT de juillet 2026, une session se compte par exécutable, utilisateur et machine, que l'application attaque une base ou aucune. Le type de base ne compte plus. Sortir de HFSQL garde toute sa valeur (données libres, outils standard), mais seule la sortie de l'application elle-même arrête la facturation.

Peut-on garder l'application WinDev et changer seulement la base ?

Techniquement, oui, par un accès natif PostgreSQL de PC SOFT. Nous ne le proposons pas : la dépendance à PC SOFT reste entière, et le comportement de l'application change dans des recoins que personne ne teste (valeurs vides, tris, blocages). La reprise des données est pour nous un jalon de la réécriture.

HFSQL Classic ou Client/Serveur, cela change-t-il quelque chose ?

Peu pour la reprise : les deux se lisent et se reprennent. En Classic, les fichiers de données, d'index et de mémos vivent sur un disque partagé, et ce sont souvent eux qui portent le plus de valeurs vides, de doublons et d'orphelins accumulés.

Combien de temps prend la reprise des données ?

Elle dépend du nombre de fichiers et surtout de la qualité des données. L'estimation en ligne compte vos fichiers de données à partir de l'analyse ; le cadrage fixe le prix et la durée du jalon de reprise sur votre base mesurée.

Migration · HFSQL vers PostgreSQL

Sortir de HFSQL vers PostgreSQL : ce que ça implique vraiment

Quand une entreprise décide de prendre ses distances avec PC SOFT, la base de données est souvent le premier chantier qui vient à l'esprit. C'est logique : les données sont ce qui a le plus de valeur, et HFSQL les enferme dans un format que seuls les outils de PC SOFT lisent confortablement.

La bonne nouvelle : copier la structure et les données d'une base HFSQL vers PostgreSQL est la partie facile. La moins bonne : ce qui coûte, ce sont les détails que la copie ne voit pas, et surtout le code WLangage qui lit et écrit ces données.

Pourquoi PostgreSQL

Vos données redeviennent lisibles par tout le monde : un outil de reporting, un tableur, un script, un autre logiciel, sans pilote propriétaire.
Les outils d'exploitation sont standard : sauvegarde, réplication, supervision, chiffrement, des compétences disponibles partout.
Aucune licence, et aucun éditeur qui peut changer un jour les règles de comptage.
Les contraintes vivent dans la base : clés étrangères, contrôles, types stricts. Une donnée incohérente est refusée à l'entrée, quel que soit le programme qui l'écrit.

Une chose à savoir avant de commencer : sortir de HFSQL ne fait pas baisser votre facture de sessions PC SOFT. Depuis juillet 2026, le type de base n'entre plus dans le comptage. Le calculateur d'exposition le montre.

Ce qui se copie sans peine

L'analyse décrit tout : fichiers, rubriques, clés, liaisons. Elle se traduit en tables, colonnes, index et clés étrangères. Les données suivent par une lecture fichier par fichier. Pour une application de taille moyenne, cette partie se compte en jours, pas en mois.

Ce qui piège

Voici les écarts que l'on retrouve d'une base HFSQL à l'autre. Aucun n'est rare.

Les valeurs vides

Par défaut, une rubrique HFSQL ne gère pas le NULL : une date absente est une chaîne vide, un montant absent vaut zéro. PostgreSQL distingue les deux. Il faut décider, rubrique par rubrique, si zéro veut dire « zéro » ou « pas renseigné ». Se tromper ici fausse vos moyennes et vos statistiques sans que rien ne plante.

Les dates

HFSQL accepte des dates que PostgreSQL refuse : un 31 février, un mois à zéro, une année à deux chiffres saisie il y a vingt ans. La reprise les trouve toutes. Elles se corrigent, mais avec vous, pas en silence.

Les clés insensibles à la casse et aux accents

Une clé HFSQL peut ignorer la casse, les accents ou la ponctuation. Une recherche sur « Ecole » trouve alors « ÉCOLE ». Dans PostgreSQL, ce comportement se reconstruit (collation, index sur expression), mais il ne vient pas tout seul. Oublié, il donne des recherches qui ne trouvent plus rien, et des doublons que la clé unique laissait passer et que la nouvelle base refuse.

L'encodage

Une base qui a vécu quinze ans mêle souvent des rubriques ANSI et Unicode, et des caractères saisis depuis des postes réglés différemment. PostgreSQL travaille en UTF-8 : chaque caractère mal encodé doit être identifié avant la reprise.

Les liaisons jamais appliquées

Les liaisons de l'analyse sont souvent décrites sans être appliquées en contrôle d'intégrité. Résultat : des lignes de facture dont la facture n'existe plus, des clients rattachés à un commercial supprimé. Une clé étrangère PostgreSQL les refuse. Il faut les trouver, les compter, et décider avec vous de leur sort.

Les identifiants automatiques et les mémos

Les identifiants automatiques deviennent des colonnes d'identité, reprises avec leurs valeurs pour ne casser aucun lien, puis recalées. Les mémos texte deviennent du texte, les mémos binaires des colonnes binaires ou des fichiers, selon leur volume et leur usage. Le type monétaire devient un NUMERIC exact, jamais un nombre à virgule flottante.

Le vrai sujet : le code

Une application WinDev ne lit pas sa base en SQL. Elle la parcourt avec les fonctions H : lecture par clé, filtres, positions, enregistrement en cours, blocages. Ce mode de travail n'a pas d'équivalent direct en SQL, et c'est lui qui porte une bonne part de vos règles métier.

Il est techniquement possible de garder l'application WinDev et de la brancher sur PostgreSQL par un accès natif PC SOFT. Nous ne le proposons pas. La dépendance à PC SOFT reste entière, et le comportement change dans des recoins que personne ne teste : une valeur vide devenue NULL, un tri qui ne suit plus les accents, un blocage qui ne se pose plus pareil.

Pour nous, la reprise des données est un jalon de la réécriture, pas un projet isolé. Elle se fait vers une base conçue proprement, pas vers une copie conforme de l'analyse d'origine, défauts compris.

Comment nous menons la reprise

un script de reprise rejouable : on le lance autant de fois qu'il le faut, sur une copie fraîche de votre base, jusqu'à la bascule ;
des preuves à chaque passage : comptages par table, sommes de contrôle, échantillonnages comparés ligne à ligne ;
la liste des défauts trouvés : orphelins, doublons, dates impossibles, caractères mal encodés, chacun compté et tranché avec vous, jamais corrigé en silence ;
une répétition de la bascule avant la vraie, avec un retour arrière testé.

Par où commencer

Mesurer avant de chiffrer. L'estimation en ligne compte vos fichiers de données, vos fenêtres et vos requêtes à partir de votre projet, dans votre navigateur, sans rien envoyer. Le diagnostic flash va plus loin : à partir du code et du script SQL de l'analyse, il dit ce qui verrouille la sortie, HFSQL compris, en cinq jours ouvrés.