Nous souhaitons migrer une application d'access vers sqlserver. Mais nous
souhaitons que la nouvelle application soit compatible avec sqlserver et
aussi avec access
Nous venons de constater que la méthode seek n'était pas supportée par
sqlserver. La seule solution est de transformer les seek en 'select ..
Where .'.
Lorsque l'on utilise la méthode seek avec access, on spécifie les index. Par
conséquent, on les déclare dans access. Si on transforme les seek en
'select . where . ', est-il nécessaire de déclarer les index que l'on met
dans la clause where pour faire des gains en performance ?
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
Patrice
Le principe général en SQL est que les index sont utilisés si présents. Les créer est donc généralement suffisant.
"Pierre-Yves" a écrit dans le message de news:
Bonjour,
Nous souhaitons migrer une application d'access vers sqlserver. Mais nous souhaitons que la nouvelle application soit compatible avec sqlserver et aussi avec access
Nous venons de constater que la méthode seek n'était pas supportée par sqlserver. La seule solution est de transformer les seek en 'select .. Where .'.
Lorsque l'on utilise la méthode seek avec access, on spécifie les index.
Par
conséquent, on les déclare dans access. Si on transforme les seek en 'select . where . ', est-il nécessaire de déclarer les index que l'on met dans la clause where pour faire des gains en performance ?
Merci d'avance
Le principe général en SQL est que les index sont utilisés si présents. Les
créer est donc généralement suffisant.
"Pierre-Yves" <py_leteste@hotmail.com> a écrit dans le message de
news:e8UeHWwGEHA.2612@TK2MSFTNGP09.phx.gbl...
Bonjour,
Nous souhaitons migrer une application d'access vers sqlserver. Mais nous
souhaitons que la nouvelle application soit compatible avec sqlserver et
aussi avec access
Nous venons de constater que la méthode seek n'était pas supportée par
sqlserver. La seule solution est de transformer les seek en 'select ..
Where .'.
Lorsque l'on utilise la méthode seek avec access, on spécifie les index.
Par
conséquent, on les déclare dans access. Si on transforme les seek en
'select . where . ', est-il nécessaire de déclarer les index que l'on met
dans la clause where pour faire des gains en performance ?
Le principe général en SQL est que les index sont utilisés si présents. Les créer est donc généralement suffisant.
"Pierre-Yves" a écrit dans le message de news:
Bonjour,
Nous souhaitons migrer une application d'access vers sqlserver. Mais nous souhaitons que la nouvelle application soit compatible avec sqlserver et aussi avec access
Nous venons de constater que la méthode seek n'était pas supportée par sqlserver. La seule solution est de transformer les seek en 'select .. Where .'.
Lorsque l'on utilise la méthode seek avec access, on spécifie les index.
Par
conséquent, on les déclare dans access. Si on transforme les seek en 'select . where . ', est-il nécessaire de déclarer les index que l'on met dans la clause where pour faire des gains en performance ?
Merci d'avance
Michel Walsh
Salut,
... hormis pour MS SQL Server 2000 avec des index sur valeurs bit. Il semble qu'il faut l'inciter avec un hint pour qu'il utilise un tel index.
Espérant être utile, Vanderghast, Access MVP
... et pour éviter que quelqu'un tombe dans le panneau classique : "pas malin, le mèque, d'indexer un champ de bit", je rétorque, pour repérer le seul enregistrement Ben Laden qui a le bit à 1, parmis tous les autres zillions d'enregistrements qui on leur bit à 0, un index peut être utile.
voilà, tout ça pour prendre la défence de l'index sur bit, ... ce mal aimé ... :-)
"Patrice" wrote in message news:
Le principe général en SQL est que les index sont utilisés si présents.
Les
créer est donc généralement suffisant.
"Pierre-Yves" a écrit dans le message de news: > Bonjour, > > > > Nous souhaitons migrer une application d'access vers sqlserver. Mais
nous
> souhaitons que la nouvelle application soit compatible avec sqlserver et > aussi avec access > > > > Nous venons de constater que la méthode seek n'était pas supportée par > sqlserver. La seule solution est de transformer les seek en 'select .. > Where .'. > > > > Lorsque l'on utilise la méthode seek avec access, on spécifie les index. Par > conséquent, on les déclare dans access. Si on transforme les seek en > 'select . where . ', est-il nécessaire de déclarer les index que l'on
met
> dans la clause where pour faire des gains en performance ? > > > > Merci d'avance > >
Salut,
... hormis pour MS SQL Server 2000 avec des index sur valeurs bit.
Il semble qu'il faut l'inciter avec un hint pour qu'il utilise un tel index.
Espérant être utile,
Vanderghast, Access MVP
... et pour éviter que quelqu'un tombe dans le panneau classique :
"pas malin, le mèque, d'indexer un champ de bit", je rétorque, pour repérer
le seul enregistrement Ben Laden qui a le bit à 1, parmis tous les autres
zillions d'enregistrements qui on leur bit à 0, un index peut être utile.
voilà, tout ça pour prendre la défence de l'index sur bit, ... ce
mal aimé ... :-)
"Patrice" <nobody@nowhere.com> wrote in message
news:OAaq6kwGEHA.3188@TK2MSFTNGP10.phx.gbl...
Le principe général en SQL est que les index sont utilisés si présents.
Les
créer est donc généralement suffisant.
"Pierre-Yves" <py_leteste@hotmail.com> a écrit dans le message de
news:e8UeHWwGEHA.2612@TK2MSFTNGP09.phx.gbl...
> Bonjour,
>
>
>
> Nous souhaitons migrer une application d'access vers sqlserver. Mais
nous
> souhaitons que la nouvelle application soit compatible avec sqlserver et
> aussi avec access
>
>
>
> Nous venons de constater que la méthode seek n'était pas supportée par
> sqlserver. La seule solution est de transformer les seek en 'select ..
> Where .'.
>
>
>
> Lorsque l'on utilise la méthode seek avec access, on spécifie les index.
Par
> conséquent, on les déclare dans access. Si on transforme les seek en
> 'select . where . ', est-il nécessaire de déclarer les index que l'on
met
> dans la clause where pour faire des gains en performance ?
>
>
>
> Merci d'avance
>
>
... hormis pour MS SQL Server 2000 avec des index sur valeurs bit. Il semble qu'il faut l'inciter avec un hint pour qu'il utilise un tel index.
Espérant être utile, Vanderghast, Access MVP
... et pour éviter que quelqu'un tombe dans le panneau classique : "pas malin, le mèque, d'indexer un champ de bit", je rétorque, pour repérer le seul enregistrement Ben Laden qui a le bit à 1, parmis tous les autres zillions d'enregistrements qui on leur bit à 0, un index peut être utile.
voilà, tout ça pour prendre la défence de l'index sur bit, ... ce mal aimé ... :-)
"Patrice" wrote in message news:
Le principe général en SQL est que les index sont utilisés si présents.
Les
créer est donc généralement suffisant.
"Pierre-Yves" a écrit dans le message de news: > Bonjour, > > > > Nous souhaitons migrer une application d'access vers sqlserver. Mais
nous
> souhaitons que la nouvelle application soit compatible avec sqlserver et > aussi avec access > > > > Nous venons de constater que la méthode seek n'était pas supportée par > sqlserver. La seule solution est de transformer les seek en 'select .. > Where .'. > > > > Lorsque l'on utilise la méthode seek avec access, on spécifie les index. Par > conséquent, on les déclare dans access. Si on transforme les seek en > 'select . where . ', est-il nécessaire de déclarer les index que l'on
met
> dans la clause where pour faire des gains en performance ? > > > > Merci d'avance > >
lionelp
valeur bit, 0 ou 1, où est l'intérêt d'utiliser un index ?
Cordialement, LionelP
"Michel Walsh" wrote in message news:uBT$
Salut,
... hormis pour MS SQL Server 2000 avec des index sur valeurs bit. Il semble qu'il faut l'inciter avec un hint pour qu'il utilise un tel
index.
Espérant être utile, Vanderghast, Access MVP
... et pour éviter que quelqu'un tombe dans le panneau classique : "pas malin, le mèque, d'indexer un champ de bit", je rétorque, pour
repérer
le seul enregistrement Ben Laden qui a le bit à 1, parmis tous les autres zillions d'enregistrements qui on leur bit à 0, un index peut être utile.
voilà, tout ça pour prendre la défence de l'index sur bit, ... ce mal aimé ... :-)
"Patrice" wrote in message news: > Le principe général en SQL est que les index sont utilisés si présents. Les > créer est donc généralement suffisant. > > > "Pierre-Yves" a écrit dans le message de > news: > > Bonjour, > > > > > > > > Nous souhaitons migrer une application d'access vers sqlserver. Mais nous > > souhaitons que la nouvelle application soit compatible avec sqlserver
et
> > aussi avec access > > > > > > > > Nous venons de constater que la méthode seek n'était pas supportée par > > sqlserver. La seule solution est de transformer les seek en 'select .. > > Where .'. > > > > > > > > Lorsque l'on utilise la méthode seek avec access, on spécifie les
index.
> Par > > conséquent, on les déclare dans access. Si on transforme les seek en > > 'select . where . ', est-il nécessaire de déclarer les index que l'on met > > dans la clause where pour faire des gains en performance ? > > > > > > > > Merci d'avance > > > > > >
valeur bit, 0 ou 1, où est l'intérêt d'utiliser un index ?
Cordialement,
LionelP
"Michel Walsh" <vanderghast@VirusAreFunnierThanSpam> wrote in message
news:uBT$fU9GEHA.2392@tk2msftngp13.phx.gbl...
Salut,
... hormis pour MS SQL Server 2000 avec des index sur valeurs bit.
Il semble qu'il faut l'inciter avec un hint pour qu'il utilise un tel
index.
Espérant être utile,
Vanderghast, Access MVP
... et pour éviter que quelqu'un tombe dans le panneau classique :
"pas malin, le mèque, d'indexer un champ de bit", je rétorque, pour
repérer
le seul enregistrement Ben Laden qui a le bit à 1, parmis tous les autres
zillions d'enregistrements qui on leur bit à 0, un index peut être utile.
voilà, tout ça pour prendre la défence de l'index sur bit, ... ce
mal aimé ... :-)
"Patrice" <nobody@nowhere.com> wrote in message
news:OAaq6kwGEHA.3188@TK2MSFTNGP10.phx.gbl...
> Le principe général en SQL est que les index sont utilisés si présents.
Les
> créer est donc généralement suffisant.
>
>
> "Pierre-Yves" <py_leteste@hotmail.com> a écrit dans le message de
> news:e8UeHWwGEHA.2612@TK2MSFTNGP09.phx.gbl...
> > Bonjour,
> >
> >
> >
> > Nous souhaitons migrer une application d'access vers sqlserver. Mais
nous
> > souhaitons que la nouvelle application soit compatible avec sqlserver
et
> > aussi avec access
> >
> >
> >
> > Nous venons de constater que la méthode seek n'était pas supportée par
> > sqlserver. La seule solution est de transformer les seek en 'select ..
> > Where .'.
> >
> >
> >
> > Lorsque l'on utilise la méthode seek avec access, on spécifie les
index.
> Par
> > conséquent, on les déclare dans access. Si on transforme les seek en
> > 'select . where . ', est-il nécessaire de déclarer les index que l'on
met
> > dans la clause where pour faire des gains en performance ?
> >
> >
> >
> > Merci d'avance
> >
> >
>
>
valeur bit, 0 ou 1, où est l'intérêt d'utiliser un index ?
Cordialement, LionelP
"Michel Walsh" wrote in message news:uBT$
Salut,
... hormis pour MS SQL Server 2000 avec des index sur valeurs bit. Il semble qu'il faut l'inciter avec un hint pour qu'il utilise un tel
index.
Espérant être utile, Vanderghast, Access MVP
... et pour éviter que quelqu'un tombe dans le panneau classique : "pas malin, le mèque, d'indexer un champ de bit", je rétorque, pour
repérer
le seul enregistrement Ben Laden qui a le bit à 1, parmis tous les autres zillions d'enregistrements qui on leur bit à 0, un index peut être utile.
voilà, tout ça pour prendre la défence de l'index sur bit, ... ce mal aimé ... :-)
"Patrice" wrote in message news: > Le principe général en SQL est que les index sont utilisés si présents. Les > créer est donc généralement suffisant. > > > "Pierre-Yves" a écrit dans le message de > news: > > Bonjour, > > > > > > > > Nous souhaitons migrer une application d'access vers sqlserver. Mais nous > > souhaitons que la nouvelle application soit compatible avec sqlserver
et
> > aussi avec access > > > > > > > > Nous venons de constater que la méthode seek n'était pas supportée par > > sqlserver. La seule solution est de transformer les seek en 'select .. > > Where .'. > > > > > > > > Lorsque l'on utilise la méthode seek avec access, on spécifie les
index.
> Par > > conséquent, on les déclare dans access. Si on transforme les seek en > > 'select . where . ', est-il nécessaire de déclarer les index que l'on met > > dans la clause where pour faire des gains en performance ? > > > > > > > > Merci d'avance > > > > > >
Michel Walsh
Salut,
c'était en dessous de ma signature... si il faut chercher le SEUL enregistrement qui a son bit différent de tous les zillions autres, l'index le trouve tout de suite... autrement, il faut une métrique appréciable de I/O... car il faut scanner tous les enregistrements :-( Lire une seule page d'index contre toutes les pages de la table (cas où on ignore combien d'enregistrements ont bit=1) me semble un avantage certain.
Vanderghast, Access MVP
"lionelp" wrote in message news:uLqMWQ%
valeur bit, 0 ou 1, où est l'intérêt d'utiliser un index ?
Cordialement, LionelP
"Michel Walsh" wrote in message news:uBT$ > Salut, > > > ... hormis pour MS SQL Server 2000 avec des index sur valeurs
bit.
> Il semble qu'il faut l'inciter avec un hint pour qu'il utilise un tel index. > > > Espérant être utile, > Vanderghast, Access MVP > > > > ... et pour éviter que quelqu'un tombe dans le panneau classique
:
> "pas malin, le mèque, d'indexer un champ de bit", je rétorque, pour repérer > le seul enregistrement Ben Laden qui a le bit à 1, parmis tous les
autres
> zillions d'enregistrements qui on leur bit à 0, un index peut être
utile.
> > > voilà, tout ça pour prendre la défence de l'index sur bit, ...
ce
> mal aimé ... :-) > > > > > > "Patrice" wrote in message > news: > > Le principe général en SQL est que les index sont utilisés si
présents.
> Les > > créer est donc généralement suffisant. > > > > > > "Pierre-Yves" a écrit dans le message de > > news: > > > Bonjour, > > > > > > > > > > > > Nous souhaitons migrer une application d'access vers sqlserver. Mais > nous > > > souhaitons que la nouvelle application soit compatible avec
sqlserver
et > > > aussi avec access > > > > > > > > > > > > Nous venons de constater que la méthode seek n'était pas supportée
par
> > > sqlserver. La seule solution est de transformer les seek en 'select
..
> > > Where .'. > > > > > > > > > > > > Lorsque l'on utilise la méthode seek avec access, on spécifie les index. > > Par > > > conséquent, on les déclare dans access. Si on transforme les seek en > > > 'select . where . ', est-il nécessaire de déclarer les index que
l'on
> met > > > dans la clause where pour faire des gains en performance ? > > > > > > > > > > > > Merci d'avance > > > > > > > > > > > >
Salut,
c'était en dessous de ma signature... si il faut chercher le SEUL
enregistrement qui a son bit différent de tous les zillions autres, l'index
le trouve tout de suite... autrement, il faut une métrique appréciable de
I/O... car il faut scanner tous les enregistrements :-( Lire une seule
page d'index contre toutes les pages de la table (cas où on ignore combien
d'enregistrements ont bit=1) me semble un avantage certain.
Vanderghast, Access MVP
"lionelp" <lionelp@microsoft.re.mo.ve.com> wrote in message
news:uLqMWQ%23GEHA.128@tk2msftngp13.phx.gbl...
valeur bit, 0 ou 1, où est l'intérêt d'utiliser un index ?
Cordialement,
LionelP
"Michel Walsh" <vanderghast@VirusAreFunnierThanSpam> wrote in message
news:uBT$fU9GEHA.2392@tk2msftngp13.phx.gbl...
> Salut,
>
>
> ... hormis pour MS SQL Server 2000 avec des index sur valeurs
bit.
> Il semble qu'il faut l'inciter avec un hint pour qu'il utilise un tel
index.
>
>
> Espérant être utile,
> Vanderghast, Access MVP
>
>
>
> ... et pour éviter que quelqu'un tombe dans le panneau classique
:
> "pas malin, le mèque, d'indexer un champ de bit", je rétorque, pour
repérer
> le seul enregistrement Ben Laden qui a le bit à 1, parmis tous les
autres
> zillions d'enregistrements qui on leur bit à 0, un index peut être
utile.
>
>
> voilà, tout ça pour prendre la défence de l'index sur bit, ...
ce
> mal aimé ... :-)
>
>
>
>
>
> "Patrice" <nobody@nowhere.com> wrote in message
> news:OAaq6kwGEHA.3188@TK2MSFTNGP10.phx.gbl...
> > Le principe général en SQL est que les index sont utilisés si
présents.
> Les
> > créer est donc généralement suffisant.
> >
> >
> > "Pierre-Yves" <py_leteste@hotmail.com> a écrit dans le message de
> > news:e8UeHWwGEHA.2612@TK2MSFTNGP09.phx.gbl...
> > > Bonjour,
> > >
> > >
> > >
> > > Nous souhaitons migrer une application d'access vers sqlserver. Mais
> nous
> > > souhaitons que la nouvelle application soit compatible avec
sqlserver
et
> > > aussi avec access
> > >
> > >
> > >
> > > Nous venons de constater que la méthode seek n'était pas supportée
par
> > > sqlserver. La seule solution est de transformer les seek en 'select
..
> > > Where .'.
> > >
> > >
> > >
> > > Lorsque l'on utilise la méthode seek avec access, on spécifie les
index.
> > Par
> > > conséquent, on les déclare dans access. Si on transforme les seek en
> > > 'select . where . ', est-il nécessaire de déclarer les index que
l'on
> met
> > > dans la clause where pour faire des gains en performance ?
> > >
> > >
> > >
> > > Merci d'avance
> > >
> > >
> >
> >
>
>
c'était en dessous de ma signature... si il faut chercher le SEUL enregistrement qui a son bit différent de tous les zillions autres, l'index le trouve tout de suite... autrement, il faut une métrique appréciable de I/O... car il faut scanner tous les enregistrements :-( Lire une seule page d'index contre toutes les pages de la table (cas où on ignore combien d'enregistrements ont bit=1) me semble un avantage certain.
Vanderghast, Access MVP
"lionelp" wrote in message news:uLqMWQ%
valeur bit, 0 ou 1, où est l'intérêt d'utiliser un index ?
Cordialement, LionelP
"Michel Walsh" wrote in message news:uBT$ > Salut, > > > ... hormis pour MS SQL Server 2000 avec des index sur valeurs
bit.
> Il semble qu'il faut l'inciter avec un hint pour qu'il utilise un tel index. > > > Espérant être utile, > Vanderghast, Access MVP > > > > ... et pour éviter que quelqu'un tombe dans le panneau classique
:
> "pas malin, le mèque, d'indexer un champ de bit", je rétorque, pour repérer > le seul enregistrement Ben Laden qui a le bit à 1, parmis tous les
autres
> zillions d'enregistrements qui on leur bit à 0, un index peut être
utile.
> > > voilà, tout ça pour prendre la défence de l'index sur bit, ...
ce
> mal aimé ... :-) > > > > > > "Patrice" wrote in message > news: > > Le principe général en SQL est que les index sont utilisés si
présents.
> Les > > créer est donc généralement suffisant. > > > > > > "Pierre-Yves" a écrit dans le message de > > news: > > > Bonjour, > > > > > > > > > > > > Nous souhaitons migrer une application d'access vers sqlserver. Mais > nous > > > souhaitons que la nouvelle application soit compatible avec
sqlserver
et > > > aussi avec access > > > > > > > > > > > > Nous venons de constater que la méthode seek n'était pas supportée
par
> > > sqlserver. La seule solution est de transformer les seek en 'select
..
> > > Where .'. > > > > > > > > > > > > Lorsque l'on utilise la méthode seek avec access, on spécifie les index. > > Par > > > conséquent, on les déclare dans access. Si on transforme les seek en > > > 'select . where . ', est-il nécessaire de déclarer les index que
l'on
> met > > > dans la clause where pour faire des gains en performance ? > > > > > > > > > > > > Merci d'avance > > > > > > > > > > > >
