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.

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.

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

Accélérer le lancement des applications

Par facilité on place régulièrement la fonction "HCréationSiInexistant" au début des applications pour s'assurer de la création systématique de tous les fichiers de données. Le piège, la base grandissante, est d'avoir une attente importante lors de cet appel, car il provoque une ouverture de tous les fichiers de données. Et l'ouverture initiale des fichiers fait partie des opérations les plus coûteuses en temps.

Il y a une solution, presque miracle, c'est l'option "hOuvertureDifférée" de la fonction :

HCréationSiInexistant("*", hOuvertureDifférée)

En effet, le but escompté est atteint, car tous les fichiers restent créés automatiquement. Mais pour les fichiers existants, l'ouverture ne sera pas faite immédiatement. Elle sera différée à la première utilisation effective du fichier. On comprend aisément le gain de temps très appréciable puisque :
- le temps d'ouverture des fichiers est réparti au fil de l'application,
- seuls les fichiers réellement utilisés seront ouverts.

Sur le même sujet :
Synthèse pour aller plus vite !
Accélérer les traitements d'importation de données

Synthèse pour aller plus vite !

Voyant apparaître sur les forums des demandes de conseils pour optimiser les accès aux données, j'ai regroupé ici les principaux éléments de réponse, et méthodes à employer. L'optimisation des accès est primordiale, surtout lorsqu'ils sont faits au travers d'Internet qui n'offre pas les débits d'un réseau local.

Privilégier les sélections par des requêtes :
Il est préférable d'effectuer les sélections de données au travers de requêtes. En effet, par opposition à des accès enregistrement par enregistrement, elles vont permettre de "ramener" sur le poste client les données sélectionnées, par "paquets" réseau bien remplis. Des lectures enregistrement par enregistrement vont au contraire générer du trafic avec à chaque fois peu de données. De plus la lecture d'un enregistrement impose de récupérer toutes ces rubriques, alors que la sélection d'une requête peut être affinée en ne prenant que les rubriques utiles à un moment donné. Ceci est d'autant plus vrai si la connexion se fait par Internet.

Optimisation des requêtes :
Le menu "Requête / Optimiser la requête" accessible en édition d'une requête doit finaliser la phase de création d'une interrogation. Il permet d'ajouter si besoin les clés dont la requête aura besoin pour un maximum de rapidité.

Statistiques des index à jour :
Les clés dans le fichier sont importantes, à condition que les statistiques des index soient régulièrement mis à jour (surtout après des ajouts en grand nombre).

Rester raisonnable :
La facilité avec laquelle on programme et accède aux données, le tout généralement dans l'urgence, provoque parfois une négligence de l'évaluation de ce que l'on demande. Chaque enregistrement à une taille bien précise, chaque interrogation va ramener un ensemble d'enregistrements, donc un volume précis. Il faut tenir compte, surtout en accès via Internet, de ce volume, afin d'évaluer avec le débit minimal si l'application ne demande pas trop par rapport à ce qu'elle peut recevoir.

Client/Serveur :
Privilégier un accès aux données au travers du moteur Hyper File Client/Serveur, il va permettre de soulager grandement le travail de chaque poste client, et donc de gagner en performances. Les procédures stockées vont offrir également des gains. Typiquement, un long calcul statistiques pourra être fait en "différé" de l'application, permettant à un utilisateur d'avoir un résultat immédiat en remplacement d'une attente.
Son mécanisme de "Log" pourra également permettre un suivi très fin des interrogations en vue de rechercher notamment des abus d'une station, ou d'un traitement.

Analyseur de performances :
Lorsque l'on a encore des attentes, il faut exécuter l'analyseur de performances qui va permettre de les localiser très précisément. Une fois que l'on sait où passe le temps, il devient possible de voir comment l'influencer (dans un programme uniquement à mon grand regret).
Cas particulier pour l'attente du matin, il faut garder dans un coin de tête le possible trouble que peut engendrer la restauration du système.

Ce billet n'a rien d'exhaustif le sujet étant si vaste, je tenterai de le compléter régulièrement. Mais pas trop vite tout de même, car il est temps pour moi de prendre quelques jours de repos en cette période estivale !

Sur le même sujet :
Accélérer le lancement des applications.
Accélérer les traitements d'importation de données

Attente au matin lors de la mise à jour d'un fichier ...

Description surprenante d'un utilisateur final :

Tous les matins le premier enregistrement d'une commande prend du temps, les suivants sont immédiats !?

