utilisation d'un CURSOR avec tous les champs de la table
1 réponse
Herve MAILLARD
Bonjour,
J'ai besoin d'utiliser un CURSOR pour lister un par un tous les
engistrements d'une table (je démarre avec T-SQL).
J'ai également besoin de travailler (calcul, insertion dans d'autres tables,
etc...) sur chaque champs séparément.
Dois-je déclarer chaque champ séparément (sachant que j'en ai 50) ?
Exemple :
Je sais comment faire pour quelques champs :
DECLARE CR_OFList cursor for
select Champ1,Champ2 from CR_OF
OPEN CR_OFList
FETCH NEXT FROM CR_OFList
INTO @Champ1, @Champ2,....
Mais cette méthode est très fastidieuse (déclarations des 50 variables...)
Comment faire si on fait un select * :
DECLARE CR_OFList cursor for
select * from CR_OF
OPEN CR_OFList
FETCH NEXT FROM CR_OFList
Comment faire maintenant pour "lire" les champs sans les déclarer dans le
INTO ?
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
Herve MAILLARD
Bonour, Thierry,
Je te conseille de bannir le "select *" de tes pratiques de développement.
De plus cette syntaxe ne sera plus soutenu dans les prochaines versions de SQL SERVER, à l'intérieur des sp, triggers et fonctions.
Merci pour tes conseils. J'ai finalement opté pour la déclaration et description de tous les champs... pfuittt... c clair que c'est contraignant... mais ça fonctionne bien, c'est l'essentiel.
Combien de lignes comporte ta table en lecture ?
Ma table ne comporte que quelques lignes (une dizaine maxi).
"Thierry Bertin" a écrit dans le message de news:
Salut,
Effectivement c'est très contraignant mais c'est la "meilleure" méthode.
Combien de lignes comporte ta table en lecture ?
As-tu envisagé une approche par table temporaire ?
Bonne journée
"Herve MAILLARD" wrote:
> Bonjour, > > J'ai besoin d'utiliser un CURSOR pour lister un par un tous les > engistrements d'une table (je démarre avec T-SQL). > J'ai également besoin de travailler (calcul, insertion dans d'autres
tables,
> etc...) sur chaque champs séparément. > > Dois-je déclarer chaque champ séparément (sachant que j'en ai 50) ? > > Exemple : > > Je sais comment faire pour quelques champs : > DECLARE CR_OFList cursor for > select Champ1,Champ2 from CR_OF > > OPEN CR_OFList > FETCH NEXT FROM CR_OFList > INTO @Champ1, @Champ2,.... > > Mais cette méthode est très fastidieuse (déclarations des 50
variables...)
> > Comment faire si on fait un select * : > DECLARE CR_OFList cursor for > select * from CR_OF > > OPEN CR_OFList > FETCH NEXT FROM CR_OFList > > Comment faire maintenant pour "lire" les champs sans les déclarer dans
le
> INTO ? > > Merci de votre aide, > > Hervé. > > >
Bonour, Thierry,
Je te conseille de bannir le "select *" de tes pratiques de développement.
De plus cette syntaxe ne sera plus soutenu dans les prochaines versions de
SQL SERVER, à l'intérieur des sp, triggers et fonctions.
Merci pour tes conseils.
J'ai finalement opté pour la déclaration et description de tous les
champs... pfuittt... c clair que c'est contraignant... mais ça fonctionne
bien, c'est l'essentiel.
Combien de lignes comporte ta table en lecture ?
Ma table ne comporte que quelques lignes (une dizaine maxi).
"Thierry Bertin" <ThierryBertin@discussions.microsoft.com> a écrit dans le
message de news:5890EC1E-8E9A-4923-AA18-3FB53899FCA9@microsoft.com...
Salut,
Effectivement c'est très contraignant mais c'est la "meilleure" méthode.
Combien de lignes comporte ta table en lecture ?
As-tu envisagé une approche par table temporaire ?
Bonne journée
"Herve MAILLARD" wrote:
> Bonjour,
>
> J'ai besoin d'utiliser un CURSOR pour lister un par un tous les
> engistrements d'une table (je démarre avec T-SQL).
> J'ai également besoin de travailler (calcul, insertion dans d'autres
tables,
> etc...) sur chaque champs séparément.
>
> Dois-je déclarer chaque champ séparément (sachant que j'en ai 50) ?
>
> Exemple :
>
> Je sais comment faire pour quelques champs :
> DECLARE CR_OFList cursor for
> select Champ1,Champ2 from CR_OF
>
> OPEN CR_OFList
> FETCH NEXT FROM CR_OFList
> INTO @Champ1, @Champ2,....
>
> Mais cette méthode est très fastidieuse (déclarations des 50
variables...)
>
> Comment faire si on fait un select * :
> DECLARE CR_OFList cursor for
> select * from CR_OF
>
> OPEN CR_OFList
> FETCH NEXT FROM CR_OFList
>
> Comment faire maintenant pour "lire" les champs sans les déclarer dans
le
> INTO ?
>
> Merci de votre aide,
>
> Hervé.
>
>
>
Je te conseille de bannir le "select *" de tes pratiques de développement.
De plus cette syntaxe ne sera plus soutenu dans les prochaines versions de SQL SERVER, à l'intérieur des sp, triggers et fonctions.
Merci pour tes conseils. J'ai finalement opté pour la déclaration et description de tous les champs... pfuittt... c clair que c'est contraignant... mais ça fonctionne bien, c'est l'essentiel.
Combien de lignes comporte ta table en lecture ?
Ma table ne comporte que quelques lignes (une dizaine maxi).
"Thierry Bertin" a écrit dans le message de news:
Salut,
Effectivement c'est très contraignant mais c'est la "meilleure" méthode.
Combien de lignes comporte ta table en lecture ?
As-tu envisagé une approche par table temporaire ?
Bonne journée
"Herve MAILLARD" wrote:
> Bonjour, > > J'ai besoin d'utiliser un CURSOR pour lister un par un tous les > engistrements d'une table (je démarre avec T-SQL). > J'ai également besoin de travailler (calcul, insertion dans d'autres
tables,
> etc...) sur chaque champs séparément. > > Dois-je déclarer chaque champ séparément (sachant que j'en ai 50) ? > > Exemple : > > Je sais comment faire pour quelques champs : > DECLARE CR_OFList cursor for > select Champ1,Champ2 from CR_OF > > OPEN CR_OFList > FETCH NEXT FROM CR_OFList > INTO @Champ1, @Champ2,.... > > Mais cette méthode est très fastidieuse (déclarations des 50
variables...)
> > Comment faire si on fait un select * : > DECLARE CR_OFList cursor for > select * from CR_OF > > OPEN CR_OFList > FETCH NEXT FROM CR_OFList > > Comment faire maintenant pour "lire" les champs sans les déclarer dans
le
> INTO ? > > Merci de votre aide, > > Hervé. > > >
