Positionner le Débogueur sur le poste de développement à partir de conditions de production.

Lorsque le mécanisme de sécurité Wlangage est déclenché en production, il n'est pas toujours évident de parvenir à reproduire le même cas sur le poste de développement afin d'apporter les corrections nécessaires. Avant d'entreprendre un débogage à distance nécessitant une connexion au poste de l'utilisateur final, et d'être disponible au moment où l'erreur survient, il est possible d'utiliser un "Dump de débogage".

Rien de plus simple, grâce au lien "Enregistrer les informations pour le fournisseur de l'application (dump de débogage)" :

En effet, le lien permet d'obtenir un fichier d'extension wdump, qu'il suffit de récupérer sur le poste de développement. Une fois le fichier récupéré, un simple drag & drop au dessus du projet concerné permet de se retrouver dans le débogueur, au moment ou le mécanisme de sécurité a été déclenché, afin de mieux cerner le cas en consultant les variables, paramètres...

Il est également possible d'obtenir un dump par programmation, par exemple dans le cas où les déclenchements du mécanisme de sécurité sont traités par l'application :
http://doc.pcsoft.fr/fr-FR/?1000018834

Je profite de ce billet pour m'excuser auprès de ceux qui m'écrivent "ce blog est-il mort ?" ! Rassurez-vous il n'est pas mort. Mais comme tout le monde les "temps modernes" ne me laissent que très peu de temps pour partager, et prendre le temps pour des activités qui sortent d'un contexte purement professionnel.

Obtenir la liste de toutes les DLL utilisées par une application

Le code suivant peut être utile pour localiser toutes les DLL utilisés par une application, durant son exécution. Affichée à partir d'une fenêtre "à propos" ou de configuration avancée, cette liste peut permettre :
- de vérifier l'emplacement des modules réellement chargés,
- de vérifier les versions,
- de connaître les dépendances nécessaires.

sListeDLL est une chaîne
POUR TOUTE CHAINE sUneAppli DE ExeListeProcessus(exePID, exeNomCourt) SEPAREE PAR RC

SI ExtraitChaîne(sUneAppli, 2, TAB) ~= fExtraitChemin(ExeInfo(exeNom), fFichier+fExtension) ALORS
sListeDLL = ExeListeDLL(ExtraitChaîne(sUneAppli, 1, TAB))
FIN

FIN
Saisie1 = sListeDLL

Supprimer les signes cabalistiques dans le sujet des emails envoyés avec WINDEV.

Suivant la messagerie utilisée pour la lecture d'un email envoyé avec WINDEV, Outlook notamment, le sujet des emails peut ne pas avoir les bons caractères (accents remplacés...).

C'est le cas lorsque le message est envoyé avec l'appel suivant :

EmailEnvoieMessage("SessionSMTP")

Pour que le mail envoyé soit correctement lu dans ce cas, il faut modifier le code d'envoi, en donnant l'option EmailOptionEncodeEntête :

EmailEnvoieMessage("SessionSMTP", EmailOptionEncodeEntête)

Sans cette option, si le sujet du message est "c'est l'été", le message envoyé contient :

From:...
Subject: c'est l'été
To:...

Alors qu'avec l'option, il est codé différemment, et est mieux interprété par certaines messageries :

From:...
Subject: =?ISO-8859-1?Q?c'est_l'=E9t=E9=00?=
To:...

Déploiement en réseau des applications, comment modifier le lien entre chaque poste utilisateur et le serveur ?

Le déploiement avec mise à jour en réseau est extrêmement pratique, puisqu'il permet :
- d'avoir l'application en local sur chaque poste pour de meilleures performances,
- de ne mettre à jour que le serveur lors des modifications de l'application, afin qu'elle se propage automatiquement sur tous les postes.
Cette solution offre donc les avantages, sans les inconvénients d'autres possibilités de déploiement.

Le seul point délicat de cette solution, concerne le changement de serveur. En effet toutes les installations locales de l'application "pointent" vers le serveur en ayant son nom stocké dans un fichier de paramètres. De ce fait, si le serveur doit changer de nom, ou de ressource partagée, il est nécessaire d'intervenir sur le paramétrage de chaque poste afin de rétablir la possibilité de mise à jour automatique.

Voici les solutions possibles, de la plus avantageuse à la plus contraignante :

