l'objet recordset.

Bonjour

Recordset est un objet de Base de Données issu des bibliothèques DAO ou ADO.
C'est un objet sous-jacent qui va retourner et remplir les colonnes d'un
contrôle récepteur dépendant.

Exemple :

Data1.Recordset("NOM") ... va retourner la donnée sélectionnée du champ NOM

L'ordre de restitution des données sera défini par la propriété RecordSource
du contrôle Data1

Les propriétés et méthodes de l'objet Recordset permettent de gérer le
contenu de la BdD

Data1.Recordset.MoveLast ... va placer le Focus sur la dernière donnée.
--
Bonne réception.
andre.araste@wanadoo.fr
http://perso.wanadoo.fr/andre.araste/
Membre du Club Win's: http://www.clubwins.org
Avertissement: Je ne vends rien.

"PHIL" <PHIL@discussions.microsoft.com> a écrit dans le message de news:
015DC7A6-01CD-4247-83E5-DF213E2A801E@microsoft.com...

Bonjour,

la definition de l'objet recordset,me parait assez flou.

si j'ai bien compris cette objet defini permet d'aller chercher sur une
base
de données,la valeur d'un champ d'une table?
mais comment????

avez vous plus de précisions à m'apporter la dessus.

merci

Bonjour,

la definition de l'objet recordset,me parait assez flou.

Non, non, ce n'est pas flou du tout :-)))

Tout d'abord, merci de préciser de quel objet recordset vous parlez.
Recordset ADO ou Recordset DAO?

Dans les 2 cas, un Recordset, comme son nom l'indique, représente un jeu
d'enregistrements résultant d'une requête envoyée sur un SGBD. Par
exemple, la requête SQL "Select * From Authors Where au_lname like D%"
envoyée sur la base de données exemple Pubs (de SQL Server) retourne
dans un Recordset tous les enregistrements de la table Authors pour
lesquels le champ au_lname commence par D.

Une fois le recordset récupéré, vous pouvez naviguer à l'intérieur (cela
dépend du type de curseur) , lire les champs de chaque enregistrement,
modifier les valeurs des champs, etc.

Le code nécessaire dépend bien sûr de la technologie utilisée (ADO, DAO,
RDO,...), ce que vous n'avez pas précisé. Par exemple pour ADO (il y a
différentes manières de procéder avec des connexions explicites ou
implicites):

Dim cnn As New ADODB.Connection
Dim rst As New ADODB.Recordset
Dim fld As ADODB.Field

' Ouvre la connexion
cnn.Open "Provider=Microsoft.Jet.OLEDB.4.0;" _
& "Data Source=.NorthWind.mdb;"

' Ouvre un recordset en avance seule,
' lecture seule
rst.Open _
"SELECT * FROM Customers WHERE Region = 'WA'", _
cnn, adOpenForwardOnly, adLockReadOnly

' Affiche les valeurs du champ de l'enregistrement
' courant (ici, le premier)
For Each fld In rst.Fields
Debug.Print fld.Value & ";";
Next
Debug.Print
rst.MoveNext
Loop

' Ferme le recordset
rst.Close

La documentation correspondante explique bien sûr tout cela en détails.
Je vous suggère donc de faire une première lecture de cette
documentation et de nous revenir si vous avez des problèmes avec tel ou
tel mécanisme particulier.

--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr

Salut à vous!

Dim cnn As New ADODB.Connection

Bien que je suis convaincu que Patrick sait ce qu'il fait, ce n'est
peut-être pas le cas de Phil...


Phil : "Dim As New" est à éviter en VB 6.
http://groups.google.com/groups?threadm=OVm4JcG1CHA.452%40TK2MSFTNGP11.phx.gbl

--
Cordialement
Yanick
MVP pour Visual Basic

Zoury wrote:

Phil : "Dim As New" est à éviter en VB 6.
http://groups.google.com/groups?threadm=OVm4JcG1CHA.452%40TK2MSFTNGP11.phx.gbl

Je ne suis pas tout à fait d'accord :-) .

En fait la seule chose qui est garantie dans tous les cas, c'est que
Initialize sera appelé avant que l'on ne puisse accéder à une méthode ou
une propriété. On ne sait pas quand et dans mes cours, j'insiste
toujours sur le fait que quelle que soit la méthode d'instanciation, le
seul fait avéré c'est qu'Initialize sera appelé avant tout appel de
méthode ou de propriété.

Même avec une syntaxe de type

Dim O As MonObj
Set O = New MonObj

je n'ai pas plus de garantie sur le moment de l'instanciation réelle.
Tout dépend du type d'objet et en particulier s'il se trouve ou non sous
le contrôle de COM+. Si je n'utilise pas l'objet immédiatement après le
Set O = New MonObj, je ne suis pas sûr que Initialize a été appelé. Il
me semble même avoir un TP où l'on voit bien le phénomène.

