Y a-t-il un moyen plus rapide de itérer via un jeu de données ADO que
while (not ADOQuery1.Eof) do
begin
/* Do something */
ADOQuery1.Next;
end;
6 Réponses :
@Pieter, deux options
1) Vous pouvez modifier votre phrase SQL avant d'exécuter, en ajoutant la condition de l'emplacement suivant avec l'ensemble prédéfini de numéros de branche.
2) en utilisant le Filtre Propriété de TadoQuery.
Il a raison. Le moyen le plus rapide d'accomplir est d'utiliser une clause WHERE dans le SQL afin qu'il ne renvoie que les enregistrements dont vous avez besoin. SQL est spécifiquement optimisé pour le faire et il est susceptible de faire un meilleur travail que tout ce que vous pouvez faire du client.
Cette réponse suppose que l'une peut filtrer les données au niveau de DB. J'ai rencontré de nombreuses situations dans lesquelles le filtrage implique des appels à une méthode d'application et ne peut tout simplement pas être fait avec une clause où.
Il est beaucoup plus rapide d'utiliser Adorecordset pour de telles tâches:
while not ADOQuery1.Recordset.EOF do
begin
ADOQuery1.Recordset.MoveNext;
// get value
SomeVar := ADOQuery1.Recordset.Fields['FieldName'].Value;
end;
Est-ce vrai? Je pensais que le .nget .nef et .fields appelle de toute façon à l'objet d'enregistrement.
Vous avez raison, mais le contrôle du jeu d'enregistrement directement est beaucoup plus rapide, car le jeu de données fait beaucoup d'autres choses qui ralentissent l'itération.
Cela fournira un peu de stimulation de vitesse, mais probablement pas autant que de ne pas avoir à itérer autant de dossiers en premier lieu.
Eh bien, 9000 - pas autant d'enregistrements, mais je peux parier que le jeu d'enregistrements surperformerait un jeu de données au moins 4 fois.
Cela dépend également des désablecontrols comme indiqué par NEFTALI. Les jeux de données ADO sont très lents si ce n'est pas appelé. Il n'est nécessaire que si vous avez des contrôles liés à des données.
Les désablecontrols et l'utilisation d'enregistrements d'enregistrement ont définitivement augmenté la vitesse dans laquelle nous traitons maintenant les enregistrements! Merci pour tous les conseils. Cordialement, Pieter.
Assurez-vous que vous utilisez des commandes de désactivation / activer des contrôles s'il n'est pas nécessaire pour ne pas passer du temps à mettre à jour des contrôles visibles associés au jeu de données.
try
ADOQuery1.DisableControls;
while (not ADOQuery1.Eof) do
begin
/* Do something */
ADOQuery1.Next;
end;
finally
ADOQuery1.EnableControls;
end;
Merci pour le lien, Gerry.
Des gains de performance supplémentaires peuvent être effectués en évitant les comparaisons de cordes jusqu'à la fin du plus tard possible (lorsque tout le reste correspond à). Si vous avez un grand nombre de chaînes en double dans votre base de données, envisagez de placer vos chaînes dans une table séparée, reliée à la première table par un entier.
Vous voudrez peut-être changer la requête pour inclure une clause SQL où, quelque chose comme suggère également très seulement des curseurs en lecture seule à donner la plus grande vitesse augmentation.
Delphi Ado Stuff ( TADOQUERY ou TADOTABLE ) n'est pas mauvais, c'est affreux (enregistré avec Delphi Xe2 / 2007). Exportation des données de Tableaux Transbase (pilote ODBC) sur MySQL via des fichiers SQL et Navicatat. Pour la table avec près de millions d'enregistrements, il faut de nombreuses heures à travers ADO (8 millions de tableaux d'enregistrements s'élevaient à 10% après 2 jours), plusieurs minutes en utilisant Tquery (mais peut s'écraser en raison de bugs BDE avec de grandes tables avec de grandes tables , BDE n'a pas été mis à jour les 15 dernières années), plusieurs minutes à travers pure ODBC ou Navicat.
Mon avantage: Utilisez quelque chose à la place ADO (au moins jusqu'à ce que sérieusement retravaillait les développeurs).