Discussion :

[le_binr]

Bonjour,

J'ai une appication en VB avec plusieurs select et insert imbriqués qui permettent de dupliquer plusieurs fiches :

select
do while
select
do while
insert
end
end


Du coup j'ai plusieurs connections SQL en attente. Mon programme marche bien, sauf que lorsque je dépasse un certains nombre fiche, ça ne marche plus.

Par exemple si mon programme sélectionne 50 fiches, il les copies bien. Par contre si j'en ai 200, ça bloque dés la première.

J'ai un message d'erreur indiquant que le délais d'attente est expiré, mais j'ai plutôt l'impression que c'est un problème de spool.

Par exemple si mon programme sélectionne 200 fiches et s'apprète à le copier (insert) rien ne se passe (avant le message d'erreur de délais d'attente terminé). Mais j'ai le temps de lancer un requête en ligne de commande dans sql server 2005 explress. Et la ma requête reste en attente (le cercle vert du traitement en cours ne s'arrête jamais). Si je quitte mon application VB, ça libère de la charge (ou du pool ?) et ma requête dans sql server fonctionne.

Ca fait plusieurs jours que je recherche de la documentation dessus, mais je ne trouve pas de solution. J'ai essayé de gérer le nombre de pool dans ma connection SQL sous vb (Pooling=True ; Max Pool Size=400 ; Max Pool Size=500 voir même Pooling = false) mais rien à faire.

Quelqu'un aurait-il déjà eu ce problème ? Est-ce bien un problème de pool ? (je pense que oui) et n'y a t-il pas moyen de l'augmenter dans sql serveur ?

Merci d'avance, j'espère que quelqu'un pourra me donner un coup de main, car toutes mes tentatives on été infractueuse et je me demande même si ça ne serait pas SQL 2005 express qui serait limitée ?

[SQLpro]

Les fiches cela n'existe pas en SQL.... Nous ne savons pas de quoi vous parlez. SQL manipule des tables et n'a pas de relation direct avec des concepts de fiches, état imprimé ou autre objet visuel.

A +

[le_binr]

Bonjour,

Merci de votre réponse.

Désolé, je me suis mal exprimé en parlant de "Fiche". Une fiche correspond en fait à une requête SQL de type "Insert". Je n'ai pas été très clair dans mon explication, je vais essayer de vous la reformuler plus simplement.

Dans mon programme VB j'ai une fonction récursive qui interroge ma base SQL avec des requêtes de type "SELECT". A chaque fois que j'ai une "SELECT" j'ai ensuite un "INSERT". Mais vu que c'est récursif, je laisse beaucoup de requête SQL ouverte (mais je les referme bien à la fin de mon programme). Le problème c'est que si j'en ai trop d'ouverte le serveur SQL me bloque et j'ai plus le droit d'en executer tant que mon programme VB n'est pas fermé (ce qui libère de nouveau l'accès). C'est pour cela que le problème doit venir des "POOL" limités sous SQL server (un peu comme si un serveur d'impression était limité à 100 impression dans la file d'attente, et que mois je lui en demandait 101, ça bloque).

Mais je ne voit pas comment identifier mes "POOL" dans l'administration de SQL 2005 express, et encore moins modifier ces paramètre (acepter par exemple 150 POOL).

Merci d'avance, j'espère avoir été plus clair.

[SQLpro]

SQL est fait pour faire du code ensembliste. Il n'est pas fait pour faire du ligne à ligne, qui plus est dans un outil lent d'un langage abscon (pour ne pas dire M..) et qui plus est par un traitement récursif !
N'oubliez pas que BASIC est l'acronyme de Beginner All Purpose Symbolic Instruction Code que l'on pourrait traduire par langage pour débutant boutonneux en informatique ;-) et a été créé en 1964, soit 6 ans après Cobol...

Entre nous, pensez vous que votre façon de développer une application bases de données relationnelle soit adaptée ? Aujourd'hui faire une requête massivement récursive (hé oui, ça existe) sur plusieurs centaines de ligne se fait en moins d'une secondes sur un serveur base de gamme !

Lisez l'article que j'ai écrit à ce sujet :
http://sqlpro.developpez.com/cours/s...te-recursives/

En utilisant les bases de données à contre emploi, n'espérez pas obtenir de bons services !!!

A +

[le_binr]

Merci pour ta réponse SQLpro... je ramasses mes dents et je vais essayer de modifier mon code. Mais je n'ai pas saisie le contenu de ton article au sujet de la récursivité (j'ai déjà eu du mal à faire de la récursivité dans mon code)
;-)

