Discussion :

[lololebricoleur]

Bonjour,

J'ai créé une appli qui utilise des fichiers de donnée Hyper file classic et je souhaite la faire fonctionner en réseau avec un partage des fichiers.
J'ai réglé tous mes problèmes sauf un.
Pour éviter les erreurs ou les conflits, je voudrais qu'un enregistrement ouvert pas un utilisateur ne puisse pas l'être par un autre.
Je cherche mais je ne trouve pas comment paramétrer ça.

Merci de votre aide svp.

[WDKyle]

Salut,

As-tu regardé du coté de la fonction HBloqueNumEnr ? http://doc.pcsoft.fr/fr-FR/?3044152

[lololebricoleur]

Je vais jeter un œil de ce côté.
Mais HF ne peut pas gérer lui même les restrictions ?

[dsr57]

Bonjour ,

je rejoins la solution de WDKyle avec la fonction HBloqueNumEnr

Mais HF ne peut pas gérer lui même les restrictions ?

Je ne comprend pas la question, que veux tu dire ?


Bon dev

[frenchsting]

Non, Windev ne gère pas les accès concurrents directement.v Initialement, il a été créé pour du mono-poste. C'est en partie pour cela que HFCS a été créé.

[PointCarreJo]

Salut,

Je confirme l'intervention de frenchsting car j'ai tous les problèmes du monde à gérer les accès concurrentiels. Après un appel directement au service technique de PC Soft, c'était vendredi dernier (le 12/06/2015), il m'exhorte de passer le plus rapidement possible en HFSQL client/serveur car les problèmes d'incohérence des données risquent d'être de plus en plus présents et fréquents.

Du coup, je m'y suis mis dès aujourd'hui. Il y a encore du TAF de mon côté.
Bon courage et bon développement,

Cordialement.

[lololebricoleur]

Merci de vos réponses,

Merci particulièrement à frenchsting car là, c'est clair et net.

Les choses sont maintenant claires.
Pourtant, il me semble que l'on trouve des discussions où la comparaison entre HF Classic et HF C/S ne fait apparaitre ce genre de limite
On trouve même des défenseurs de la solution HF Classic pour des appli réseau.
Que faut il en penser ?
Est-ce à dire qu'il y a d'autres paramètre à prendre en compte, notamment le nombre d'utilisateurs ?

[frenchsting]

Moins tu as d'utilisateurs sur une même base, moins il y a de risque d'accès concurrentiel.

Tu peux également avoir une base avec beaucoup d'utilisateurs et que ceux-ci n'accèdent jamais aux même tables.

L'intérêt de Classic est qu'il ne nécessite aucune installation. De plus, il est parfois compliqué d'accéder au serveur pour installer, paramétrer Manta mais également les droits Windows.

[R&B]

Bonjour

En plaçant un peu la question dans l'histoire sur HyperFile vers HFSQL on comprend mieux qu'elle a été l'évolution et ses raisons.

Initialement on était en Classic mono-poste. Là, il n'y a pas à gérer l'accès concurrentiel.
Ensuite on passe en Classic, multi-postes. Technologiquement, on utilise un répertoire partagé (protocole SMB utilisé dans Netbios / CIFS) et reporte la gestion de l'accès concurrentiel au développeur. En effet, il n'existe pas de mécanisme commun qui permet d'effectuer les réservations ou libération d'enregistrement.

Toutefois, HyperFile a souffert de cette architecture en raison des qualités diverses de la couche réseau. En effet, le contrôle d'information du partage étant effectué coté le client, la vitesse et la qualité d'écriture n'étant homogène, il pouvait se produire des erreurs qui deviennent critiques pour l'application. La solution, toujours coté client, était un palliatif : réorganisation, libération des transactions.

