Discussion :

[jlbrd]

Bonjour,

si tu exécutes ces différentes requêtes via des programmes totalement différents, est-ce que tu as le même phénomène ?

Alors la solution que j’ai choisi est de créer un projet WD mode console auquel je passe la requête à exécuter et qui renvoie les résultats par mémoire partagée (fMemOuvre etc). Ensuite dans mon programme principal chaque thread appelle cet EXE puis affiche le résultat. Et là chaque résultat est affiché au fil des réponses. On peut donc dire que le blocage n’est ni causé par la base de données, ni par l’accès simultané en SELECT à une même table.

c'est que si 2 requêtes attaquent la même table, il peut arriver qu'elles entrent en conflit.

Uniquement en écriture et si on est dans une transaction qui bloque les tables.

Ici, tu as une application 'professionnelle'. Et tu utilises HFSQL

Non je suis sur SQL Server en SQLOLEDB

Pour revenir sur l'idée de tbc92, même si tes requêtes ne font que de la consultation, il est possible que quelqu'un écrive sur la table pendant ta requête.

Oui mais là on est sur une application lancée par plusieurs utilisateurs simultanément. Il y a toujours le risque qu’une donnée qu’on lit ne soit plus à jour car quelqu’un vient de la modifier. Ce risque existe toujours, avec ou sans Thread et tant pis si ce n’est plus tout à fait à jour.

Donc pas de solution à mon problème mais une solution de contournement

Bonne journée

[frenchsting]

Bonjour,

J'ai eu une idée, lourde certes, mais qui pourrait être testée. Mettre les champs qui servent à afficher les résultats dans une fenêtre interne. Le résultat de cal1 dans la FI_1, cal2 dans la FI_2, ... En exécutant, bien sûr, chaque requête dans la FI associée.

[jlbrd]

Bonjour, oui j'ai déjà testé ça ne change rien

[frenchsting]

Et en utilisant des timersys() / threads géré directement au niveau des procédures ?

[Narwe]

Hum...
Il est donc possible d'exécuter des requêtes en parallèles sur le serveur lorsque celles-ci sont lancées dans 2 programmes différents.
Je me dit que c'est la connexion à SQLODB qui fait que les requêtes sont exécutés une à une.
Si on lance 2 requêtes longues, est-ce que le temps est l'heure des 2 thread est le même ?
- si ce n'est pas le cas, c'est que les requêtes sont exécutées séquentiellement et que la première n'attends pas la fin de l'autre pour envoyer son résultat. Dans ce cas, il faudrait que chaque thread ouvre une nouvelle connexion SQLODB (si c'est possible).

[frenchsting]

+1 Narwe : j'allais répondre ça : que les requêtes sont empilées et finalement exécutées l'une après l'autre alors que le fait de lancer des exe différents montent chacun leur propre connexion.

Et donc, ton idée de se connecter à la bdd directement dans le thread pourrait paralléliser les requêtes.

[tbc92]

Côté SQLServer, j'imagine qu'on peut 'espionner' ce qui se passe. On peut voir à un instant t qui est connecté, et on doit pouvoir consulter un journal des actions : telle connexion, telle requête a tourné entre 11h50mn50sec340millièmes et 11h50mn50sec370millièmes. (Je suppose, en lisant en diagonale des choses sur SQLServer, je trouve une journalisation des insert/update/delete, mais pas des select)

Normalement, les différents thread utilisent des connexions différentes. Si dans ce journal, les identifiants des connexions sont les mêmes, c'est qu'il y a un loup.

[L.nico]

Bonjour,

Juste une piste à explorer.
Si les requêtes ne font que de la "sélection",

pourquoi ne pas utiliser un connecteur de données en lecture seule pour accélérer le traitement ?

bonne suite,

[jlbrd]

Bonjour,

Juste une piste à explorer.
Si les requêtes ne font que de la "sélection",

pourquoi ne pas utiliser un connecteur de données en lecture seule pour accélérer le traitement ?

bonne suite,

C'est à dire ?

[L.nico]

Bonjour,

Exemple de connexion :

Code windev :

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

1
2
3
4
5
6
7
8
9
10
11
12
MaConnexion est une Connexion
// Description de la connexion
MaConnexion.Utilisateur = "USER"
MaConnexion.MotDePasse = "PASSWORD"
MaConnexion.Serveur = "MONSERVEUR"
MaConnexion.BaseDeDonnées = "Base de données"
MaConnexion.Provider = hAccèsHFClientServeur
MaConnexion.Accès = hOLecture
MaConnexion.InfosEtendues = "Infos étendues"
MaConnexion.OptionsCurseur = hCurseurClient
 
HOuvreConnexion(MaConnexion)

En utilisant une connexion en lecture seule, on accélère sensiblement les requêtes de sélection.
On précise donc hoLecture
Dans mes applicatifs, j'utilise toujours 2 connexions, une en lecture/écriture (pour les requêtes de modifications, ajout et suppressions et pour les instructions hyperfile) et une connexion en lecture seule pour les requêtes de sélection.

Ensuite au niveau du code :

Code windev :

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

1
2
3
Rs est une source de données = "Rs" + Donneidentifiant()
Query est une chaine = "SELECT ....."
HExécuteRequêteSQL(Rs,MaConnexion,hRequêteSansCorrection,Query)

Il y a donc toujours 2 connexions actives par session applicative.
Et les requêtes de sélection sont exécutées plus rapidement.

Je suis certain de l'efficacité de cette méthode avec une base de type "SQL Server".
Cependant je ne travaille pas en HF, mais ça ne coute rien d'essayer

Bonne suite,