Je n'ai pas encore assez d'expérience en VB et SQL car il s'agit de mon premier programme, et je vois que le chemin est long pour optimiser tout ça.

Mon programme est un gestionnaire de produits qui fonctionne comme un explorateur. Mes produits sont classés dans des dossiers et des sous-dossiers sur 7 niveaux maximum. Lorsque je veux dupliquer un dossier avec tous les sous-dossiers enfants j'ai voulu faire ça proprement avec une fonction récursive, mais je ne pensais pas qu'au bout du compte s'était pas compatible avec l'utilisation de SQL Server.

La problématique est qu'à chaques fois que j'enregistre un élément parent il faut que je copie aussi sont élément enfant (récursivement jusqu'au 7ème niveau) et je n'ai pas assez de connaissance pour rassembler tout ça dans une seul requête SQL. Est-ce possible (car à chaque fois que j'enregistre un élément enfant, j'ai besoin de l'ID de son parent pour faire le lien entre l'enfant et le parent)

Je vais chercher dans cette direction, car si je pouvait le faire en une seule requête SQL ça serait la solution.

Mais aillant du mal à comprendre ton article sur la récursivité (rassurez-moi, c'est un niveau expert ça !) je sents que les nuits vont être courtes.
;-)

En tout cas merci pour toutes ces infos.

[WOLO Laurent]

j'ai voulu faire ça proprement avec une fonction récursive, mais je ne pensais pas qu'au bout du compte s'était pas compatible avec l'utilisation de SQL Server.

Faux, SQL Serveur n'a pas du mal à faire de la récursivité !
C'est élégant mais c'est complexe pour un débutant.
Pouvez vous postez :
1-le shemas de votre DB,
2-Votre code VB pour qu'on nous puissions essayer de vous aider ?

[le_binr]

J'ai fais un test qui confirme tes propos WOLO. J'ai restauré une copie de ma base de données actuel que j'avais fait il y a quelques jours (j'ai fait uen copie, je ne l'ai pas restauré). Et là, étrange tout fonctionne sans problème. J'ai même rajouté des informations pour que ma requête récursive soit plus grande est tout est OK. Avec 160 requêtes lancées et ma base de données qui date de quelques jours, ça marche sans problème alors qu'avec la base d'origine qui à 150 requêtes ça bloque. J'ai donc comparé les données de ma base pricipale (qui ne marche pas) que je veux copier avec ceux de ma base qui fonctionne (l'ancienne), et il n'y a aucune différence (c'est normal car le logiciel n'est en production que chez uen seule personne qui ne modifie pas cette partie des données). Alors pourquoi avec cette ancienne base ça fonctionne sans problème ? Et en plus j'ai beaucoup plus de données dans cette ancienne base car j'avais fait pleins de test.

Est-ce que ça viendrait d'un paramétrage diférent de la base SQL ?
Car vue que c'est une copie de la base, même les clefs primaire sont identiques, alors pourquoi ce bloquage ? La seule difference c'est que j'ai rajouté un champ dans mes deux bases. Mais pourtant ce champ à les mêmes caractéristique. Et quand je fais une seule requête de type "insert" ça marche bien. C'est seulement quand je fait des insert avec ma fonction récursive, et avec certaines données (avec d'autres données de la même base, ça marche sans problème).


Etrange non ?

Merci de votre aide, c cool ;-)

[SQLpro]

Si écrire des requêtes récusive vous rebute alors utilisez le modèle intervallaire qui permet de gérer une arborescence dans une table sans avoir plus aucune récursivité à gérer.

Lisez l'article que j'ai écrit à ce sujet :http://sqlpro.developpez.com/cours/arborescence/
Vous y trouverez même les primitives de manipulation d'un arbre.

A +

[le_binr]

Dans le moteur d'activité de SQL server, je retrouve bien ma requête d'insertion qui bloque :

commande : INSERT
Etat : suspended
temps d'attente : 209343
Type d'attente : LCK_M_IX
UC : 0
E/S physique : 0
Bloqué par 56



56, c'est le PID du processus qui sélectionne les données de ma base (SELECT) que je veux dupliquer (INSERT) :

Commande : SELECT
Etat : runnable
Temps d'attente : 15
Type d'attente : ASYNC_NETWORK_IO
UC : 16
E/S physique : 0
blocage : 1



C'est donc bien la commande "SELECT" qui bloque la commande "INSERT", mais pourquoi ?

On se rapproche, je le sens !
;-)

[SQLpro]

A cause de vos imbrications de requêtes.

A +

[WOLO Laurent]

Nous attendons toujours votre procédure VB pour vous proposez quelques optimisations de base.
je reste en attente.