Discussion :

[jlm22]

Bonjour,

Je souhaite faire un programme qui parcours une table d'une base de donnée et en particulier un champs, ce champs est par défault à 0 et tant qu'il n'est pas passé à 1 je souhaite attendre et bam dès qu'il passe à 1 je continue le programme. Mon problème est de savoir comment "guetter" l'arrivée du 1 dans ce champs. Avez vous une idée ?

[Kropernic]

Que penses-tu de :

Code :

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

1
2
3
4
5
laValeurDuChamp = RequêteQuiRécupèreLaValeur()
 
While not laValeurDuChamp = 1
   laValeurDuChamp = RequêteQuiRécupèreLaValeur()
End While

?

[jlm22]

sa me parait interressant ^^ mais très, cependant comment faire pour passer à la ligne suivante. Par exemple on tattend que le champs de la première ligne passe à 1 ...............hop il passe du coup on va à la 2ème ligne puis on attend que le champs de la 2ème ligne passe à 1 ........................hop il passe et ainsi de suite. Il faudrait une sorte d'indice !

[Kropernic]

Ah ok, tu checkes ce champs sur plusieurs lignes. J'avais pas compris ça.

Bien en fait, ce n'est pas vraiment plus compliqué.

Tu fais une requête du genre

Code :

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

select distinct leChamp from maTable

Après, y a plus qu'à compter le nombre de lignes récupérées. Si c'est >1, tu boucles. Si c'est =1, tu vérifies que la valeur n'est pas 0.

[Bluedeep]

Visiblement, il y a un problème de conception : une base de données sert à stocker des ... données; pas à communiquer des infos de changement d'état entre programme (ce que je soupçonne que tu essaye de faire).

Exprime la totalité du besoin fonctionnel, on verra peut être plus clair.