- réinstallation complète de l'application en "push"
Sur le serveur le programme WDADMINEXE.EXE permet de déployer l'application sur les postes utilisateurs. Donc si le réseau le permet, une première possibilité consiste à déployer à nouveau l'application sur tous les postes. De cette manière sur chaque poste le lien vers le nouveau serveur sera mis à jour.

- réinstallation complète de l'application sur chaque poste :
Cette seconde solution vise à obtenir le même résultat que précédemment, en installant à nouveau l'application sur chaque poste. Le fichier de paramètre est ainsi remis à jour, par contre cette solution impose de repasser sur tous les postes pour relancer l'installation du serveur.

- modification du fichier de paramètre de chaque poste :
Le fichier de paramètre utilisé par se mécanisme ne nomme WDUPDATE.NET, il est placé dans le répertoire de l'exécutable sur chaque poste. C'est un fichier de type ".INI", il est donc possible de le modifier depuis l'application elle-même à l'aide de la fonction "AppliChangeParamètre" (ou "INIEcrit"). Il est donc envisageable avant le changement de serveur de faire une dernière mise à jour de l'application, qui sera capable via le code du projet de corriger le WDUPDATE.NET. Une fois la mise à jour prise par chaque poste, il sera possible de changer le serveur, puisque la version locale de l'application aura maintenant l'emplacement du nouveau serveur.

Applet Java et exécutable Win32 générés depuis un même projet, comment supprimer les erreurs de compilation "La fonction n'a pas d'équivalent dans le framework WL/Java" ?

Lorsqu'un projet contient deux configurations, l'une permettant de créer un exécutable Windows, l'autre permettant de créer une applet Java, tous les codes sont compilés en permanence, quelque soit la configuration en cours. Ainsi même si la configuration de projet chargée et celle de l'exécutable Windows, les erreurs de compilation de la forme suivante peuvent remonter :

La fonction n'a pas d'équivalent dans le framework WL/Java

L'utilisation de la fonction "EnModeTest" ne permet pas d'éviter la compilation. La solution pour éviter cette compilation systématique : le "code-cible conditionnel". Il suffit dans le code utilisant une fonction non disponible en Java, de dérouler le menu "Code / code-cible conditionnel". L'interface propose alors de sélectionner les codes à ajouter, et divise le code en sections. Il est ainsi possible d'avoir un code compilé dépendant de chaque plateforme cible. Illustration avec un bouton faisant appel à un état :

Où paramétrer l'utilisation d'un serveur proxy pour utiliser les fonctions FTPEnvoie, FTPRécupère ?

Les fonctions FTP* du WLangage reposent directement sur le API FTP de Internet Explorer. Si un proxy doit être utilisé, il faut donc le configurer directement dans les options de Internet Explorer, et non pas avec la fonction Proxy du WLangage.

Voici en image l'emplacement du réglage dans Internet Explorer :

Exception pour confirmer la règle, il y en a toujours une, la fonction "FTPCommande", contrairement à "FTPRécupère" ou "FTPEnvoie", permet d'adresser directement le serveur FTP, sans passer par les API de Interner Explorer. Elle est obligatoire si le serveur FTP n'est pas accessible au travers de Internet Explorer.

Exporter les données d'un champ table vers Excel sans limitation sur le nombre de lignes.

Lors de l'utilisation de l'option automatique "Exporter vers Excel" d'un champ table, ou de la fonction "TableVersExcel", l'extension "XLS" est proposée par défaut. Le fichier Excel créé a donc le format des versions de Excel antérieures à la version 2007. Ces versions sont limitées à 65 536 lignes dans une feuille.

Pour exporter les données sans aucune limitation, il faut que format du fichier Excel créé soit en version 2007. Il faut pour cela préciser lors de l'exportation une extension "XLSX", au lieu de "XLS".

Précision dans les champs de saisie des IHM

Ce billet complète le précédent concernant la précision des calculs faits par programmation. En effet, tout comme l'utilisation de "0n" pour l'affectation d'un numérique, l'option "Numérique haute précision" des champs permet d'obtenir une précision maximale pour les valeurs saisies :


La coche n'est pas active par défaut, il faut donc bien penser à l'activer à partir du moment ou le domaine de l'application nécessite une précision importante.

Résultat erroné dans un calcul sur des numériques

L'expression courante "on en apprend tous les jours" est sans doute la plus vraie qui soit !

Hier encore je pensais que le type "numérique" était juste comme le type "monétaire". Ce n'est pas tout à fait exact, son affectation directe se faisant via un réel, on peut avoir des valeurs ou arrondis inattendus inhérents au codage des réels de Windows (IEEE).

Mais aujourd'hui après une consultation de l'aide sur le type numérique, j'ai appris une syntaxe permettant de forcer une affectation pour qu'elle soit juste. Je pense qu'il est bon de garder cette information à l'esprit dès lors qu'un traitement nécessite une importante précision de calcul.

Ainsi l'écriture traditionnelle :

nValeur est un numérique
nValeur = 1234567890123456789.01
Trace(nValeur)

Sera avantageusement remplacée par :

nValeur est un numérique
nValeur = 0n1234567890123456789.01
Trace(nValeur)

Attention le "0n" qui précède la valeur est un "zéro" combiné avec la lettre "n". Il ne s'agit pas des lettres "o" et "n".

Ignorer un paramètre sur index full-text dans une requête

Lorsqu'une requête contient un paramètre portant sur un index full-text, par défaut la pertinence relative à l'index full-text fait partie du résultat. La requête est donc de la forme suivante :

SELECT
MATCH(XX, YY, ZZ) AGAINST({ParamFullText}) AS PertinenceFullText
FROM
TABLE
WHERE

AND PertinenceFullText > 0
ORDER BY
PertinenceFullText DESC

Tant que cette pertinence figure dans le résultat, le paramètre de la requête s'y rapportant est obligatoire. La syntaxe suivante :

Requête.ParamFullText = Null
HExécuteRequête(Requête)

conduira à l'erreur :

Erreur dans le code SQL de la requête . Initialisation de la requête impossible. Le paramètre doit être renseigné.

Pour pouvoir rendre le paramètre optionnel, il suffit de ne pas le faire figurer dans le résultat de la requête. Dans l'éditeur de requêtes il faut pour cela sélectionner "ne pas afficher" en cliquant sur l'oeil correspondant à la condition sur l'index full-text. La requête obtenue sera de la forme suivante :

SELECT
*
FROM
TABLE
WHERE

AND MATCH(XXX, YYY, ZZZ) AGAINST({ParamFullText}) > 0

Comme toujours, c'est très simple ... une fois que l'on sait.

Pallier au message "L'état ?? est déjà en cours d'impression"

J'ai constaté avec surprise, suite aux plaintes d'utilisateurs, que le double-clic sur un bouton lançant un état provoquait une erreur de l'application :

L'état ?? est déjà en cours d'impression
Dump de l'erreur du module <12.00Bw>.
- Niveau : erreur fatale (EL_FATAL)
- Code erreur : 210055
- Infos de debug : Fonction (21,0)

Le défaut m'a été confirmé par le support. En palliatif immédiat, puriste s'abstenir, j'ai utilisé le code suivant qui évite de relancer l'état en cas de double clic.

// Code de clic sur le bouton d'impression
SI ChaîneOccurrence(dbgInfo(dbgPile), "Clic sur "+MoiMême..Nom) > 1 ALORS RETOUR

iAperçu(i100)
iImprimeEtat(Etat1)

J'espère que cette astuce pourra resservir, même s'appuyer sur la pile n'est pas de plus "propre", cela permet de facilement régler le problème.

Wlangage dans les requêtes SQL : "Vous n'êtes pas autorisé à exécuter la fonction WLangage XX dans une requête"

Les requêtes sur une base Hyper File peuvent inclure des instructions WLangage (cf billet fonction du WLangage dans une requête SQL). Par contre une erreur peut se produire lors de l'exécution, mentionnant le nom de la fonction WLangage appelée dans le code SQL :

Vous n'êtes pas autorisé à exécuter la fonction WLangage XX dans une requête

Où est le piège ... dans les droits définis sur le serveur !

Il faut donner le droit "Droit d'exécuter des procédures stockées" à l'utilisateur connecté. Sans ce droit spécifique, l'exécution d'une requête se solde par ce retour.

Requête DECODE pour moins de code...

Je ne découvre seulement qu'aujourd'hui l'instruction SQL DECODE. C'est un intérêt du développement on en apprend tous les jours !

L'instruction SQL DECODE est très pratique, elle permet de formater une information directement dans le résultat d'une requête SQL, afin d'éviter de la programmation lors de la lecture de la requête pour présenter les données. Exemple typique d'une civilité stockée avec 1, 2 ou 3 dans une base de données, on pourra grâce à DECODE obtenir directement dans le résultat de la requête "M.", "Mme" ou "Mlle". Exemple :

SELECT
DECODE(CLIENT.Civilité ,1,'M. ',2,'Mme. ',3,'Melle ','') +' '+
CLIENT.NomClient +' '+CLIENT.PrénomClient AS NomComplet
FROM
CLIENT

Système 32 ou 64 bits pour héberger un moteur Hyper File Client/Serveur (ou exécuter les applications) ?

"Qui peut le plus peut le moins" on peut donc être tenté de systématiquement partir sur du 64 bits ! Il n'y a cependant aucune obligation. La seule restriction incontournable d'un système 32 bits et de ne pas permettre à un processus d'allouer plus de 2 Go de RAM (indépendamment de la RAM totale). Donc ... système 64 bits obligatoire si le moteur Hyper File Client/serveur a besoin à un moment donné de plus de 2 Go de RAM pour répondre aux applications clientes qui le sollicitent. Dans tout autre cas un système 32 bits est suffisant.

Par contre attention de ne pas sous évaluer les besoins, car d'après mes constations lorsque les 2 Go disponibles en 32 bits sont alloués, il n'est pas rare que les postes clients ne reçoivent plus de réponse (ou seulement après une attente trop importante).

Ajuster l'espace alloué pour le cache du moteur Hyper File Client/Serveur

Le centre de contrôle Hyper File permet d'indiquer la taille mémoire maximale à utiliser pour les caches.

Afin d'accélérer les accès pour de meilleures performances, on peut être tenté d'augmenter à outrance cet espace, . Mais il faut bien garder à l'esprit que l'espace donné pour le cache, limite d'autant l'espace disponible pour les autres besoins du serveur (requêtes, traitements...).

Il est donc nécessaire d'étudier en production ce qu'il se passe sur le serveur, en fonction des actions faites par les applications. En effet, en fonction des accès effectués par les applications, les caches devront être privilégiés, ou au contraire, il faudra un maximum d'espace mémoire libre pour satisfaire au plus vite les applications.

Pour cela il faut activer dans la configuration du serveur les statistiques d'activités, puis les consulter sur une période de mise en production la plus représentative possible de l'utilisation courante.

Leur visualisation sous forme de graphe permet de voir les accès (en nombre ou en octets) fait en directs sur le disque, ou dans les caches. L'opération doit être renouvelée à plusieurs reprises, en augmentant à chaque fois sensiblement l'espace des caches. Dès que l'augmentation du cache alloué ne permet plus de faire évoluer le nombre d'accès en cache de façon significative, il ne faut plus augmenter l'espace alloué au cache sous peine de limiter l'espace mémoire inutilement.

Pour une mesure précise, il faut à chaque essai de réglage de l'espace du cache consulter les statistiques d'activité sur une même période d'utilisation (même nombre d'utilisateurs, avec une même activité). Pour encore plus de précision l'observation des statistiques peut se faire sur une période ou l'application n'est exécutée que par des tests automatiques, qui permettraient d'avoir une activité constante. Personnellement, je ne suis jamais allé jusque là, la simple consultation des statistiques durant la production ayant toujours été suffisante pour se faire une bonne idée.

Créer une copie locale pour test d'un fichier Hyper File Client/Serveur

Il n'est pas rare d'avoir besoin pour test d'une copie locale d'un fichier de données Client/Serveur en cours d'exploitation. Dans ce cas, la fonction "HCopieFichier" ne peut pas être utilisée, car elle aurait une incidence sur les blocages et accès en cours.

Le code suivant peut avantageusement être utilisé, son exécution sera transparente pour les utilisateurs.

ConnexionHFCS est une Connexion
sNomFicherHFCS est une chaîne = "PRODUITS.FIC"
sdFichierHFCS est une Source de Données
sdFichierLocal est une Source de Données
sRepLocal est une chaîne = "C:\TEMP"
sNomLocal est une chaîne = "PRODUITS"

ConnexionHFCS..Provider = hAccèsHFClientServeur
ConnexionHFCS..Utilisateur = "admin"
ConnexionHFCS..MotDePasse = ""
ConnexionHFCS..Serveur = "SRV_Data:4912"
ConnexionHFCS..BaseDeDonnées = "FACT"