Surprenante, car c'est plutôt au fur et à mesure que l'on "charge" la machine tout au long de la journée qu'elle ralentit, plutôt qu'à son démarrage. Et pourtant, cela peut se produire avec les postes XP configurés par défaut et utilisant une base Hyper File.

Le fautif : la restauration du système de Windows car elle pense que les fichiers NDX (index Hyper File) sont des fichiers systèmes à sauvegarder. De ce fait, après chaque démarrage du poste, si une modification est demandée sur un fichier Hyper File ("HModifie", "HAjoute", "HSupprime"...), une sauvegarde du fichier est faite et peut donc être coûteuse en temps suivant sa taille. Plus généralement, sont concernées toutes les actions qui provoquent une modification de l'index. En revanche la simple consultation n'a pas d'incidence sur la restauration du système.

La solution consiste à indiquer au mécanisme de restauration du système qu'il doit ignorer les fichiers d'index de votre application. Pour cela une clé de registre est mise à disposition par Microsoft. Il suffit donc d'aller insérer une valeur dans cette clé avec la fonction "RegistreEcrit".

La clé de registre est la suivante : HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\BackupRestore\FilesNotToBackup
Il faut insérer une valeur texte dont le nom est une chaîne quelconque, par exemple le nom de votre application, et la donnée le chemin à exclure.

La copie d'écran ci-contre donne une illustration, et ce lien donne une page de détail sur un site Microsoft.

Migrer une analyse vers une autre base de données...

Les forums contiennent souvent des sujets de la forme "comment migrer mon analyse" en Oracle, en SQL SERVER, MYSQL...

J'avais évoqué ce sujet dans un précédent billet, il n'y a aucune migration à faire au niveau des descriptions de fichiers pour utiliser une base de données ou une autre ! Si dans l'analyse un fichier est décrit en Oracle, sa description peut être appliquée en Hyper File, SQL SERVER ou tout autre base pour laquelle on dispose d'un provider OLE DB ou d'un accès natif.

La clé du mécanisme : les fonctions "HOuvreConnexion" et "HChangeConnexion".

Peu importe le type indiqué dans l'analyse, à tout moment le programme peut :
- appeler "HOuvreConnexion" pour ouvrir une connexion vers une base de données,
- puis appeler "HChangeConnexion" pour associer les tables de l'analyse, à cette nouvelle connexion.

C'est donc un mécanisme à garder dans un coin de tête, bien plus rapide que de se lancer dans des modifications de l'analyse, générations ...

Jauge en lieu et place du sablier lors de l'exécution d'une requête, la "soluce" !?

Les utilisateurs ne supportent pas les écrans figés avec un sablier, pourtant imposés lorsqu'une requête importante doit être exécutée.

Afin d'afficher une jauge durant le traitement d'une requête, il faut bien récupérer en premier lieu le nombre d'enregistrements à traiter avec la fonction "HNbEnr", et cette dernière fige l'application avec le sablier tant que toute la requête n'est pas exécutée dans sa totalité.

Et bien cela n'est plus vrai, après consultation des dernières nouveautés !!!

La fonction "HNbEnr" a été dotée d'une option "hNonBloquant". Elle permet de connaître immédiatement après l'appel de la requête, le nombre d'enregistrements déjà récupérés. Il est donc possible de débuter le traitement de la requête par son parcours, tout en affichant une jauge certes approximative, mais une jauge. Au fur et à mesure du parcours, si la propriété "..ExécutionTerminée" retourne faux, il est possible de réajuster la jauge avec le nombre d'enregistrements récupérés en rappelant "HNbEnr".

Tous ceux qui aiment observer les utilisateurs de nos applications, savent déjà que le traitement sera jugé plus rapide, du moment qu'une progression est visible !

Extraire sur disque des fichiers contenus dans une bibliothèque ?

J'ai longtemps pensé que cela n'était pas possible, et pourtant ... astuce découverte sur le forum WIN DEV, elle mérite d'être connue j'espère pouvoir la relayer par ce billet !

Je remercie son auteur que je cite (presque) directement :

- Faire un fichier Hyper File avec une rubrique mémo binaire,
- Ajouter les fichiers que l'on veut pouvoir extraire dans le mémo binaire,
- Inclure ce fichier (.fic, .ndx, .mmo) dans l'exécutable,
- dans le code indiquer que pour ce fichier il faut le rechercher dans la bibliothèque :
HChangeLocalisation(Fichier, hWDL)

Et voila.

