Bonjour à tous,
je me questionne quant à l'utilité de gérer dynamiquement les sources de mes
formulaires soit comme je le fais actuellement, en générant une instruction
sql, que je déclare comme source de mon formulaire, ou en déclarant des
objets Recordset et en gérant le tout par vba... ce qui semble assez proche,
non ?
Un Objet Recordset créé par vba est-il plus rapide qu'une requête Access par
exemple ? Le jeu de données transférés est-il moins important (meilleures
performances réseaux par exemple) dans le cas de l'ouverture d'un Recordset,
que par une requête (après tout, si les critères sont les mêmes) ...
Je me questionne plus globalement sur intérêt de se taper du code, et de la
gestion d'erreur, avec les Objet Recordset .., Une âme charitable peut-elle
m'éclairer ?
Merci d'avance et bon code à tous
François Dej
--
François Dej
[exe] Soft Solutions
Enlevez "-antispam"
Bonjour à tous,
je me questionne quant à l'utilité de gérer dynamiquement les sources de mes
formulaires soit comme je le fais actuellement, en générant une instruction
sql, que je déclare comme source de mon formulaire, ou en déclarant des
objets Recordset et en gérant le tout par vba... ce qui semble assez proche,
non ?
Un Objet Recordset créé par vba est-il plus rapide qu'une requête Access par
exemple ? Le jeu de données transférés est-il moins important (meilleures
performances réseaux par exemple) dans le cas de l'ouverture d'un Recordset,
que par une requête (après tout, si les critères sont les mêmes) ...
Je me questionne plus globalement sur intérêt de se taper du code, et de la
gestion d'erreur, avec les Objet Recordset .., Une âme charitable peut-elle
m'éclairer ?
Merci d'avance et bon code à tous
François Dej
--
François Dej
[exe] Soft Solutions
info.exe-antispam@skynet.be
Enlevez "-antispam"
Bonjour à tous,
je me questionne quant à l'utilité de gérer dynamiquement les sources de mes
formulaires soit comme je le fais actuellement, en générant une instruction
sql, que je déclare comme source de mon formulaire, ou en déclarant des
objets Recordset et en gérant le tout par vba... ce qui semble assez proche,
non ?
Un Objet Recordset créé par vba est-il plus rapide qu'une requête Access par
exemple ? Le jeu de données transférés est-il moins important (meilleures
performances réseaux par exemple) dans le cas de l'ouverture d'un Recordset,
que par une requête (après tout, si les critères sont les mêmes) ...
Je me questionne plus globalement sur intérêt de se taper du code, et de la
gestion d'erreur, avec les Objet Recordset .., Une âme charitable peut-elle
m'éclairer ?
Merci d'avance et bon code à tous
François Dej
--
François Dej
[exe] Soft Solutions
Enlevez "-antispam"
Salut,
Tous les recordsets ne sont pas égaux, loin de là. Par exemple, un
"snapshot" est une photo
instantannée de ce qui est, au moment de la prise de photo. Cela n'est pas
magique, derrière les
rideaux, une COPIE des VALEURS est amenée sur ton PC. Une fois la copie
terminée, c'est plus rapide
car tu interroges (probablement) en local, plutôt qu'au travers du réseau,
mais la création du
recordset ne fut pas négligeable. À l'opposé, un firehose (tuyeau
d'incendie) est un recordset
ForwardOnly (pas de possibiiltés de retour en arrière, MovePrevious),
ReadOnly ( lecture seule )...
qui n'est guère rien de plus qu'un pointeur! (C'est plus qu'un pointeur,
mais pas beaucoup plus).
Ce n'est même pas un recordset, à proprement parler, mais à chaque
MoveNext, il y a échange avec le
"serveur". Entre les deux, il y a le KeySet ( ou Dynaset, selon DAO),
c'est un recordset qui,
lorsqu'il est construit, emmagazine les "clés" (disons plutôt les
"bookmarks", car ce ne sont pas
nécessairement les clés primaires) des enregistrements (plutôt que toutes
les valeurs, comme le
ferait le snapshot) à considérer, au moment de l'ouverture du recordset.
Si le propriétaire ajoute
des enregistrements, ceux-ci sont ajoutés au keyset, mais les ajouts
apportées par les autres
utilisateurs ne le sont pas, pas plus que n'est "recalculé" le critère,
le filtre. Exemple, si
j'ouvre un keyset sur
SELECT * FROM matable WHERE prix <
le keyset prend un "snapshot" des 'bookmarks' des enregistrements qui, à
ce moment de la création
du recordset, ont leur prix <= 10. Si, par la suite, le prix change, tant
pis, l'ensemble des
'bookmarks' à considérer n'est pas, lui, remis à jour.
En plus de tout celà, il faut concevoir qu'un recordset doit
possiblement savoir naviguer
(avant, arrière) et verrouiller (optimiste, pessimiste) les
enregistrements, qu'il y ait, ou non,
plusieurs utilisateurs.
Un recordset est donc un "overhead" plus ou moins important par
rapport à l'énoncé SQL qui l'a
créé, mais il possède des "atouts" que ne possède pas nécessairement un
énoncé SQL. En plus de la
localisation, de la possibilité même d'être déconnecté de la base de
données (ADO), il "sérialise"
les enregistrements. En effet, sous SQL, les enregistrements sont mobiles
les uns par rapport aux
autres, comme des bulles dans l'eau, mais dans un recordset, ces bulles
sont "chaînées",
possibilité de naviation oblige, entre elles. Mais ce n'est pas
nécessairement trivial.
SELECT f1, f2, f3 FROM maTable ORDER BY f1
sur un firehose. J'ouvre, et je lis
A, 1, Napoléon
Je passe au prochain, disons
B, 2, Octavius
et, à ce moment, disons qu'un autre utilisateur change l'enregistrement
(A, 1, Napoléon) en ( Z,
1, Napoléon), mais moi, je suis en (B, 2, Octavius), sur un firehose
(aucun ensemble de "clé"
associée à mon recordset). Si je fais des MoveNext, encore et encore, et
puisque j'ai un firehose,
à chaque fois, je ré-interroge la db et lui dit, en gros, je veux ce qui
suit (B,2) dans "SELECT
f1, f2 FROM maTable ORDER BY f1". Que ce passera-t-il? Bingo, bien sûr,
dans ce sénario un peu
loufoque, je pourrais retomber une SECONDE FOIS sur Nap., maintenant en
(Z, 1, Napoléon), même si
j'utilise un recordset!
Donc, en gros, en autant que faire ce peut, éviter de passer par
l'overhead d'un recordset
(création et destruction non "gratuite") si un énoncé SQL fait l'affaire
(comme pour ajouter un
nouvel enregistrement, par exemple), mais les recordsets ont leur utilité,
la principale étant
qu'ils permettent de travailler avec une base de données, sans connaître
vraiement grand chose de
SQL.
Espérant être utile,
Vanderghast, Access MVP
"François Dej" wrote in message
news:Bonjour à tous,
je me questionne quant à l'utilité de gérer dynamiquement les sources de
mes
formulaires soit comme je le fais actuellement, en générant une
instruction
sql, que je déclare comme source de mon formulaire, ou en déclarant des
objets Recordset et en gérant le tout par vba... ce qui semble assez
proche,
non ?
Un Objet Recordset créé par vba est-il plus rapide qu'une requête Access
par
exemple ? Le jeu de données transférés est-il moins important
(meilleures
performances réseaux par exemple) dans le cas de l'ouverture d'un
Recordset,
que par une requête (après tout, si les critères sont les mêmes) ...
Je me questionne plus globalement sur intérêt de se taper du code, et de
la
gestion d'erreur, avec les Objet Recordset .., Une âme charitable
peut-elle
m'éclairer ?
Merci d'avance et bon code à tous
François Dej
--
François Dej
[exe] Soft Solutions
Enlevez "-antispam"
Salut,
Tous les recordsets ne sont pas égaux, loin de là. Par exemple, un
"snapshot" est une photo
instantannée de ce qui est, au moment de la prise de photo. Cela n'est pas
magique, derrière les
rideaux, une COPIE des VALEURS est amenée sur ton PC. Une fois la copie
terminée, c'est plus rapide
car tu interroges (probablement) en local, plutôt qu'au travers du réseau,
mais la création du
recordset ne fut pas négligeable. À l'opposé, un firehose (tuyeau
d'incendie) est un recordset
ForwardOnly (pas de possibiiltés de retour en arrière, MovePrevious),
ReadOnly ( lecture seule )...
qui n'est guère rien de plus qu'un pointeur! (C'est plus qu'un pointeur,
mais pas beaucoup plus).
Ce n'est même pas un recordset, à proprement parler, mais à chaque
MoveNext, il y a échange avec le
"serveur". Entre les deux, il y a le KeySet ( ou Dynaset, selon DAO),
c'est un recordset qui,
lorsqu'il est construit, emmagazine les "clés" (disons plutôt les
"bookmarks", car ce ne sont pas
nécessairement les clés primaires) des enregistrements (plutôt que toutes
les valeurs, comme le
ferait le snapshot) à considérer, au moment de l'ouverture du recordset.
Si le propriétaire ajoute
des enregistrements, ceux-ci sont ajoutés au keyset, mais les ajouts
apportées par les autres
utilisateurs ne le sont pas, pas plus que n'est "recalculé" le critère,
le filtre. Exemple, si
j'ouvre un keyset sur
SELECT * FROM matable WHERE prix <
le keyset prend un "snapshot" des 'bookmarks' des enregistrements qui, à
ce moment de la création
du recordset, ont leur prix <= 10. Si, par la suite, le prix change, tant
pis, l'ensemble des
'bookmarks' à considérer n'est pas, lui, remis à jour.
En plus de tout celà, il faut concevoir qu'un recordset doit
possiblement savoir naviguer
(avant, arrière) et verrouiller (optimiste, pessimiste) les
enregistrements, qu'il y ait, ou non,
plusieurs utilisateurs.
Un recordset est donc un "overhead" plus ou moins important par
rapport à l'énoncé SQL qui l'a
créé, mais il possède des "atouts" que ne possède pas nécessairement un
énoncé SQL. En plus de la
localisation, de la possibilité même d'être déconnecté de la base de
données (ADO), il "sérialise"
les enregistrements. En effet, sous SQL, les enregistrements sont mobiles
les uns par rapport aux
autres, comme des bulles dans l'eau, mais dans un recordset, ces bulles
sont "chaînées",
possibilité de naviation oblige, entre elles. Mais ce n'est pas
nécessairement trivial.
SELECT f1, f2, f3 FROM maTable ORDER BY f1
sur un firehose. J'ouvre, et je lis
A, 1, Napoléon
Je passe au prochain, disons
B, 2, Octavius
et, à ce moment, disons qu'un autre utilisateur change l'enregistrement
(A, 1, Napoléon) en ( Z,
1, Napoléon), mais moi, je suis en (B, 2, Octavius), sur un firehose
(aucun ensemble de "clé"
associée à mon recordset). Si je fais des MoveNext, encore et encore, et
puisque j'ai un firehose,
à chaque fois, je ré-interroge la db et lui dit, en gros, je veux ce qui
suit (B,2) dans "SELECT
f1, f2 FROM maTable ORDER BY f1". Que ce passera-t-il? Bingo, bien sûr,
dans ce sénario un peu
loufoque, je pourrais retomber une SECONDE FOIS sur Nap., maintenant en
(Z, 1, Napoléon), même si
j'utilise un recordset!
Donc, en gros, en autant que faire ce peut, éviter de passer par
l'overhead d'un recordset
(création et destruction non "gratuite") si un énoncé SQL fait l'affaire
(comme pour ajouter un
nouvel enregistrement, par exemple), mais les recordsets ont leur utilité,
la principale étant
qu'ils permettent de travailler avec une base de données, sans connaître
vraiement grand chose de
SQL.
Espérant être utile,
Vanderghast, Access MVP
"François Dej" <info.exe-antispam@skynet.be> wrote in message
news:eVTEdAgRDHA.3132@tk2msftngp13.phx.gbl...
Bonjour à tous,
je me questionne quant à l'utilité de gérer dynamiquement les sources de
mes
formulaires soit comme je le fais actuellement, en générant une
instruction
sql, que je déclare comme source de mon formulaire, ou en déclarant des
objets Recordset et en gérant le tout par vba... ce qui semble assez
proche,
non ?
Un Objet Recordset créé par vba est-il plus rapide qu'une requête Access
par
exemple ? Le jeu de données transférés est-il moins important
(meilleures
performances réseaux par exemple) dans le cas de l'ouverture d'un
Recordset,
que par une requête (après tout, si les critères sont les mêmes) ...
Je me questionne plus globalement sur intérêt de se taper du code, et de
la
gestion d'erreur, avec les Objet Recordset .., Une âme charitable
peut-elle
m'éclairer ?
Merci d'avance et bon code à tous
François Dej
--
François Dej
[exe] Soft Solutions
info.exe-antispam@skynet.be
Enlevez "-antispam"
Salut,
Tous les recordsets ne sont pas égaux, loin de là. Par exemple, un
"snapshot" est une photo
instantannée de ce qui est, au moment de la prise de photo. Cela n'est pas
magique, derrière les
rideaux, une COPIE des VALEURS est amenée sur ton PC. Une fois la copie
terminée, c'est plus rapide
car tu interroges (probablement) en local, plutôt qu'au travers du réseau,
mais la création du
recordset ne fut pas négligeable. À l'opposé, un firehose (tuyeau
d'incendie) est un recordset
ForwardOnly (pas de possibiiltés de retour en arrière, MovePrevious),
ReadOnly ( lecture seule )...
qui n'est guère rien de plus qu'un pointeur! (C'est plus qu'un pointeur,
mais pas beaucoup plus).
Ce n'est même pas un recordset, à proprement parler, mais à chaque
MoveNext, il y a échange avec le
"serveur". Entre les deux, il y a le KeySet ( ou Dynaset, selon DAO),
c'est un recordset qui,
lorsqu'il est construit, emmagazine les "clés" (disons plutôt les
"bookmarks", car ce ne sont pas
nécessairement les clés primaires) des enregistrements (plutôt que toutes
les valeurs, comme le
ferait le snapshot) à considérer, au moment de l'ouverture du recordset.
Si le propriétaire ajoute
des enregistrements, ceux-ci sont ajoutés au keyset, mais les ajouts
apportées par les autres
utilisateurs ne le sont pas, pas plus que n'est "recalculé" le critère,
le filtre. Exemple, si
j'ouvre un keyset sur
SELECT * FROM matable WHERE prix <
le keyset prend un "snapshot" des 'bookmarks' des enregistrements qui, à
ce moment de la création
du recordset, ont leur prix <= 10. Si, par la suite, le prix change, tant
pis, l'ensemble des
'bookmarks' à considérer n'est pas, lui, remis à jour.
En plus de tout celà, il faut concevoir qu'un recordset doit
possiblement savoir naviguer
(avant, arrière) et verrouiller (optimiste, pessimiste) les
enregistrements, qu'il y ait, ou non,
plusieurs utilisateurs.
Un recordset est donc un "overhead" plus ou moins important par
rapport à l'énoncé SQL qui l'a
créé, mais il possède des "atouts" que ne possède pas nécessairement un
énoncé SQL. En plus de la
localisation, de la possibilité même d'être déconnecté de la base de
données (ADO), il "sérialise"
les enregistrements. En effet, sous SQL, les enregistrements sont mobiles
les uns par rapport aux
autres, comme des bulles dans l'eau, mais dans un recordset, ces bulles
sont "chaînées",
possibilité de naviation oblige, entre elles. Mais ce n'est pas
nécessairement trivial.
SELECT f1, f2, f3 FROM maTable ORDER BY f1
sur un firehose. J'ouvre, et je lis
A, 1, Napoléon
Je passe au prochain, disons
B, 2, Octavius
et, à ce moment, disons qu'un autre utilisateur change l'enregistrement
(A, 1, Napoléon) en ( Z,
1, Napoléon), mais moi, je suis en (B, 2, Octavius), sur un firehose
(aucun ensemble de "clé"
associée à mon recordset). Si je fais des MoveNext, encore et encore, et
puisque j'ai un firehose,
à chaque fois, je ré-interroge la db et lui dit, en gros, je veux ce qui
suit (B,2) dans "SELECT
f1, f2 FROM maTable ORDER BY f1". Que ce passera-t-il? Bingo, bien sûr,
dans ce sénario un peu
loufoque, je pourrais retomber une SECONDE FOIS sur Nap., maintenant en
(Z, 1, Napoléon), même si
j'utilise un recordset!
Donc, en gros, en autant que faire ce peut, éviter de passer par
l'overhead d'un recordset
(création et destruction non "gratuite") si un énoncé SQL fait l'affaire
(comme pour ajouter un
nouvel enregistrement, par exemple), mais les recordsets ont leur utilité,
la principale étant
qu'ils permettent de travailler avec une base de données, sans connaître
vraiement grand chose de
SQL.
Espérant être utile,
Vanderghast, Access MVP
"François Dej" wrote in message
news:Bonjour à tous,
je me questionne quant à l'utilité de gérer dynamiquement les sources de
mes
formulaires soit comme je le fais actuellement, en générant une
instruction
sql, que je déclare comme source de mon formulaire, ou en déclarant des
objets Recordset et en gérant le tout par vba... ce qui semble assez
proche,
non ?
Un Objet Recordset créé par vba est-il plus rapide qu'une requête Access
par
exemple ? Le jeu de données transférés est-il moins important
(meilleures
performances réseaux par exemple) dans le cas de l'ouverture d'un
Recordset,
que par une requête (après tout, si les critères sont les mêmes) ...
Je me questionne plus globalement sur intérêt de se taper du code, et de
la
gestion d'erreur, avec les Objet Recordset .., Une âme charitable
peut-elle
m'éclairer ?
Merci d'avance et bon code à tous
François Dej
--
François Dej
[exe] Soft Solutions
Enlevez "-antispam"