HOuvreConnexion(ConnexionHFCS)
HDéclareExterne(sNomFicherHFCS,sdFichierHFCS,ConnexionHFCS)

HAlias(sdFichierHFCS, sdFichierLocal)
HChangeRep(sdFichierLocal, sRepLocal)
HChangeNom(sdFichierLocal, sNomLocal)
HCréationSiInexistant(sdFichierLocal)

POUR TOUT sdFichierHFCS

HCopieEnreg(sdFichierLocal, sdFichierHFCS, hCopieIdAuto)
HAjoute(sdFichierLocal,hForceIdAuto)

FIN

Note : en fonction des actions faites sur le fichier Client/Serveur en production, il faut compléter le traitement afin de traiter les cas d'erreur.

Comparer deux enregistrements d'une table décrite dans l'analyse ...

Le WLangage n'a pas de fonction permettant de savoir si deux enregistrements d'un même fichier, ou de deux fichiers différents mais de même structure, sont identiques. Pour effectuer une telle comparaison, sans tester l'égalité entre toutes les rubriques, il est possible d'utiliser une fonction spécifique :

HRécupèreEnregistrement(...)

Cette dernière permet en effet d'avoir le contenu complet d'un enregistrement dans une variable chaîne de caractères. Il suffit donc de l'utiliser sur les enregistrements à comparer, puis de comparer les chaînes obtenues.

Comment récupérer le séparateur décimal de windows ?

La fonction WLangage "NumériqueVersChaine" peut retourner sous la forme d'une chaine une valeur réelle, tout en utilisant le séparateur décimal de Windows. Elle peut donc servir à récupérer si besoin ce séparateur :

SeparateurDecimal est un caractère
SeparateurDecimal = NumériqueVersChaîne(1.1,"3,1f")[[2]]
Info(SeparateurDecimal)

Encoder un mot de passe pour un serveur LDAP

Si l'écriture dans un serveur LDAP est simple avec les fonctions LDAP* du Wlangage, il n'en est pas de même dans le cas bien particulier ou l'on souhaite écrire un mot de passe !

Voici le code nécessaire à l'encodage du mot de passe pour qu'il soit "conforme" LDAP :

sMotDePasse est une chaîne = "secret"
sSel est une chaîne = "graindesel"
sHash est une chaîne = HashChaîne(HA_SHA_160, sMotDePasse+sSel)
sAttrib est une chaîne = "{SSHA}"+Crypte(sHash+sSel, "", crypteAucun, encodeBASE64)

Placer en fond d'un état les pages d'un formulaire PDF

Suite à une demande sur le forum, et intéressé par la fonctionnalité, j'ai recherché comment placer en fond d'un état les différentes pages d'un document PDF.

La méthode n'a rien d'immédiate, je pense que sa publication sera appréciée !

Si un état contient plusieurs pages, et qu'il a en fond un PDF contenant également plusieurs pages, les différentes pages de l'état ne peuvent pas prendre les différentes pages du PDF, mais une seule (et c'est vraiment dommage) :



Il faut donc jongler et créer plusieurs états qui vont être imbriqués les uns dans les autres :
- un premier état est associé à la page 1 du formulaire PDF,
- un deuxième état est associé à la page 2 du formulaire PDF,
- un troisième état est associé à la page 3 du formulaire PDF ....

L'application fera ainsi un iImprimeEtat() du premier état. Ce premier état fera dans son code après impression un iImprimeEtat() du deuxième état, qui appellera à son tour le troisième état...

J'ai testé la solution d'états internes, mais je n'ai pas eu de bons résultats. De façon générale il me semble que les états imbriqués sont à préférer aux états internes.

Gageons que PC SOFT saura faire évoluer la fonctionnalité pour plus de simplicité. Car cette solution s'applique si les pages de l'état sont différentes, mais pas dans le cas ou c'est le bloc corps d'un état qui va se dérouler sur différentes pages ...

Utilisateur courant dans la barre de message, sans programmation comme la date ou l'heure...

Sans aucune programmation il est possible d'insérer des informations dans la barre de messages des applications : date, heure, depuis peu l'utilisateur en cours dans le cas ou l'application utilise le Groupware utilisateur !



Ce principe du "Zéro code" se développe, avec les actions prédéfinies et les FAA notamment, et c'est une bonne chose pour accélérer les développements, limiter les risques d'erreur, ajouter des fonctionnalités !

Ndlr : terminant une longue intervention sur site, je devrais retrouver avec plaisir un peu de temps pour le blog et le forum dans les semaines qui viennent !

Aide à la saisie obligatoire !!!

Voici une fonctionnalité de la version 12 qu'il faudrait rendre obligatoire, par respect pour les utilisateurs des applications !

Un jour ou l'autre on se retrouve devant un champ, sans savoir où trouver l'information attendue. Dans le meilleur des cas une bulle d'aide est proposée, ou un bouton d'aide dans la fenêtre, mais il n'est pas rare de ne pas être assisté.

Alors que toute saisie respectueuse de l'utilisateur, devrait permettre instantanément de savoir de quoi il s'agit. Voici un exemple de mise en oeuvre de l'aide à la saisie avec WINDEV 12 (c'est également disponible pour les pages WEB des sites WEBDEV) :


