|
FORUMS PROFESSIONNELS
WINDEV, WEBDEV et WINDEV Mobile |
| | | | | |
| Requêtes longues, longues..... |
| Débuté par mlion, 30 aoû. 2004 12:33 - 2 réponses |
| |
| | | |
|
| |
Posté le 30 août 2004 - 12:33 |
Versions windev : toutes depuis la 7.5
Base de données : Hyper File sur disque réseau d'un serveur NT
Postes connectés : NT4, 2000 ou XP
Problème :
Pour une connexion sur la base de données les temps sont "normaux"
Pour deux, voire plus de connexions les temps sont normaux aussi tant que
aucune écriture n'a eu lieu. Dès qu'une écriture (MAJ Ajout ou suppression)
s'est faite les temps sont augmentés de manière flagrande pour les requêtes
SQL (faites avec l'éditeur de requêtes). Un affichage de requête immédiat
pour un sel utilisateur connecté peut alors prendre 10 s !
Un exemple de requête :
SELECT DISTINCT Demande.Semaine AS Semaine,
Demande.CAP AS CAP,
Demande.IDAgence AS IDAgence,
MIN(Demande.jour_debut) AS le_minimum_jour_debut,
MAX(Demande.Jour_fin) AS le_maximum_Jour_fin
FROM Demande
WHERE Demande.CAP = 0
AND Demande.IDAgence <> 1
GROUP BY Demande.Semaine, Demande.CAP, Demande.IDAgence
ORDER BY Semaine ASC, IDAgence ASC
Des clés sont sur jour_debut et jour_fin ainsi que sur CAP et IDAgence !!!!
De toute manière cela n'explique pas la détérioration des temps de réponse
pour une deuxième requête.
De plus une simple requête de MAJ ->
UPDATE Demande
SET CAP = 1
WHERE Demande.jour_debut BETWEEN {param1} AND {param2}
AND Demande.IDAgence = {param3}
Qui porte sur quelques dizaines d'enregistrements sur 13 000 enregistrements
passe de "immédiate" à 10 s aussi !!!
Cas de figures testés :
table directe sur requête
Exécution de requête puis MAJ d'une table mémoire
Toujours hannuledéclaration à la sortie de la fenêtre affichant la table
J'ai essayé de fermer les fichiers après la requête de sélection, après les
MAJ de tables fichiers
J'ai modifié la base de reqistre suite aux articles Microsoft sur l'opportunistic
locking -> RAS
Conclusion : des idées à me donner ????
PS : pour des affichages de tables style ceux générés par le RAD en W-langage
-> pas de problèmes !
Je ne me vois pas remplacer toutes les requêtes de sélection et mise à jour
par des hfiltre.....
Quelqu'un a t'il aussi ce genre de problèmes ???
Quelqu'un a t'il une solution ???
Merci.
Michel |
| |
| |
| | | |
|
| | |
| |
Posté le 30 août 2004 - 15:24 |
Jettes un coup d'oeil à ce document : http://www.pcsoft.fr/st/telec/windev7/HyperFileSurServeurWindows.pdf
A+
Adrien.
"Michel" <mlion@tele2.fr> wrote:
Versions windev : toutes depuis la 7.5
Base de données : Hyper File sur disque réseau d'un serveur NT
Postes connectés : NT4, 2000 ou XP
Problème :
Pour une connexion sur la base de données les temps sont "normaux"
Pour deux, voire plus de connexions les temps sont normaux aussi tant que
aucune écriture n'a eu lieu. Dès qu'une écriture (MAJ Ajout ou suppression)
s'est faite les temps sont augmentés de manière flagrande pour les requêtes
SQL (faites avec l'éditeur de requêtes). Un affichage de requête immédiat
pour un sel utilisateur connecté peut alors prendre 10 s !
Un exemple de requête :
SELECT DISTINCT Demande.Semaine AS Semaine,
Demande.CAP AS CAP,
Demande.IDAgence AS IDAgence,
MIN(Demande.jour_debut) AS le_minimum_jour_debut,
MAX(Demande.Jour_fin) AS le_maximum_Jour_fin
FROM Demande
WHERE Demande.CAP = 0
AND Demande.IDAgence <> 1
GROUP BY Demande.Semaine, Demande.CAP, Demande.IDAgence
ORDER BY Semaine ASC, IDAgence ASC
Des clés sont sur jour_debut et jour_fin ainsi que sur CAP et IDAgence !!!!
De toute manière cela n'explique pas la détérioration des temps de réponse
pour une deuxième requête.
De plus une simple requête de MAJ ->
UPDATE Demande
SET CAP = 1
WHERE Demande.jour_debut BETWEEN {param1} AND {param2}
AND Demande.IDAgence = {param3}
Qui porte sur quelques dizaines d'enregistrements sur 13 000 enregistrements
passe de "immédiate" à 10 s aussi !!!
Cas de figures testés :
table directe sur requête
Exécution de requête puis MAJ d'une table mémoire
Toujours hannuledéclaration à la sortie de la fenêtre affichant la table
J'ai essayé de fermer les fichiers après la requête de sélection, après
les
MAJ de tables fichiers
J'ai modifié la base de reqistre suite aux articles Microsoft sur l'opportunistic
locking -> RAS
Conclusion : des idées à me donner ????
PS : pour des affichages de tables style ceux générés par le RAD en W-langage
-> pas de problèmes !
Je ne me vois pas remplacer toutes les requêtes de sélection et mise à jour
par des hfiltre.....
Quelqu'un a t'il aussi ce genre de problèmes ???
Quelqu'un a t'il une solution ???
Merci.
Michel
|
| |
| |
| | | |
|
| | |
| |
Posté le 30 août 2004 - 16:01 |
Merci mais je l'ai déjà décortiqué !!!
-> si tu lis mon mail tu comprendras que j'ai déjà balayé presque toutes
les solutions.....
Merci quand même.
Michel.
"Adrien" <adrien.titou@ifrance.com> wrote:
Jettes un coup d'oeil à ce document : http://www.pcsoft.fr/st/telec/windev7/HyperFileSurServeurWindows.pdfA+ Adrien. "Michel" <mlion@tele2.fr> wrote:
Versions windev : toutes depuis la 7.5
Base de données : Hyper File sur disque réseau d'un serveur NT
Postes connectés : NT4, 2000 ou XP
Problème :
Pour une connexion sur la base de données les temps sont "normaux"
Pour deux, voire plus de connexions les temps sont normaux aussi tant que
aucune écriture n'a eu lieu. Dès qu'une écriture (MAJ Ajout ou suppression)
s'est faite les temps sont augmentés de manière flagrande pour les requêtes
SQL (faites avec l'éditeur de requêtes). Un affichage de requête immédiat
pour un sel utilisateur connecté peut alors prendre 10 s !
Un exemple de requête :
SELECT DISTINCT Demande.Semaine AS Semaine,
Demande.CAP AS CAP,
Demande.IDAgence AS IDAgence,
MIN(Demande.jour_debut) AS le_minimum_jour_debut,
MAX(Demande.Jour_fin) AS le_maximum_Jour_fin
FROM Demande
WHERE Demande.CAP = 0
AND Demande.IDAgence <> 1
GROUP BY Demande.Semaine, Demande.CAP, Demande.IDAgence
ORDER BY Semaine ASC, IDAgence ASC
Des clés sont sur jour_debut et jour_fin ainsi que sur CAP et IDAgence
!!!!
De toute manière cela n'explique pas la détérioration des temps de réponse
pour une deuxième requête.
De plus une simple requête de MAJ ->
UPDATE Demande
SET CAP = 1
WHERE Demande.jour_debut BETWEEN {param1} AND {param2}
AND Demande.IDAgence = {param3}
Qui porte sur quelques dizaines d'enregistrements sur 13 000 enregistrements
passe de "immédiate" à 10 s aussi !!!
Cas de figures testés :
table directe sur requête
Exécution de requête puis MAJ d'une table mémoire
Toujours hannuledéclaration à la sortie de la fenêtre affichant la table
J'ai essayé de fermer les fichiers après la requête de sélection, après
les
MAJ de tables fichiers
J'ai modifié la base de reqistre suite aux articles Microsoft sur l'opportunistic
locking -> RAS
Conclusion : des idées à me donner ????
PS : pour des affichages de tables style ceux générés par le RAD en W-langage
-> pas de problèmes !
Je ne me vois pas remplacer toutes les requêtes de sélection et mise à
jour
par des hfiltre.....
Quelqu'un a t'il aussi ce genre de problèmes ???
Quelqu'un a t'il une solution ???
Merci.
Michel
|
| |
| |
| | | |
|
| | | | |
| | |
| | |
| |
|
|
|