Il suffit de rechercher dans le fichier Hyper File l'enregistrement qui contient le fichier que l'on souhaite extraire, puis de l'extraire avec :
HExtraitMémo(Fichier,MemoFichier,"C:\chemin...\FichierDestination")

Message d'origine.

Ajout de descriptions de tables MYSQL dans une analyse provoque une erreur MSVCRT.DLL ou WDHF

Rien de pire qu'une action que l'on utilise couramment, et qui sur un poste ne daigne pas s'exécuter. J'ai rencontré ce cas avec l'importation d'une table MYSQL dans une analyse. Après le listage des tables de la base MYSQL, un des messages suivants était affiché :

Une erreur système inattendue est survenue.
Si cet incident se produit de manière systématique
Module MSVCRT.DLL...

Ou :

Erreur interne à la DLL WDHF

L'origine de la panne ? Une version de LIBMYSQL.DLL qui ne convenait pas à WINDEV.
Le problème a donc disparu en installant un MYSQL et en récupérant sa LIBMYSQL.DLL standard. Précédemment il s'agissait d'un MYSQL installé avec par EasyPHP.

Pourquoi la taille d'un fichier Hyper File n'est pas réduite après un lot de suppressions ?

L'appel en série de la fonction "HSupprime()" ne provoque pas la diminution de la taille du fichier. Ceci est valable pour le fichier de données (.FIC) et pour son mémo (.MMO).

Déroutant au premier abord, mais normal en creusant un peu. En effet, pour le système de fichiers (FAT32, NTFS...) l'allocation d'un espace ou sa restitution est coûteuse en temps. Il n'y a qu'à voir la différence de temps entre un copier/coller par l'explorateur, et un couper/coller du même volume. De ce fait en cas de suppression, la taille initiale est conservée, il y a simplement un "marquage" des enregistrements laissés libres par les suppressions. Les ajouts ultérieurs viendront réutiliser ces espaces vides.

Si après une suppression importante on souhaite récupérer l'espace disque correspondant, il est possible d'exécuter la fonction "HRéindexe" avec compression : là tout l'espace est restitué.

A noter que par un parcours séquentiel du fichier sur les numéros d'enregistrements, on peut passer sur les enregistrement marqués à réutiliser (cf. fonction "HEtat").

A noter d'autre part que ce mécanisme met clairement en évidence le fait qu'il ne faut jamais baser un traitement, encore moins une liaison, sur un numéro d'enregistrement puisqu'il n'est pas fixe.

Le numéro d'enregistrement des fichiers et des requêtes.

Lors du parcours d'un fichier, on peut connaître la position physique de l'enregistrement dans le fichier avec la fonction HNumEnr(). A partir de ce numéro, il est possible par la suite d'effectuer un accès direct à l'enregistrement avec la fonction "HLit", ou une modification avec "HMofifie(,)".

Par contre lors du parcours du résultat d'une requête, cette même fonction "HNumEnr" donne un numéro d'enregistrement dans la requête, mais pas celui de l'enregistrement d'origine dans le fichier. Pour avoir le numéro de l'enregistrement du fichier, il est possible d'utiliser la variable d'état "H.NumEnr" après une lecture dans la requête. On peut ainsi envisager après une lecture d'un enregistrement du résultat d'une requête, de modifier directement l'enregistrement correspondant dans le fichier avec "HMofifie(,)".

Attention par contre à l'utilisation du numéro d'enregistrement pour accéder aux données. Cette technique convient à un instant donné dans l'application. Par contre il ne faut pas utiliser ce numéro d'enregistrement par exemple pour lier des enregistrements. En effet, la position physique d'un enregistrement dans un fichier est modifiée lors d'opérations de maintenance. Pour les liaisons, l'utilisation de l'identifiant automatique est la meilleure solution.

A savoir avant de déployer sous Windows Vista...

Après, au fil des bêtas, les incertitudes sur les fonctionnalités qui seraient actives ou non par défaut, Windows VISTA est devenu une réalité. Le voile est levé, plus aucun incertitude ne subsiste l'UAC est active par défaut.

L'UAC, ou pour les initiés User Account Control, est une des fonctionnalités majeure de Windows VISTA. Elle doit permettre de redonner au système la sécurité qui faisait défaut aux précédentes versions.
Lorsqu'elle est active, et que le programmeur ne tient pas compte de ses spécificités, un panneau d'information avec l'icône ci-contre sera fréquemment donné à l'utilisateur final qui risque d'être dérouté. En effet par défaut les privilèges sont restreints, il faut jusqu'à 7 clics par exemple pour supprimer un raccourci sur le bureau.