Dès que le curseur est placé dans le champ, l'information d'aide s'efface progressivement avec un effet de fondu pour laisser place à la saisie.

Aucune programmation n'est requise, il suffit de fournir l'information qui guidera l'utilisateur dans la description du champ :

WINDEV 12 non documenté !

Deux fonctionnalités non documentées de WINDEV 12 découvertes après quelques minutes d'utilisation, certes avec l'aide du support, mais cela vaut un petit billet pour faire circuler l'information en attendant que la documentation rattrape la productivité des développeurs !

1. Recherche dans les styles et les options d'édition des champs, information sur le Blog du support. A vos claviers pour tester le Ctrl+F, il y en a peut être d'autres du même type à découvrir !

2. Afficher un PDF dans une image est enfantin :

IMG_TEST_PDF = fRepExe()+["\"]+"AideDépart.PDF"

Le positionner sur une page précise est ... tout aussi simple, à condition d'avoir trouvé la bonne propriété (ce que l'aide ne donne pas par défaut pour le moment) :

IMG_TEST_PDF..NuméroPage = 4

Au passage le support m'informe qu'à terme le champ image lorsqu'il est affecté avec un PDF, aura une gestion d'ascenseurs, de zoom. Le tout basé sur la technologie "Zéro code" chère à PC SOFT !

Compléter les appels aux navigateurs par un message d'information

Il n'est pas rare de lancer depuis une application le navigateur Web par défaut sur un site. Le traitement est de la forme :

LanceAppliAssociée("http://elianlacroix.blogspot.com")

Mais les configurations de plus en plus sécurisées peuvent bloquer cette ouverture du navigateur. L'action pourrait en effet être commandée par un programme malveillant...

Il est donc bon lorsque cette ouverture est ponctuelle de donner au passage un message d'information indiquant l'action, et la conduite à tenir en cas de difficulté. Ceci est d'autant plus vrai dans le cas d'une application dite "grand public".

Voici une illustration de ce mécanisme mis en place dans l'application Tomtom Home lorsque l'on tente de consulter la documentation d'un GPS fraîchement déballé :


Ainsi même si l'ouverture est impossible, l'utilisateur final n'est pas dérouté par un bouton sans aucun effet. L'ajout d'une minuterie sur le bouton peut être un plus, ainsi que d'une coche "ne plus afficher ce message".

Accélérer les traitements d'importation de données

Les temps de traitement pour des importations de données peuvent générer une attente importante si se cumulent des volumes importants, et des index nombreux. En effet, chaque ajout va nécessiter de mettre à jour les différents index correspondant aux données.

Une alternative permettant des traitements d'importations plus rapides, consiste à différer la mise à jour des index en s'appuyant sur le mécanisme de réindexation.

La phase d'importation se fait en utilisant la fonction "HEcrit" en lieu et place de "HAjoute". Elle permettra d'insérer les données à importer, sans aucune mise à jour des index. Cela permet un gain de temps, très significatif dans le cas d'un fichier ayant de nombreux index.

Une fois les données importées, il suffit d'utiliser la fonction "HRéindexe" qui va mettre à jour les index avec les nouvelles données. Dans bien des cas, cette méthode en deux temps est plus rapide qu'une importation traditionnelle avec la fonction "HAjoute".

Sur le même sujet :
Synthèse pour aller plus vite !
Accélérer le lancement des applications