EDIT : après avoir lu les messages postés supra (ce que je n'avais pas fait) je réitére mon analyse : gros problème de conception.
Visiblement, tu veux utiliser la DB pour quelque chose qui n'est pas du tout son rôle.

[jlm22]

Bon je vous explique tout,

Côté SQL
En faite j'ai fait une procédure PL/SQL qui parcours une table (Table X) chaque fois qu'elle arrive sur une ligne elle fait un traitement puis elle passe un champs de la ligne à 1.

Côté Vb.NET
En parallèle de ma procédure j'ai un programme vb qui lance la procédure (il n'est pas conçu que pour sa c'est seulement une option) et regarde le champs qui est censé passer à 1, quand il passe à 1 il incrémente une variable et ainsi de suite jusqu'à la fin du parcours de la table.

Je pense avoir été à peu près clair, j'ai beaucoup simplifier l'application mais l'idée principale est là.

Merci pour votre aide.

Ps: je ne joins pas le code sa serais superflux et sa vous embrouillerai plus qu'autre chose

Edit : s'il y a un problème de conception comment faire autrement je souhaite juste savoir ou en est mon traitement

[Bluedeep]

Tu confirmes donc ce que je disais. (mauvaise conception).

On va supposer que tes traitements sont assez longs et que tu as réellement besoin du monitoring coté client de la progression du traitement dans la base (mais ce serait pas mal de préciser pourquoi ?).

Je ne connais pas assez Oracle pour savoir ce qu'il y a de dispo dessus, mais je sais comment je ferais en SQL Server pour ce cas. Dans la proc stoc, je posterai à chaque élement traité un message dans une SSSBQ, et du coté client, j'écouterai la SSSBQ. Maintenant, voir les mécanismes Oracle équivalent.

[Kropernic]

Pour ma culture... Qu'est-ce qu'une SSSBQ (ou SSBQ ?). Quand je fais une recherche dans google, je ne tombe que sur d'autres de tes messages où tu utilises cet acronyme mais jamais sur une explication ^^

[jlm22]

Sa me parait bien compliqué pour seulement voire un état d'avancement du traitement

[Kropernic]

Ta procédure en pl/sql, elle parcours les records selon un ordre précis ?

Si oui, tu peux aussi faire qqch du genre

Code :

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

1
2
 
Select * from maTable where leChamp = 0 order by ...

Ta première ligne sera celle qui est en cours de traitement par ta procédure si ce que tu mets dans la clause order by trie tes records de la même manière que ta procédure.

[Bluedeep]

Pour ma culture... Qu'est-ce qu'une SSSBQ (ou SSBQ ?). Quand je fais une recherche dans google, je ne tombe que sur d'autres de tes messages où tu utilises cet acronyme mais jamais sur une explication ^^

Sql Server Service Broker Queue.

[Bluedeep]

Sa me parait bien compliqué pour seulement voire un état d'avancement du traitement

On peut à l'inverse s'interroger sur la pertinence de voir l'avancement d'un traitement effectué dans le DBMS.

[jlm22]

J'ai pensé à sa parce que je savais pas comment faire autrement, tout le monde n'a pas la chance d'être un expert, je fait avec ce que j'ai et jusque la sa a toujours fonctionner. C'est de la bidouille je te l'accorde mais sa sert a rien de m'enfoncer
Merci griftou je vais regarder sa

[Bluedeep]

J'ai pensé à sa parce que je savais pas comment faire autrement, tout le monde n'a pas la chance d'être un expert, je fait avec ce que j'ai et jusque la sa a toujours fonctionner. C'est de la bidouille je te l'accorde mais sa sert a rien de m'enfoncer
Merci griftou je vais regarder sa

Je ne te parles pas de ton choix technique mais de la necessité de monitorer la progression d'un traitement ayant lieu sur la DB. Cela ne me semble pas répondre à une necessité fonctionnelle. La technique n'a rien à voir la dedans.

[jlm22]

Quand je lance la procédure via Vb j'aimerais savoir où sa en est via une progressbar, je me vois pas attendre devant l'appli et me dire " C'est bientot fini ?!" . D'où pour moi la "nécessité" de récupérer l'avancement de la procédure. Je ne pense pas être le premier dans ce cas là (enfin ptete que si qui sait ).

Merci de ton interêt pour mon soucis.

[Bluedeep]

Quand je lance la procédure via Vb j'aimerais savoir où sa en est via une progressbar, je me vois pas attendre devant l'appli et me dire " C'est bientot fini ?!" . D'où pour moi la "nécessité" de récupérer l'avancement de la procédure. Je ne pense pas être le premier dans ce cas là (enfin ptete que si qui sait ).

A vrai dire, où le traitement est vraiment long (plus de 1mn, disons) et dans ce cas, a priori, tu n'as pas besoin de synchronisme, ou il est court et synchrone, et un simple message d'attente suffit.

Sinon, plutot que balayer la table, tu écrit une table temporaire avec juste une ligne et un champ integer que tu incrémente dans ta proc stoc, et à interval régulier tu interroges cette tables. Mieux, deux champs, le premier avec le nombre total de lignes à traiter que ta PS renseigne au début, et le champ incrémenté. Ainsi le programme client connait le % d'avancement quel que soit le moment d'interrogation de la table.

Ceci dit, je pense que tu vas avoir dans tous les cas des problèmes d'isolation transactionnelle.

[jlm22]

J'avais pensé à un autre truc (je garde ce que tu m'as dit sous le coude ) en faite on garde le principe du champs dans la table parcouru, chaque fois qu'une ligne est traité hop le champs passe à 1, en parallèle une fonction VB compte le nombre de ligne de la table et fait la différence avec le count de ligne qui ont le champs à 1 et ainsi tu alliment petit à petit la progress bar.
c'est possible ?

[jlm22]

Je crois que je vais opter pour ta seconde idée qui me parait être la plus simple à mettre en oeuvre, je l'implemente et je te dit si c'est fonctionnel

[Bluedeep]

J'avais pensé à un autre truc (je garde ce que tu m'as dit sous le coude ) en faite on garde le principe du champs dans la table parcouru, chaque fois qu'une ligne est traité hop le champs passe à 1, en parallèle une fonction VB compte le nombre de ligne de la table et fait la différence avec le count de ligne qui ont le champs à 1 et ainsi tu alliment petit à petit la progress bar.
c'est possible ?

Je maintiens que tu vas avoir des problèmes d'isolation transactionnelle.

[jlm22]

isolation transactionelle ?