Avec l'arrivée du client/serveur (HyperFile 10), on change littéralement la donne.
En effet, comme pour la quasi totalité des bases, on voit arriver un serveur (en fait un service sur la machine hôte) qui va se charger d'interpréter les demandes des applications (les "clients") et donc être en mesure de gérer une couche réservation et transaction même si le client ne le fait pas.
Notez que le format des fichiers de stockage n'est pas en cause, c'est leur exploitation est centralisée dans un mécanisme commun cité plus haut.

Enfin, est même si cela n'a été forcément compris, la mouture 19 nous apporte une évolution du serveur en mode ACID.
On trouve ainsi une meilleure gestion de la fonction serveur dans sa gestion des ressources, une capacité à ne réserver que ce qui est nécessaire et donc une plus grande disponibilité du reste, une évolution sensible (conséquence du reste) des transactions... le tout sans changement pour le "client" si ce n'est une bien meilleure gestion de l'accès aux données. Au passage le moteur est étoffé de la description des données, ce qui permet aussi de travailler sur ce plan (SDD, descriptions dynamique)... bref une évolution très importante.

Conséquence, aujourd'hui, la programmation de l'accès concurrentiel demeure à la charge du client (l’application et donc au développeur) parce que cela n'a pas été adapté. En revanche les éléments qui ont conduit aux dysfonctionnements inhérents aux partages de fichiers ont été résolus.
Le blocage dynamique et exclusivement par le serveur est un concept qui pourrait être envisagé mais qui ne servirait pas tous les cas d’utilisation... ce qui limite sa validité. C'est un sujet à comparer avec les autres bases.

[lololebricoleur]

Je reviens sur mon post concernant le problème de la gestion des accès concurrentiels dans HFSQL Classic car j'obtiens des résultats étonnant.
Ou plutôt "nous" obtenons des résultats étonnant car depuis peu, je bosse avec un nouveau développeur dans ma boite (et un bon ;-)
Donc nous nous somme penché à deux sur le sujet avant de reposter.

Nous avons essayé différentes solutions en utilisant les fonctions dédiée à la gestion des blocages (HSurErreur, HBloqueNumEnr...)
Et nous l'avons testé dans 2 applications similaire en termes de mode de fonctionnement.
Dans la première, aucun souci, les fonctions réagissent exactement comme nous l'avons prévu.
Mais dans la seconde, c'est tout simplement comme si les fonctions de blocage n'existaient pas ! Elles ne provoquent rien ! L'application ne bloque absolument rien !
Nous avons comparer les analyses, les fichiers, les codes... et nous ne comprenons pas où est le problème.

Vous auriez une idée, une piste, une explication ?
Merci ;-)

[R&B]

Bonjour

Peut être un indice (peu probable mais bon...) : Dans le second, vérifier la configuration du projet : Description du projet> onglet Fichiers.
Il est possible de configurer le "Mode de gestion de fichiers" : "Mono Utilisateur" = pas de blocage, Multi Utilisateur = Blocages.

[JG_33]

Bonjour,

Voir dans la configuration du projet comme l'indique R&B
et
rechercher l'utilisation de la fonction hMode dans le code du projet, qui peut remettre en question les paramètres saisis dans la configuration.

[lololebricoleur]

Merci de votre aide,

J'ai vérifié la description du projet, multi utilisateurs activé dans les 2 cas (et autres paramètres identiques)
J'ai vérifié l'utilisation de la fonction Hmode mais je ne l'utilise pas.

[lololebricoleur]

Je reviens sur mon problème de gestion des accès concurrentiels en HFSQL Classic.
Je reprécise le contexte :
2 applis en HFSQL Classic
1 gère bien le blocage des enregistrement pour une utilisation en réseau
l'autre non
pas de fonction hmode utilisée, même paramètres d'analyse et de projet (multi utilisateurs)
utilisation des même fonction pour gérer le blocage :
- blocage en écriture sur les hlit
- utilisation de Hsurerreur pour gérer l'action en cas de blocage (inséré en déclaration globale de fenêtre)

Dans l'appli 1, le hsurerreur fait parfaitement son boulot
Dans l'appli 2, aucune réaction

Je désespère de trouver une explication

[lololebricoleur]

je viens de tester ce code :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
HLitRecherchePremier(PARoi,IDPARoi,Ref_Paroi,hBlocageEcriture)
HModifie(PARoi,hNumEnrEnCours)
HFiltre(PARoi_DETail,IDPARoi,Ref_Paroi)
Ouvre(FEN_PARoi_DETail)

Je lance l’exécutable en multi instance et je demande l'ouverture du même enregistrement sur les 2 instances l'une après l'autre
A minima, je devrais avoir une erreur au moment du hmodifie de la 2ème instance puisque que je demande à modifier un enregistrement déjà ouvert et vérouillé.
Et bien... non ! Nada.
Vous le croyez ça ?

[Hemgé]

Bonsoir,

Juste par acquit de conscience :

PARoi est bien un fichier et pas une requête ?
HLitRecherchePremier ne génère aucune erreur ?

Hemgé

[lololebricoleur]

Merci de ton aide Hemgé,

Oui, Paroi est bien un fichier.
Et non, je n'ai aucune erreur sur le HlitRecherchePremier. D'ailleurs, dans les 2 instances, la fenêtre qui affiche le données s'ouvre sans aucun soucis et sans aucun message particulier.
Je suis totalement largué et je ne trouve aucune astuce pour contourner le problème.

[JG_33]

Bonjour,

je viens de tester ce code :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
HLitRecherchePremier(PARoi,IDPARoi,Ref_Paroi,hBlocageEcriture)
HModifie(PARoi,hNumEnrEnCours)
HFiltre(PARoi_DETail,IDPARoi,Ref_Paroi)
Ouvre(FEN_PARoi_DETail)

Je lance l’exécutable en multi instance et je demande l'ouverture du même enregistrement sur les 2 instances l'une après l'autre
A minima, je devrais avoir une erreur au moment du hmodifie de la 2ème instance puisque que je demande à modifier un enregistrement déjà ouvert et vérouillé.
Et bien... non ! Nada.
Vous le croyez ça ?

Pour moi, ce code ne permet pas de tester le blocage. Il faudrait que les deux codes soient exécutés exactement en même temps, ce qui est improbable..
La fonction hmodifie débloque l'enregistrement, tout cela en quelques millisecondes

Pour tester le blocage, il faut utiliser hlitrecherchepremier avec option de blocage sans lancer de modification sur un poste, et tenter une modification du même enregistrement sur un autre poste


.

[Hemgé]

La fonction hmodifie débloque l'enregistrement, tout cela en quelques millisecondes .

Bonjour,

Cela a été ma première réflexion, sur base des comportements habituels.
Comme je n'utilise pas HFSQL et n'en ai quasi aucune expérience, j'ai regardé dans l'aide.
Cela n'est mentionné nulle part dans les diverses instructions et notamment pas dans HModifie.
Je n'ai pas trouvé d'article général sur le blocage des fichiers (mais ce n'est pas toujours évident de trouver la bonne entrée dans l'index)

Donc, je me suis abstenu, mais quid ?

Hemgé

[lololebricoleur]

Sauf erreur, la doc de pc soft dit bien que le hmodifie renverra une erreur si l’enregistrement est verrouillé non ?
Donc, quand je fais le hmodifie dans mon code de test, l'appli devrait applique la fonction hsurerreur non ?

Le seul moment où j'ai réussi à obtenir ce résultat c'est quand j'ai intercalé une fonction info(hinfoblocage....
La fenêtre d'info était déclenchée juste après le hlitpremier. Elle n'affichais d'ailleurs aucune info mais je crois que c'est normal.
Et bien pendant que cette fenêtre était visible sur une instance de l'appli, si j'essaye d'ouvrir sur l'autre instance le même enregistrement, la gestion d'erreur fonctionne.
Dès que la fenêtre d'info est fermée, l'enregistrement redevient ouvrable par plusieurs appli