Plusieurs requêtes fonctionnant bien sous WD7.5 et 8 ne fonctionnent
pas, ou seulement sporadiquement sous WD9.
J'ai noté que HExecuteRequêteSQL version 9 retourne beaucoup plus vite
le contrôle au programme que sous WD8. Ceci n'est pas documenté.
Vraiment étrange est que j'ai cru avoir trouvé des solutions sur mon PC
dev XP Pro avec 512MB RAM. Cela fonctionne aussi sous W2K Server avec
512MB RAM, mais ne fonctionne plus, ou pas toujours, sur deux PC XP Pro
avec 1GB RAM. Et puisque tout fonctionnait bien sous WD8, sur n'importe
quel PC, et selon PC Soft il n'y a qu'à compiler et continuer, je
deviens dingue.
J'ai aussi remarqué que les requêtes WD9 sont améliorés pour les accès
multi-utilisateurs, ce qui confirme une information reçu à ce propos en
juillet, je voudrais bien mettre à jour mon projet principal vers WD9.
Seulement, le comportement aléatoire des sous-requêtes me font
simplement peur de déployer la mise à jour. Je l'ai fait chez un client
et déjà mes propres tests étaient catastrophiques.
Je dois absolument trouver une solution pour les sous-requêtes, sans
pour autant détériorer trop la performance.
La sous-requête WD7.5/8 de l'exemple rendait le résultat de 38
enregistrements en 1-2 secondes. La solution fonctionnant sous WD9 prend
6-7 secondes. C'est mieux que ne pas fonctionner du tout, mais ça
confirme encore que HF Classic n'est toujours pas top pour les requetes
multi-utilisateurs.
Je cherche désespérément des améliorations de syntaxe pour les
sous-requêtes, ou alternatives performantes. Une requête peut avoir une
ou plusieurs sous-requêtes, parfois imbriquées. Merci pour vos idées.
Mat
Requête WD8, utilisant sous-requête avec clause IN, 1-2 secondes pour 38
résultats. Ne fonctionnant que sporadiquement sous WD9
===============================================================================
SELECT ...
FROM InvoiceDetail INNER JOIN Invoice ON InvoiceDetail.IDInvoice =
Invoice.IDInvoice
WHERE Invoice.IsNew = 0
AND Invoice.Date >= '20051001'
AND Invoice.Date <= '20051031'
AND Invoice.RecType >= 20
AND Invoice.RecType <= 29
AND Invoice.IDInvoice IN (SELECT InvoiceDetail.IDInvoice FROM
InvoiceDetail WHERE InvoiceDetail.IDCompany IN (SELECT AG.IDAddress FROM
Address_AddressGroup AS AG WHERE AG.IDAddressGroup=1))
ORDER BY BusinessSector, ProductRange, ProductGroup, IdProduct, Date
Solution pour WD9, donnant le même résultat, mais prenant 6-7 secondes
pour les 38 enregistrements
============================================================================
SELECT ...
FROM InvoiceDetail INNER JOIN Invoice ON (InvoiceDetail.IDInvoice =
Invoice.IDInvoice),
InvoiceDetail INNER JOIN Address_AddressGroup ON
(InvoiceDetail.IDCompany = Address_AddressGroup.IDAddress)
WHERE Invoice.IsNew = 0
AND Invoice.Date >= '20051001'
AND Invoice.Date <= '20051031'
AND Invoice.RecType >= 20
AND Invoice.RecType <= 29
AND Address_AddressGroup.IDAddressGroup=1
ORDER BY BusinessSector, ProductRange, ProductGroup, IdProduct, Date
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
mat
mat wrote:
correction: ...
6-7 secondes. C'est mieux que ne pas fonctionner du tout, mais ça confirme encore que HF Classic n'est toujours pas top pour les requetes multi-utilisateurs.
... multi-fichiers.
mat wrote:
correction:
...
6-7 secondes. C'est mieux que ne pas fonctionner du tout, mais ça
confirme encore que HF Classic n'est toujours pas top pour les requetes
multi-utilisateurs.
6-7 secondes. C'est mieux que ne pas fonctionner du tout, mais ça confirme encore que HF Classic n'est toujours pas top pour les requetes multi-utilisateurs.
... multi-fichiers.
mat
mat wrote: ..
Plusieurs requêtes fonctionnant bien sous WD7.5 et 8 ne fonctionnent pas, ou seulement sporadiquement sous WD9. J'ai noté que HExecuteRequêteSQL version 9 retourne beaucoup plus vite le contrôle au programme que sous WD8. Ceci n'est pas documenté. Vraiment étrange est que j'ai cru avoir trouvé des solutions sur mon PC dev XP Pro avec 512MB RAM. Cela fonctionne aussi sous W2K Server avec 512MB RAM, mais ne fonctionne plus, ou pas toujours, sur deux PC XP Pro avec 1GB RAM.
il semble le RAM ait une influence, mais je n'avais apparemment pas testé assez souvent. Sur les machines avec 512MB RAM, je n'arrive non plus à lancer cette même requête problématique 10 fois de suite. Au lieu de s'arrêter à la 1ère ou 2e fois, elle s'arrête à la 5e ou 6e.
...
Je cherche désespérément des améliorations de syntaxe pour les sous-requêtes, ou alternatives performantes. Une requête peut avoir une ou plusieurs sous-requêtes, parfois imbriquées. Merci pour vos idées.
Personne n'utilise les sous-requêtes ?
Pour ma part, des recherches ultérieures montrent que le problème est avec les sous-requête imbriquées. J'ai trouvé à contourner en mettant le résultat d'une sous-requête imbriquée dans une source de donnée, ce qui permet ne pas avoir plus d'une clause IN par requête. Ca complique les choses, mais au moins fonctionne chaque fois et n'est pas pénalisant au niveau de performance.
Salutations Mat
mat wrote:
..
Plusieurs requêtes fonctionnant bien sous WD7.5 et 8 ne fonctionnent
pas, ou seulement sporadiquement sous WD9.
J'ai noté que HExecuteRequêteSQL version 9 retourne beaucoup plus vite
le contrôle au programme que sous WD8. Ceci n'est pas documenté.
Vraiment étrange est que j'ai cru avoir trouvé des solutions sur mon PC
dev XP Pro avec 512MB RAM. Cela fonctionne aussi sous W2K Server avec
512MB RAM, mais ne fonctionne plus, ou pas toujours, sur deux PC XP Pro
avec 1GB RAM.
il semble le RAM ait une influence, mais je n'avais apparemment pas testé
assez souvent. Sur les machines avec 512MB RAM, je n'arrive non plus à
lancer cette même requête problématique 10 fois de suite. Au lieu de
s'arrêter à la 1ère ou 2e fois, elle s'arrête à la 5e ou 6e.
...
Je cherche désespérément des améliorations de syntaxe pour les
sous-requêtes, ou alternatives performantes. Une requête peut avoir une
ou plusieurs sous-requêtes, parfois imbriquées. Merci pour vos idées.
Personne n'utilise les sous-requêtes ?
Pour ma part, des recherches ultérieures montrent que le problème est
avec les sous-requête imbriquées. J'ai trouvé à contourner en mettant le
résultat d'une sous-requête imbriquée dans une source de donnée, ce qui
permet ne pas avoir plus d'une clause IN par requête. Ca complique les
choses, mais au moins fonctionne chaque fois et n'est pas pénalisant au
niveau de performance.
Plusieurs requêtes fonctionnant bien sous WD7.5 et 8 ne fonctionnent pas, ou seulement sporadiquement sous WD9. J'ai noté que HExecuteRequêteSQL version 9 retourne beaucoup plus vite le contrôle au programme que sous WD8. Ceci n'est pas documenté. Vraiment étrange est que j'ai cru avoir trouvé des solutions sur mon PC dev XP Pro avec 512MB RAM. Cela fonctionne aussi sous W2K Server avec 512MB RAM, mais ne fonctionne plus, ou pas toujours, sur deux PC XP Pro avec 1GB RAM.
il semble le RAM ait une influence, mais je n'avais apparemment pas testé assez souvent. Sur les machines avec 512MB RAM, je n'arrive non plus à lancer cette même requête problématique 10 fois de suite. Au lieu de s'arrêter à la 1ère ou 2e fois, elle s'arrête à la 5e ou 6e.
...
Je cherche désespérément des améliorations de syntaxe pour les sous-requêtes, ou alternatives performantes. Une requête peut avoir une ou plusieurs sous-requêtes, parfois imbriquées. Merci pour vos idées.
Personne n'utilise les sous-requêtes ?
Pour ma part, des recherches ultérieures montrent que le problème est avec les sous-requête imbriquées. J'ai trouvé à contourner en mettant le résultat d'une sous-requête imbriquée dans une source de donnée, ce qui permet ne pas avoir plus d'une clause IN par requête. Ca complique les choses, mais au moins fonctionne chaque fois et n'est pas pénalisant au niveau de performance.