Discussion :

[PaulR]

Bête question a priori : mais que faut-il de spécial pour que des instructions aussi élémentaires que FindKey fonctionnent avec MySQL ?

J'utilise les composants MyDAC, de Core Lab, version 4.40... Y a-t-il d'autres ici qui ont des problèmes ? Les FindKey ne retournent pas vrai/faux selon que l'article existe ou pas, ce qui est quand même un peu embêtant, non ?

Bref, si quelqu'un pouvait me jurer que ça marche, je me sentirais encouragé à continuer à chercher :-)))

Paul

[ProgD]

ce que je sais, est que les fonction FindKey et FindNearest propre au objet BDE Ttable et TQuery pour les autres Objet com ADO, InterBase IB, ainsi que MyDac, je vous conseil d'utilisé la fonction LOCATE.

Bonne continuation.

[PaulR]

Merci, je vais chercher par là.
Le locate est "techniquement" équivalent ? Il fait une recherche via index ? C'est sans doute un bête réflexe de terminologie, mais quand je pense plutôt à une recherche par balayage, sans utilisation de l'index, tandis que le FindKey, par définition, on sait qu'il fait une recherche sur clé... Mais je suppose que je me gourre.
Merci du conseil !
Paul

[Caesarus]

j'utilise pas ces composants, mais
de souvenir à ce qu'on m'en avait dit c'est plus optimisé par le findkey d'ou son existance, qui fait une recherche par index, alors que pour le locate il ne crée pas automatiquement d'index. maintenant je me souviens avoir eu des probleme avec des findkey et j'avais du passer par locate (pouquoi exactement je me souviens plus j'ai la memoire passoire)

[ShaiLeTroll]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SELECT id_article FROM article WHERE code_article = "Pull Bleu"

Une requête, c'est pas le mieux qu'une ouverture de Table (TMyTable) ce qui peut être lent car cela fait un "SELECT * FROM article" (sans limit, voir Fetch) et ensuite un Locate ...

N'extraire que la donnée utile réduit le flux réseau, l'occupation processeur du serveur, la mémoire tampon en local ...

Je travaille depuis 15 mois avec MyDAC CoreLab, et c'est 99% de SQL ... on n'a des TMyTable que pour les tables courtes chargées au début de l'application comme les Paramètres Utilisateurs et Systèmes ...

[PaulR]

Ah, chouette, quelqu'un qui connaît le produit...

Je ne m'y retrouve pas dans la jungle SQL et mon impression est quand même que les performances varient fortement d'un moteur à l'autre, et donc que les stratégies à mettre en oeuvre peuvent différer.

Je travaille beaucoup sur AS400, et là je peux te dire que si tu veux lire une centaine d'articles de même clé dans un fichier volumineux (disons 1 million d'articles), t'as vachement intérêt à oublier SQL...
Du coup, j'ai sans doute de mauvais réflexes face à d'autres moteurs...
Ainsi, si je te comprends bien, il est plus performant avec MySQL de faire un "select ... where" plutôt qu'une recherche je dirais "traditionnelle" ?

Ma difficulté est que notre équipe essaie d'écrire du code qui, sur simple changement d'une directive de compilation, pourrait travailler sur un AS400 ou sur une base SQL (MySQL pour le moment)...

Pour ça, on a créé des classes qui héritent (selon la directive) soit d'un TDataBase soit d'un TMyConnection, et d'un TTable / TMyTable... D'où nécessité d'avoir des instructions communes. Bref, il semble qu'il faudrait donc surcharger le FindKey du TMyTable pour le changer par un LocateEx ou mieux, si je te comprends bien, par un "select...where" ?

Merci pour ton temps,

Paul