Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

méthode seek avec objets ADO et sql server

1 réponse
Avatar
Pierre-Yves
Bonjour,



nous avons une grosse application access à migrer en sql server. Nous allons
donc passer en objets ADO pour gérer cette base de données.



Dans tout le code, nous utilisons les méthodes seek pour faire des
recherches rapides sur index.



Nous avons testé cette méthode avec accès à la base sql server. Nous
constatons que les méthodes seek ne fonctionnent avec un provider OLEDB.1.
On a essayé en natif, meme probleme.



Nous avons lu sur cetains forums que d'autres avaient également eu ce
probleme.



La seule solution pour l'instant consisterait à convertir tous les seek en
select where. Mais cette opération nous prendra des mois.



Qui a déjà été confronté à ce probleme? Quelle solution peut-etre envisagé?



Merci d'avance

1 réponse

Avatar
Michel Walsh
Salut,



J'imagine qu'il faut plus que de convertir les Seek, car cela présuppose
qu'on utilise des recordsets... le résultat risque d'être plus lent avec MS
SQL Server qu'avec Jet, dans ce scénario. Faire le test: générer un million
d'enregistrements sous Jet, et faire la même chose, sous MS SQL Server, en
amenant TOUS ces enregistrements, localement. La dernière fois que j'ai
essayé, Jet a mis 20 secondes, MS SQL Server a mis trois minutes (et cela,
depuis tempdb, elle même réputée plus rapide qu'une db ordinaire). Si on
veut utiliser la force de MS SQL Server, il faut minimiser le nombre
d'enregistrements transférés, cela veut dire d'utiliser une clause WHERE
dans l'énoncé SQL qui crée le recordset, et non de créer le recordset puis
de limiter les enregistrements via un Seek. Dans le permier cas, le filtrage
a lieu avant le transfert, dans le second cas, le filtrage a lieu après le
transfert. En fait, il est bon de limiter au MAX les enregistrements
transférés... et puisqu'il vous faut réécrire le code, de toutes façons
(vous ne désirez pas livrer quelque chose qui sera huit fois plus lent,
non...), peut être en profiter pour le réécrire avec cette "amélioration" en
tête.


Et si vous êtes intéressé par faire le "test" par vous même, un peu
comme les pierres de Galilé, il s'agit de créer une table Ds, un champ, d,
dix enregistrements, avec valeurs de 0 à 9. Puis, amener TOUS les
enregistrements ( noter que Access+ MS SQL Server limite, par défaut, aux
10 000 seuls premiers enregistrement, enlever cette limite ) de la requête:


SELECT Ds.d + 10*a.d + 100*b.d + 1000*c.d + 10000*e.d + 100000*f.d
FROM Ds, Ds As a, Ds As b, Ds As c, Ds As e, Ds As f



qui produit, effectivement, un million d'enregistrements. "Chronométrer"
(rien de terriblement précis n'est requis, regarder la trotteuse de
l'horloge sur le mur suffit) Jet et MS SQL Server. Conclure. On pourrait
même, j'imagine, utiliser tempdb et, dans une autre expérience, pubs. Je
n'ai pas fait ce test-là, par contre, me fiant aveuglément sur les
affirmations de Delaney dans son "Inside MS SQL Server 2000", page 173,
avant dernier paragraphe, pour "imaginer" que sur pubs, cela sera plus lent.




Espérant être utile,
Vanderghast, Access MVP



"Pierre-Yves" wrote in message
news:u$
Bonjour,



nous avons une grosse application access à migrer en sql server. Nous


allons
donc passer en objets ADO pour gérer cette base de données.



Dans tout le code, nous utilisons les méthodes seek pour faire des
recherches rapides sur index.



Nous avons testé cette méthode avec accès à la base sql server. Nous
constatons que les méthodes seek ne fonctionnent avec un provider OLEDB.1.
On a essayé en natif, meme probleme.



Nous avons lu sur cetains forums que d'autres avaient également eu ce
probleme.



La seule solution pour l'instant consisterait à convertir tous les seek en
select where. Mais cette opération nous prendra des mois.



Qui a déjà été confronté à ce probleme? Quelle solution peut-etre


envisagé?



Merci d'avance