Discussion :

[b_reda31]

Bonjour à tous,

J'ai développé une application qui permet d'ajouter des commandes (fichier command) depuis un poste connecté à internet.

La base est en hyperfilesql Client/Serveur accessible à distance.

L'application cliente (mono-utilisateur) accède à la base de donnée via le réseau internet et ajoute les enregistrements à la base. (j'utilise HDécritConnexion)
Pour le moment, tout fonctionne pour le mieux. (accès à la base et l'ajout d'enregistrement).

Ce qui m'importe dans la base de données, ce sont les fichiersCommand et LigneCommand.

Le fichier command regroupe les informations générales de la commande :

Command :

• IdCommande (Numérique Clé )
• IdClient (Numérique Clé avec Doublons)
• Date
• Total
• ...etc

Le fichier LigneCommand regroupe le détail d'une commande (Produits commandés avec Quantités...etc)

LigneCommand

• IdLigneCommande (Clé Unique Numérique)
• IdCommande (Numérique Clé avec Doublons)
• IdProduit (Clé Avec Doublons)
• QT
• ...etc

Au niveau de l'application cliente, l'utilisateur sélectionne le Client puis ajoute au fur et mesure les produits commandés dans une table mémoire (Table1) en précisant les quantités puis valide.
Voici le traitement que j'exécute lors de la validation

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
 
//Récuperer l'ID de la dernière commande et l'incrémenter
Idc est un entier;
Idc = HLitDernier(Command,IdCommande);
Idc++;
 
//Ajout d'une nouvelle Commande
HRAZ(command);
Command.IdCommande = Idc;
command.IdClient = ...
Command ....
HAjoute(Command);
 
 
//Ajout des Détails la commande LigneCommande
 
//Récupérer l'id du dernier LigneCommande et l'incrementer
IdL est un entier;
HLitDernier(LigneCommand,IdLigneCommande);
IdL = LigneCommand.IdLigneCommande;
IdL++;
 
//Ajout des Ligne de Commande depuis la table mémoire
Pour TOUTE Ligne de Table1
HRAZ(LigneCommand);
LigneCommand.idLigneCommande = IdL;
IdL++;
LigneCommand.IdCommande = Idc;
LigneCommand.IdProduit=table1.IdProduit
LigneCommand.Qt = ....
//...etc
HAjoute(LigneCommand)
 
FIN

En mono-utilisateur il n'y a aucun souci. Cependant, s'il y a plusieurs applications clientes qui tournent au même moment, je me dois de gérer l'accès concurrent.
En effet, plusieurs utilisateurs peuvent valider une commande au même moment ; avec le code actuel, il est possible d'avoir des incohérences dans la base de données (Ou une violation de clé).

Pour y remédier, j'ai pensé à la fonction HBloquerFichier juste avant l'accès au données :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
//On patiente tant que le fichier est bloqué (par une autre application)
TANTQUE HBloqueFichier(Command,hBlocageEcriture)=Faux
Temporisation(100, tempoDessin);
FIN
 
//----------------------------------------------------------------------
//Insertion des enregistrements
//......
//......
//----------------------------------------------------------------------
 
//Libérer le fichier
HDébloqueFichier(Command)

Est-ce une bonne solution ? Sinon pouvez-vous m'en proposer une meilleure?
Je précise que l'accès à la base se fait par réseau Internet, donc je tente de minimiser les accès au serveur.

Merci par avance

[SevenSoftware]

Bonjour,

HBloqueFichier est un peu "violent" selon moi... (et un peu spécifique à HFSQL)

Vous pouvez créer un fichier des numéros, contenant les derniers numéros de commandes, factures, etc... (rubriques: "Type" et "Dern_Num" par ex.)
Vous testez le blocage de l'enregistrement du fichier "Numéros" et, s'il est libre vous le bloquez et vous incrémentez le numéro. (le HModifie liberera l'enregistrement)
Ensuite, vous pouvez effectuer le traitement (dans une transaction, c'est encore mieux).

[R&B]

Bonjour

Le problème de la numérotation a été traité ici.
Evidemment, c'est à vous de pondre le code correspondant à l'algorithme.

L'accès concurrentiel en HFSQL C/S est le même qu'en HFSQL Classic : on bloque au strict moment de l'écriture et retourne en saisie si cela n'est pas possible. De plus on bloque le moins de temps possible.
Si a priori on tenterais de bloquer à la lecture et débloquer en écriture/abandon, le seul blocage à l'écriture est plus rationnel à l'usage. On en arrive à une base contenant des informations plus juste : le dernier qui a écrit a raison.
Je vous enjoins donc à créer un projet avec deux trois fichiers, y appliquer le rad compatible WD11 et aller voir dans les classes où et quand sont proposés les blocages... et tenter de comprendre pourquoi. C'est éloquent.

J'ajouterais que pour les écriture dans de multiples fichiers et à fortiori sur une base DISTANTE (de la machine qui exécute), il est OBLIGATOIRE d'utiliser les transactions. Ce mécanisme n'est pas superflu.
Ainsi, en cas de problème (blocage, erreur d'intégrité...) l'annulation de la transaction permet de ne pas corrompre votre base de données tout en revenant vers l'utilisateur avec un message adapté à la situation.

C'est le moment de vous poser les bonnes questions : comment garantir le fonctionnement de vos écritures dans la base ?
Dommage que cela arrive après le développement...

[b_reda31]

Bonjour,
Avant tout je vous remercie pour vos réponses très instructives pour moi.

HBloqueFichier est un peu "violent" selon moi... (et un peu spécifique à HFSQL)

Vous testez le blocage de l'enregistrement du fichier "Numéros" et, s'il est libre vous le bloquez et vous incrémentez le numéro

Je ne suis pas sur de vous suivre. Je le bloque avec HBloqueFichier ? Vous me conseillez alors de bloquer le fichier des numéros (compeut) plutôt que le fichier commande?
est-ce bien cela ?

Vous m'avez tous les deux conseillé d'utiliser un fichier à part contenant le(s) dernier(s) identifiant(s).
Est-ce avantageux à cause de la taille des fichiers, il est clair que le fichier compteur (2 voire 3 enregistrements) est bien moins volumineux que le fichier Commande. Est-ce pour cette raison que vous me conseiller d'utiliser un fichier compteur? ceci permet donc de supprimer les HLitDernier sur le fichier commande mais en même temps cela génére une certaine redondance de l'information ?

J'ajouterais que pour les écriture dans de multiples fichiers et à fortiori sur une base DISTANTE (de la machine qui exécute), il est OBLIGATOIRE d'utiliser les transactions.

cela va de soi, surtout dans mon cas (possibilité de perte de connexion pendant le traitement) je dois cependant avouer que je n'ai pas eu encore l'occasion d'utiliser les transactions dans mes projets,
mais ça a l'air très simple avec windev...Je vais m'y mettre

Dommage que cela arrive après le développement...

Je suis toujours en phase de développement, quand j'ai dis "j'ai développé" c'est pour dire que j'ai pu faire les tests de connexion qui sont positifs pour le moment mais le schéma complet de la base de données n'est pas encore défini...

[SevenSoftware]

Vous bloquez seulement l'enregistrement du fichier "Numéros" qui correspond au numéro souhaité.
Voir HLitRecherchePremier(fichier,clé,valeur,HBlocageLectureEcriture)

Bon dev

[b_reda31]

Vous bloquez seulement l'enregistrement du fichier "Numéros" qui correspond au numéro souhaité.
Voir HLitRecherchePremier(fichier,clé,valeur,HBlocageLectureEcriture)

Bon dev

Merci infiniment SevenSoftware. Voici le début du code du traitement de validation de commande. Cela marche très bien pour le moment :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
//On Patiente tantque l'enregistrement est bloqué
TANTQUE HLitRecherchePremier(Compteur,IdCompteur,1,hBlocageLectureEcriture)=Faux
 
	Multitâche(100);
 
FIN
 
//---Enregistrement Libre --> Début des Traitements
 
//........
 
//On met à jour l'identifiant et on débloque à l'aide de HModifie
Compteur.IdCommande=Compteur.IdCommande+1;
HModifie(Compteur);

Est-ce bon selon vous ?

[lubinfo]

bonjour,

si après avoir récupéré le n° incrémenté il y a possibilité d'abandon, penser à récupérer le compteur en gérant une pile des n° non utilisés

[b_reda31]

bonjour,

si après avoir récupéré le n° incrémenté il y a possibilité d'abandon, penser à récupérer le compteur en gérant une pile des n° non utilisés

Pour le moment, l'opération de validation est irréversible, cependant, en cas d'erreur l'utilisateur pourrai faire une demande d'annulation sur telle ou telle commande.
La commande sera toujours dans la base mais avec un tag "Annulé". Merci quand même pour votre proposition, j'y prends bien note pour d'autres applications