Vieux SetRange et Mysql

Bonjour

Toujours dans cette migration d'une très ancienne application BDE + DBase vers Firedac + MySQL, je me retrouve face à un problème inattendu que je vais tenter de décrire simplement.

Le code de l'application (très mal faite mais impossible à reprendre entièrement) utilise très intensivement des index et des SetRange pour filtrer des tables sur des plages de valeurs.
Je sais, c'est dégueu mais encore une fois ce n'est pas moi le responsable :(
Je ne vous dirai pas combien il y a d'occurrences de SetRange dans l'application pour éviter un malaise mais ça devra rester ainsi au moins pour quelques années.

Mon problème est le suivant.

Dans la version DBase, un index est toujours soit un nom unique de colonne, soit une concaténation de plusieurs colonnes pour donner au final une sorte de colonne unique "virtuelle".
(Dans le cas d'un index avec une seule colonne, aucun souci)

Pour passer les données sous MySQL, j'ai transformé ces index (sous forme expression) pour les utiliser sous la forme de plusieurs champs.
Par exemple:
Sous DBase, Index Truc = col1+col2
Sous MySQL, Index Truc = (col1, col2)

Dans le code, on écrit par exemple:
Code:

1 2 3 4 5 6 7 8 9 10 tbl.Indexname := 'Truc'; tbl.SetRangeStart: tbl.fieldbyname('col1').AsString := 'ddd'; tbl.fieldbyname('col2').AsString := 'ddd'; tbl.SetRangeEnd: tbl.fieldbyname('col1').AsString := 'ggg'; tbl.fieldbyname('col2').AsString := 'zzz'; Tbl.Applyrange
Problème: Dans la version MySQL le ApplyRange ne donne pas le même résultat
Sous DBase on dirait qu'il fait un AND sur les 2 colonnes de l'index alors que sur MySQL il semble ne tenir compte que de le première colonne de l'index.

DBase va donc flltrer sur col1 en prenant la plage de valeurs entre ddd et ggg puis filtrer à nouveau le résultat sur la seconde colonne.

La version MySQL, filtre sur la plage de valeurs définie pour col1 mais semble oublier la seconde colonne dans son filtre.

Par contre, l'ordre asc est bien respecté sur la première colonne et éventuellement sur la seconde en cas de multiples retournés sur col1.

Je dois absolument obtenir un comportement identique dans les 2 versions sinon, c'est la cata pour moi :-(

La question est donc de savoir ce qui peut clocher dans tout ça.

Est-ce un problème Firedac ?
Firedac aurait-il une option cachée pour forcer l'utilisation des index d'une façon ou d'une autre ?
Est-ce plutôt côté MySQL qu'il faut chercher ?

Toute idée est bonne à prendre ..........

Bon, il se trouve que finalement le comportement est celui attendu. Il y a des jours ou Delphi pourrait me rendre chèvre :arf: