J'aimerais voir cette requête, mais j'imagine que c'est un problème avec une sorte d'itérateur, et bien que je ne puisse penser à aucune situation où c'est possible, je parie que cela vient d'un mauvais moment/cas/curseur ou une tonne de vues mal implémentées.

@chopeen Vous pouvez modifier la façon dont vous calculez ces statistiques et conserver à la place un tableau séparé de toutes les statistiques par produit. Lorsqu'une commande est passée, parcourez les produits et mettez à jour les enregistrements appropriés dans le tableau des statistiques . Cela déplacerait une grande partie de la charge de calcul vers la page de paiement plutôt que de tout exécuter dans une énorme requête lors de l'exécution d'un rapport. Bien sûr, certaines statistiques ne fonctionneront pas aussi bien de cette façon, par exemple. suivre les prochains achats des clients après l'achat d'un produit particulier.

Pour SQL Server 2005, je vous recommande d'utiliser des variables de table et de créer partiellement les données au fur et à mesure.

Pour ce faire, créez une variable de table qui représente votre jeu de résultats final que vous souhaitez envoyer à l'utilisateur.

Ensuite, trouvez votre table principale (disons la table des commandes dans votre exemple ci-dessus) et extrayez ces données, ainsi qu'un peu de données supplémentaires qui ne sont qu'à une jointure (nom du client, nom du produit). Vous pouvez faire un SELECT INTO pour mettre cela directement dans votre variable de table.

À partir de là, parcourez la table et pour chaque ligne, effectuez un ensemble de petites requêtes SELECT qui récupèrent toutes les données supplémentaires dont vous avez besoin pour votre ensemble de résultats. Insérez-les dans chaque colonne au fur et à mesure.

Une fois terminé, vous pouvez alors faire un simple SELECT * à partir de votre variable de table et renvoyer cet ensemble de résultats à l'utilisateur.

Je n'ai pas de chiffres concrets pour cela, mais il y a eu trois cas distincts sur lesquels j'ai travaillé jusqu'à présent où ces petites requêtes ont en fait fonctionné plus rapidement que de faire une requête de sélection massive avec un tas de jointures.< /p>

Publier la requête :D

De plus, j'ai l'impression que l'un des problèmes possibles pourrait être d'avoir une tonne (lire 200) de tables de noms/valeurs qui pourraient être condensées en une seule table de recherche.

J'ai eu le même problème... ma boîte de développement exécute SQL Server 2008 (la vue fonctionnait bien) mais en production (avec SQL Server 2005), la vue ne fonctionnait pas. J'ai fini par créer des vues pour éviter cette limitation, en utilisant les nouvelles vues dans le cadre de la requête dans la vue qui a généré l'erreur.

Un peu idiot étant donné que l'exécution logique est la même...