Ainsi par défaut un message relatif à l'élévation des privilèges peut être affiché régulièrement. N'ayant qu'une expertise limitée sur le sujet, je n'aurai pas la prétention de vous décrire les méandres de ce mécanisme. En revanche un article Microsoft détaille ce qu'il faut absolument connaître de l'UAC avant d'aborder Windows VISTA. Je vous encourage donc vivement à le consulter.

Si besoin dans un tout premier temps, notamment pour le Développement, il est possible de désactiver l'UAC. Plus généralement, les fonctionnalités de VISTA peuvent être activées ou désactivées via ce mode opératoire.

Fonctions Wlangage dans les requêtes Hyper File avec l'opérateur "WL." (WINDEV 11)

Le moteur Hyper File Client/Serveur propose les procédures stockées, et de ce fait permet l'appel de fonctions du Wlangage, directement dans le code SQL des requêtes !

J'ai fait quelques tests de procédures stockées, et au passage j'ai utilisé cette possibilité. Cela va simplifier bien des traitements nécessitant le formatage du résultat d'une requête, en vue d'une exportation par exemple.

Un cas typique, je dois générer un fichier texte contenant des dates / numéros / montants de commandes. La date doit être lisible, et non pas au format "AAAAMMJJ" utilisé pour le stockage et l'affectation des champs ou colonnes de type date des interfaces.

Le résultat peut être obtenu immédiatement dans la requête, ce qui évite un traitement des données lors du parcours qui suit la requête.

Voici un exemple utilisant cette possibilité (il s'agit du code de l'image de ce billet) :

sNomFichierTXT est une chaîne = "c:\temp\commande.txt"
sListeCommande est une chaîne
sCodeSQL est une chaîne
sdReq est une Source de Données

sCodeSQL = [
SELECT WL.DateVersChaine(DateCommande) as DateCommandeformatée,
NumCommande,
TotalHT
FROM COMMANDE
]

HExécuteRequêteSQL(sdReq, sCodeSQL)

POUR TOUT sdReq
sListeCommande += [RC]+HRécupèreEnregistrement(sdReq,TAB)
FIN

fSauveTexte(sNomFichierTXT, sListeCommande)
LanceAppliAssociée(sNomFichierTXT)

A noter qu'il est possible de donner un formatage spécifique à la date avec le code SQL suivant :

sCodeSQL = [
SELECT WL.DateVersChaine(DateCommande,'JJJ JJ MMM AAAA') as DateCommandeformatée,
NumCommande,
TotalHT
FROM COMMANDE
]

Le fichier généré aura les dates dans un format "Ven. 28 Jan. 2000" par exemple.

Ndlr : la requête est volontairement simpliste pour l'illustration, elle permet dans un cas réel une sélection de données. Ce qui est très intéressant, c'est le code d'exportation qui est simplifié à l'extrême, et qui dit code simple, dit code plus rapide avec un risque d'erreur de programmation moindre !

Big Brother dans les applications ...

Dans un site en exploitation avec des données en perpétuelle mouvements, il n'est pas rare de rencontrer deux utilisateurs se disputant la propriété ... d'une erreur de manipulation.

- C'est toi il y a une semaine qui m'a dit de rentrer la nouvelle adresse.
- Oui mais ensuite je l'ai changée à nouveau, tu n'aurais pas du l'écraser !
- Non je ne l'ai pas changée à nouveau, c'est toi qui a oublié de la changer ...

Au final le conflit est stoppé en se tournant vers l'informaticien en charge du programme :

- [en coeur] : on vient te voir car l'application a encore perdu une adresse.

Ca sent le vécu pour beaucoup j'en suis certain. Un remède très efficace existe, c'est la journalisation. Cerise sur le gâteau, son activation se fait par une case à cocher dans la description des fichiers de l'analyse, aucune programmation n'est requise. La journalisation des écritures est suffisante pour régler tout litige tel que décrit ci-dessus.

Lorsque la journalisation est active, le menu contextuel des champs reliés aux rubriques de fichiers dispose d'une option "Historique..." qui permet de connaître toutes les valeurs successivement prises par la rubrique avec :
- la date de l'heure de modification,
- la valeur,
- le poste depuis lequel le changement a été fait,
- le login de l'utilisateur qui a fait le changement.

Toutes ces informations peuvent également être proposées par une interface spécifique de l'application, avec la fonction "HHistoriqueModification" qui retourne, entre autre, toutes ces informations sur les modifications.

Plus de doute sur qui a fait quoi !

Autre intérêt, la journalisation permet après une restauration de données de rajouter à la sauvegarde les dernières modifications.

Deux recommandations pour l'utilisation de la journalisation :
- utiliser dans le programme la fonction "HPoste" pour renseigner le journal précisément sur l'auteur des changements,
- placer les journaux sur un autre disque que celui contenant les données, avec la fonction "HChangeRepJNL".

Fichier en cours d'utilisation ... mais par qui ?

Un fichier de données reste parfois ouvert, alors que l'on est persuadé qu'il n'est plus utilisé, et que tous les programmes l'utilisant sont arrêtés...

Fichier en cours d'utilisation sur un autre poste ...
Le fichier est utilisé par un autre processus ...

Un utilitaire pouvant se substituer au gestionnaire de tâches est très commode, car il permet de connaître les processus qui utilisent un fichier. Il s'agit de Process Explorer, à toujours garder dans ses outils de travail. Anecdote, l'éditeur d'origine est Sysinternal, mais il semble qu'il y ait eu récemment une absorption de Microsoft. En effet, l'adresse http://www.sysinternals.com est directement redirigée sur un site Microsoft !

Bref, le menu "Find / Find handle or DLL" permet de donner le chemin d'accès au fichier de données en cours d'utilisation ... qui ne devrait pas l'être. La recherche vous donne ensuite la liste de tous les processus utilisant ce fichier.

Au passage, deux "pièges" pouvant aboutit à laisser un fichier de données ouvert ...
- fichier Hyper File, appeler la fonction "HFerme", mais oublier les "HAnnuleDéclaration" sur les requêtes exécutées sur ce même fichier,
- fichier externe : appeler "fCrée" et "fOuvre", et ne faire qu'un seul "fFerme". Pour éviter tout risque d'erreur, préférer "fOuvre" seule, mais avec le paramètre "foCréation".

Une image (celle du site Microsoft) de l'utilitaire complet, tel qu'il apparaît si vous le substituez au gestionnaire de tâches :

Importer un fichier texte dans un fichier Hyper File en formatant des dates

L'importation d'un fichier texte dans un fichier Hyper File est facilitée par la commande "HImporteTexte". Dans le cas favorable, l'importation est donc extrêmement simple grâce à cette fonction. Bien évidemment, suivant l'origine des données à importer, on se trouve en dehors du "cas favorable", il suffit par exemple qu'une date n'ait pas le format "AAAAMMJJ" attendu.

Dans ce cas, il faut avoir recours à une bonne vieille moulinette, facilitée par l'instruction POUR TOUT.

L'exemple ci-dessous utilise une demande du forum, ce sujet revenant assez régulièrement d'ou l'idée de ce billet. Il faut souligner qu'il s'applique aux dates, mais également à tout ce qui peut nécessiter une conversion avant la mise en base.

Soit un fichier texte à importer avec le contenu suivant (une tabulation sépare les colonnes, un retour chariot sépare les lignes ) :

15/03/2002 abc imo 560,33
19/04/2003 klo hap 561,00
12/06/2001 dol pme 7840,00

Si la date dans le fichier texte avait été codée sous la forme "20020315" la fonction "HImporteTexte" aurait fait l'affaire. Mais avec ce codage de date, il faut mouliner (une fois de plus ?). Voici un exemple de code pouvant être utilisé :

sEnregistrementsAImporter est une chaîne
sNouvelEnreg est une chaîne
sDateNonformatée est une chaîne

sEnregistrementsAImporter = fChargeTexte("C:\MonFichier.txt")

POUR TOUTE CHAINE sNouvelEnreg DE sEnregistrementsAImporter SEPAREE PAR RC

sDateNonformatée = ExtraitChaîne(sNouvelEnreg, 1, TAB)
Fichier.Date = ChaîneVersDate(sDateNonformatée, "JJ/MM/AAAA")
Fichier.Personne = ExtraitChaîne(sNouvelEnreg, 2, TAB)
Fichier.Libellé = ExtraitChaîne(sNouvelEnreg, 3, TAB)
Fichier.Montant = ExtraitChaîne(sNouvelEnreg, 4, TAB)

HAjoute(Fichier)
FIN

Une bonne évolution de la fonction "HImporteTexte", serait de pouvoir donner dans les délimiteurs un format de date comme le prend la fonction "ChaîneVersDate". Le champ d'action de "HImporteTexte" serait grandement étendu. J'en ai fait la suggestion au support.