C'est pour cela que je ne me préoccupe pas de la différence entre les 2
syntaxes: je fais toujours comme si Initialize n'était appelé qu'au
dernier moment.

--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr

Zoury wrote:

Phil : "Dim As New" est à éviter en VB 6.
http://groups.google.com/groups?threadm=OVm4JcG1CHA.452%40TK2MSFTNGP11.phx.gbl

En l'occurence, j'ai repris quasiment à l'identique un exemple de la doc
Microsoft :-)))

--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr

> En fait la seule chose qui est garantie dans tous les cas, c'est que
Initialize sera appelé avant que l'on ne puisse accéder à une méthode ou
une propriété.

tu as un exemple de ça ?
ici dans le cas d'un "Dim As" suivi de "Set New" Initialize n'est appelé que
lorsque que "Set New" est appelé (et sans délai).. et c'est ce comportement
que j'ai pu observer sur tout les postes où j'ai pu testé ce concept..


Voici un test nous montrant ce qui se passe :
'***
' Class1
Option Explicit

Public n As Integer

Private Sub Class_Initialize()
n = 1
Debug.Print "initialize"
End Sub

Private Sub Class_Terminate()
Debug.Print "terminate"
End Sub

Public Function f() As Long
f = 2
End Function
'***
' Module1
Option Explicit

Private Sub Main()

Debug.Print String$(50, "-")
Debug.Print "Déclaration de c1 (Dim As New)"
Dim c1 As New Class1

Debug.Print String$(50, "-")
Debug.Print "Déclaration de c2"
Dim c2 As Class1

On Error Resume Next

Debug.Print String$(50, "-")
Debug.Print "utilisation de c1"
Debug.Print c1.n
Debug.Print c1.f

Debug.Print String$(50, "-")
Debug.Print "instanciation explicite de c2"
Set c2 = New Class1

Debug.Print String$(50, "-")
Debug.Print "utilisation de c2"
Debug.Print c2.n
Debug.Print c2.f

Debug.Print String$(50, "-")
Debug.Print "destruction explicite de c1"
Set c1 = Nothing

Debug.Print String$(50, "-")
Debug.Print "destruction explicite de c2"
Set c2 = Nothing

Debug.Print String$(50, "-")
Debug.Print "utilisation de c1"
Debug.Print c1.n
Debug.Print c1.f

Debug.Print String$(50, "-")
Debug.Print "utilisation de c2 (plante ici...)"
Debug.Print c2.n
Debug.Print c2.f

Debug.Print String$(50, "-")
Debug.Print "fin du Main (la destruction implicite de c1 et c2 se fait
ici car les variables tombent hors de portée, c2 étant déjà à Nothing seul
c1.Terminate() est appelée)"

End Sub
'***

Trace :
--------------------------------------------------
Déclaration de c1 (Dim As New)
--------------------------------------------------
Déclaration de c2
--------------------------------------------------
utilisation de c1
initialize
1
2
--------------------------------------------------
instanciation explicite de c2
initialize
--------------------------------------------------
utilisation de c2
1
2
--------------------------------------------------
destruction explicite de c1
terminate
--------------------------------------------------
destruction explicite de c2
terminate
--------------------------------------------------
utilisation de c1
initialize
1
2
--------------------------------------------------
utilisation de c2 (plante ici...)
--------------------------------------------------
fin du Main (la destruction implicite de c1 et c2 se fait ici car les
variables tombent hors de portée, c2 étant déjà à Nothing seul
c1.Terminate() est appelée)
terminate


Initialize n'est pas appelée lors de l'utlisation mais bien lors du Set...
ai-je mal compris ton explication ?

--
Cordialement
Yanick
MVP pour Visual Basic

On ne sait pas quand et dans mes cours, j'insiste
toujours sur le fait que quelle que soit la méthode d'instanciation, le
seul fait avéré c'est qu'Initialize sera appelé avant tout appel de
méthode ou de propriété.

Même avec une syntaxe de type

Dim O As MonObj
Set O = New MonObj

je n'ai pas plus de garantie sur le moment de l'instanciation réelle.
Tout dépend du type d'objet et en particulier s'il se trouve ou non sous
le contrôle de COM+. Si je n'utilise pas l'objet immédiatement après le
Set O = New MonObj, je ne suis pas sûr que Initialize a été appelé. Il
me semble même avoir un TP où l'on voit bien le phénomène.

C'est pour cela que je ne me préoccupe pas de la différence entre les 2
syntaxes: je fais toujours comme si Initialize n'était appelé qu'au
dernier moment.

--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr

Zoury wrote:

En fait la seule chose qui est garantie dans tous les cas, c'est que
Initialize sera appelé avant que l'on ne puisse accéder à une
méthode ou une propriété.

tu as un exemple de ça ?

Je crois que oui mais il faut que je retrouve ça dans mes archives...

--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr

Patrick Philippot wrote:

Zoury wrote:

En fait la seule chose qui est garantie dans tous les cas, c'est que
Initialize sera appelé avant que l'on ne puisse accéder à une
méthode ou une propriété.

tu as un exemple de ça ?

Je crois que oui mais il faut que je retrouve ça dans mes archives...

Je viens de refaire un test et en ce qui concerne l'instanciation d'une
classe non COM définie directement dans le même projet, c'est toi qui
est dans le vrai: c'est le Set O = ... qui provoque l'appel à
Initialize. Dans le cas d'une classe COM aussi.

Dans le cas d'un As New, c'est la première utilisation, dans les 2 cas,
qui provoque l'initialisation.

Par contre, si la classe instanciée est une classe COM sous COM+ (pas
testé, il faudrait que je remonte une appli COM+ pour ça), je pense que
je n'ai pas la garantie que Initialize sera exécuté au moment du Set
parce que tout simplement, en fonction des réglages de l'objet, il peut
ne pas être instancié du tout (momentanément) côté serveur : ma variable
objet peut pointer sur un objet de contexte en état désactivé.

Il y a au moins un cas de figure où cette situation est sûre à 100%,
c'est si l'objet a été réglé pour être invoqué en asynchrone via MSMQ
(queued component). Dans ce cas, le client pourra faire des appels de
méthode alors que l'objet n'a même pas encore été instancié.

Cette situation est particulièrement significative parce que le fait que
l'objet soit invoqué en synchrone ou en asynchrone ne dépend pas
uniquement du code client mais aussi d'un réglage administratif au
niveau de COM+. C'est pour cela que dans l'incertitude, je m'en tiens en
général à la règle de base : je ne sais pas quand Initialize sera
appelé. Un objet géré de manière standard aujourd'hui peut passer sous
COM+ demain et le mécanisme d'instanciation peut devenir complètement
différent. Il faut donc toujours appliquer la règle "du pire qui est
toujours possible" et faire comme si... AMHA.

--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr

ah d'accord!

Il faut donc toujours appliquer la règle "du pire qui est
toujours possible" et faire comme si... AMHA.

donc en résumé avec COM sans COM+ l'utilisation du Dim et du Set
successivement offre un avantage sur le Dim As New dans le sens où c'est
nous qui controllons la "vie" de l'objet, ce qui évite des problèmes du
genre : "Quand je ferme mon programme, il reste dans la liste des
processus.". Alors qu'avec COM sous COM+ l'utilisation du Dim et du Set
successivement agissent tout comme le As New, il faut donc être prudent avec
l'utilisation de nos objets.

amha, il est quand même mieux de les utiliser successivement... pour le peu
de temps de plus que ça prend. ;O)

--
Cordialement
Yanick
MVP pour Visual Basic

Zoury wrote:

c'est nous qui controllons la "vie" de l'objet, ce qui évite des
problèmes du genre : "Quand je ferme mon programme, il reste dans la
liste des processus.".

Le type de problème que tu cites est surtout lié à la manière dont le
comptage de référence est géré (bien ou mal) par l'objet.

Dans les 2 cas, on devrait avoir le même comportement de ce point de
vue. Que l'objet soit instancié à la première utilisation ou par un
appel explicite à Set MonObj = New... , le comptage de référence se fait
de la même manière. On fera de toutes façons -1 dans le compteur dès que
la variable MonObj sortira du scope ou que l'on fera un Set MonObj =
Nothing.

Mais je pense que ta conclusion est la bonne de toutes façons :-)) car
je viens de me souvenir d'un comportement aberrant de VB6. Regarde la
séquence de code suivante:

Dim Compte As New clsCompte

Compte.Nom = "Pat" '
Print "Compte.Nom = " & Compte.Nom
Print "Compte.ObtenirSolde = " & Compte.ObtenirSolde
Set Compte = Nothing
Print "Compte.Nom = " & Compte.Nom <<<<<<<
Print "Compte.ObtenirSolde = " & Compte.ObtenirSolde

A l'avant-dernière ligne, je réutilise une variable objet que je viens
explicitement de mettre à Nothing. A ton avis il se passe quoi? Contre
toute attente, il n'y a aucune erreur et VB6 réinstancie automatiquement
un nouveau clsCompte (on *repasse* dans Initialize). Je trouve ça
totalement aberrant 1) d'un point de vue sémantique et 2) d'un point de
vue sécurité : il n'y a pas d'erreur et on se retrouve donc avec une
variable objet dont l'état n'est pas celui que l'on croit. Le Set Compte
= Nothing peut avoir été oublié et se trouver des dizaines de lignes en
amont de la ligne "Print "Compte.Nom = " & Compte.Nom". Intéressant à
déboguer. Le programme ne plante pas mais on a des données aberrantes
dans l'objet.

Par contre, si on fait un

Dim Compte As clsCompte
Set Compte = New clsCompte

on a bien l'erreur attendue sur l'avant-dernière ligne.

--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr