PC SOFT

FORUMS PROFESSIONNELS
WINDEVWEBDEV et WINDEV Mobile

Accueil → WINDEV 2024 → HCREATIONSIINEXISTANT("*") attention à l'utilisation
HCREATIONSIINEXISTANT("*") attention à l'utilisation
Débuté par Olivier, 13 sep. 2018 17:06 - 9 réponses
Membre enregistré
88 messages
Popularité : +2 (2 votes)
Posté le 13 septembre 2018 - 17:06
Bonjour,

Ceci est une mise en garde pour ceux qui utiliseraient des tables Microsoft SQL server en connexion OLEDB, et d'autres tables HFSQL dans une même application.
Voici ce qui nous est arrivé récemment, et qui nous a planté l'ERP (sous Microsoft SQL), nous obligeant à arrêter la production jusqu'à trouver le pourquoi du problème.

J'explique le contexte :

- Nous avons un programme existant depuis 15 ans, qui gère le suivi de production en temps réel, et que l'on fait évoluer au fur et à mesure des mises à jour Windev (actuellement version 23)

- Dans ce programme des tables HFSQL sont définies, ainsi que des tables Microsoft SQL de notre ERP, que nous avons déclaré dans l'analyse via une connexion OLEDB.

- A l'initialisation du programme il y a un HcreationSiInexistant("*"). Je pensais que cette instruction ne concernait que les tables WINDEV, MAIS IL N'EN EST RIEN..... Toutes les tables, y compris les tables SQL sont manifestement concernées.

- Le problème est survenu sur des PC connectés en WIFI dans l'usine. La connexion WIFI devait être défaillante (c'était lors de la canicule), et des micro-coupures de réseau ont du avoir lieu.
Nous ne nous expliquons pas comment cela s'est passé, mais la coïncidence a voulu certainement qu'une coupure ait eu lieu au moment du lancement du programme, et celui-ci ne trouvant pas les tables SQL, les a supprimées et recrées VIDES..... quand il s'agit des tables du personnel, des ordres de fabrication, et des gammes et nomenclatures, on comprend que la production soit un "peu désorganisée".

Cela s'est reproduit 8 à 9 fois en l'espace de 2 jours, le temps que l'on trouve ce qui se passe, et la parade au problème.....

On a bien la preuve que c'est notre programme WINDEV qui est à l'origine de ce problème, des logs ont été retrouvés sous Microsoft SQL, précisant l'heure exact à laquelle cela s'est passé, le nom du programme à l'origine du DROP TABLE, et CREATE TABLE..... (et c'est bien le nôtre).

Vous voila avertis.
Cordialement,

--
Olivier Heckel
Membre enregistré
2 566 messages
Popularité : +222 (260 votes)
Posté le 13 septembre 2018 - 17:24
Bonjour,

Merci pour ce retour d'expérience. Je n'utilise personnellement cet ordre que sur du HFSQL. Pour tout le reste je crée mes scripts SQL à la main afin de ne pas avoir de surprise (j'en ai eu sur du PostgreSQL).

--
Cordialement,

Philippe SAINT-BERTIN
Membre enregistré
188 messages
Popularité : +12 (12 votes)
Posté le 13 septembre 2018 - 19:42
Ouch !

Voilà qui me conforte dans mon choix de me passer d'analyse pour les bases SQL.
Vive le SQLExec et les requêtes construites à la main. On sait ce que l'on fait et tout est optimisé.

Mais bon le user applicatif connecté à la base SQL ne devrait pas avoir de tels droits (DROP, CREATE ....)
Merci pour l'alerte et bon courage pour la reprise

--
Côme, Clairinfo
Membre enregistré
88 messages
Popularité : +2 (2 votes)
Posté le 14 septembre 2018 - 10:29
Côme a écrit :
Ouch !

Voilà qui me conforte dans mon choix de me passer d'analyse pour les bases SQL.
Vive le SQLExec et les requêtes construites à la main. On sait ce que l'on fait et tout est optimisé.

Mais bon le user applicatif connecté à la base SQL ne devrait pas avoir de tels droits (DROP, CREATE ....)
Merci pour l'alerte et bon courage pour la reprise

--
Côme, Clairinfo


Tout à fait d'accord sur le fait que le user ne devait pas avoir les droits qu'il avait.
Mais cela a été mis en place il y a 15 ans, et à l'époque nous étions moins regardants.
Toutefois, je pense qu'à l'origine, le drive OLEDB n'avait que des accès en lecture, et ce n'est qu'au fur et à mesure des évolution de Windev que la "puissance" des instructions a évolué.
Ce n'est pas, à ma connaissance, marqué dans l'aide que le HCREATIONSIINEXISTANT("*") "s'occupe" aussi des tables autres que celle de Windev, d'où mon message de mise en garde.

--
Olivier Heckel
Membre enregistré
326 messages
Popularité : +15 (19 votes)
Posté le 14 septembre 2018 - 11:30
Bonjour.
Personnellement le HCREATIONSIINEXISTANT, je ne l'utilise que pour créer des tables après création dans l'analyse. Ensuite lors d'une nouvelle table je mets eventuellement HCREATIONSIINEXISTANT(ma_table).
Je ne vois pas l'utilité de laisser en permanence le HCREATIONSIINEXISTANT("*") si ce n'est pour créer une base vide au premier démarrage d'une application !
-> Par contre je ne comprends pas bien pourquoi il a été créé des tables vides dans SQLServer: l'application ne voit pas les tables mais est bien connectée à base et elle crée les tables ? Bizarre... C'est plutôt la connexion OLEDB qui est "fautive"

Michel.
Membre enregistré
1 143 messages
Popularité : +50 (142 votes)
Posté le 14 septembre 2018 - 16:38
Bonjour,

Je suis d'accord avec mlion quant à l'usage de HCreationSiInexistant(). Et même si on ne l'utilise pas, il me semble qu'au premier ajout dans une table, si elle n'existe pas, Windev crée la table en question automatiquement avant d'ajouter la donnée (est-ce le cas sur SQL server?!)

En fait je trouve assez rapide de conclure que c'est votre programme qui est en cause parce que c'est une situation anormale (coupures) qui a causé un fonctionnement anormal (Windev-->SQL), et donc en temps normal, l'application fonctionne bien. On a beau essayer d'anticiper les mauvaises manipulations des utilisateurs, on n'est jamais à l'abri d'incidents de ce type.

Personnellement j'essaierais d'analyser la solution sous deux autres angles :
-Comment faire pour qu'il n'y ai plus de micro coupures ? (pb d'électricité)
-Comment faire pour que le programme s'assure bien que la liaison à la base est correcte ?

Pourquoi je dis cela ? juste parce qu'aujourd'hui c'est HCreationSiInexistant qui est en cause, mais que se passera-t-il avec une requête simple de mise à jour dans le même contexte ? Vous avez mis le doigt sur un problème qui risque de se reproduire...

Thierry
Membre enregistré
137 messages
Popularité : +7 (7 votes)
Posté le 14 septembre 2018 - 21:11
bonjour,
je ne suis pas tellement d’accord sur l’inutilité d'utiliser HCreationSiInexistant() au lancement du logiciel.

en effet HCreationSiInexistant() vérifie aussi la structure des tables et déclenche une erreur si il y a eu une modification dans l'analyse
de mon cote je utilise toujours des perso-dossiers l'analyse HFSQL est dans un perso-dossier et les analyses externes SQL Server, MySql, ... sont dans d'autres perso-dossiers

je lance un HCreationSiInexistant(persoDossierHFSQL) , ainsi seulement les fichiers HFSQL sont pris en compte et en cas d'erreur je lance une modification automatique des données via ligne de commande.
cela permet de mettre à jour automatiquement la base de données et ne touche jamais au bases tierces.
Posté le 20 septembre 2018 - 16:07
Bonjour,

J'utilise également un mixte de HFSQL et des tables SQL Server en OLEDB
et
l'utilisation de "PERSO DOSSIER" est parfait pour gérer cela.
Membre enregistré
1 143 messages
Popularité : +50 (142 votes)
Posté le 20 septembre 2018 - 18:30
Je ne maîtrise pas les PERSO DOSSIER. est-ce à dire qu'on peut avoir une description HF Classic dans un perso dossier et et la même description en HFSQL CS sur un serveur distant ?
Membre enregistré
137 messages
Popularité : +7 (7 votes)
Posté le 25 mars 2024 - 10:15
Bonjour à tous, je ressort ce post ,
Effectivement faire très attention avec HCreationSiInexistant("") si on utilise des connexions OLEDB ou ODBC vers SQL Serveur ca nous ai arrivé aussi d'avoir des suppressions et recréaction de tables dans SQLServeur avec la perte de toutes les données.

aussi faire attention a ne pas cocher la case "Création des fichiers de données lors du premier accès" dans la descritption du projet ( ca reviendrait à avoir un HCreationSiInexistant("") et c'est le meme probleme qui peut se produire).

Utiliser les persos Dossiers dans l'Analyse pour HCreationSiInexistant et decocher la case dans la descritption projet est la solution à garder.