Discussion :

[Papy214]

Bonjour,

J'ai repris une base depuis DBase vers MySQL 8.0.
Dans cette base, il y avait des index composé parfois avec des fonctions.
Par exemple, un index pouvait être défini en faisant la concaténation des 3 premiers caractères des valeurs d'une colonne avec les 5 derniers.
(Inutile de me dire que ça ne rime à rien, je le sais déjà et ça me pose déjà assez de problèmes comme ça dans cette migration logicielle )
MySQL permet de définir des index sur le même principe. Exemple:

Code sql :

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

1
2
create index CALINT
	on pvs ((left(`CODEINT`,3)), (right(`CODEINT`,5)));

Problème: une table avec ce genre d'index fait planter l'ouverture d'un TFDTable lié à la table en question.

---------------------------
Erreur
---------------------------
[FireDAC][DatS]-2. L'objet [] est introuvable.
---------------------------
OK
---------------------------

Si je supprime l'index de la table, plus aucun problème.

Si l'un de vous a déjà eu ce genre de problème et a trouvé une solution, je suis curieux de la connaître.
Je trouve quand même un peu dommage d'avoir des facilités comme celles-ci et que Firedac ne sache pas gérer ça.


Je viens de tester en modifiant la propriété FetchOptions en mettant fiMeta à False



Et là ça ne pose plus de problème.

Enfin, à part le nouveau qui est : Quelle sera la conséquence de cette modification ?

[SergioMaster]

Bonjour,

Je viens de tester en modifiant la propriété FetchOptions en mettant fiMeta à False
....
Enfin, à part le nouveau qui est : Quelle sera la conséquence de cette modification ?

Je ne suis pas un MySQL fan donc je ne pourrais pas trop faire quoique ce soit pour la partie le concernant, par contre la partie fiMeta est dans ma liste des TODOs (et certainement TOBLOG, a minima) des prochaines semaines. En effet, dans la doc, j'ai pu voir que l'on pouvait changer le comportement de récupérations de données et, entre autres, gérer plus facilement la pagination . C'est surtout ce truc qui m'intéresse mais, au cours de ces premières approches j'ai pu aussi voir que les fiBlobs avaient une certaine importance.
Même dans "l'évangile Firedac" de Cary Jensen il n'y a qu'un petit entrefilet au sujet de FecthOptions.Cache AMHA décoché l'option ne devrait pas poser de soucis mais ...


D'un autre côté, je n'utilise plus que rarement les Tables, préférant, malgré la contrainte d'ajout d'un UpdateObject, les Query

[Papy214]

Après quelques tests, j'ai compris l'utilité de fiMeta.
Cela sert à récupérer les informations qui permettent de mettre à jour les données.
Par exemple, grâce à ce flag, Firedac connait la clé primaire permettant d'identifier une ligne unique dans une table.
Sans ce flag, au moment d'une modification de ligne, Firedac répond qu'il ne peut pas identifier la ligne à mettre à jour.
Donc, en mettant à False ce flag, impossible de modifier les données.
Pour compenser, il faut utiliser la propriété ProviderFlags du composant TFDTable pour indiquer quels sont les champs qui permettent cette identification.
Comme cette base de données était extrêmement mal foutue, les tables n'ont aucune clé primaire.
Le premier développeur utilisait les fichiers DBase comme de simples fichiers textes utilisables sans effort avec des composants TTable du BDE.
En définissant quelques colonnes comme référence de ligne, et en modifiant une ligne, j'ai vu que ça en modifiait plusieurs qui reprenaient les mêmes valeurs dans les colonnes que j'avais indiquées comme clé.
Jeu très dangereux si on ne sait pas comment identifier une ligne unique.
Il faut savoir que TFDtable est à la base un TFDCustomQuery exactement comme TFDQuery.
Pour mettre à jour une ligne modifiée, il ne fait qu'un update de la table sur les lignes ciblées par les infos de "clé" pour retrouver la/les ligne(s) à prendre en compte.
Ce qui fait que, quand tu dis préférer les query, ça ne change en fait pas grand-chose pour toi

Conclusion, il va falloir que je vois avec le client comment cibler chaque ligne de façon unique quand c'est possible, ou ajouter une clé primaire dans le cas contraire.
Et vu le nombre de composants touchés par ce problème, ça va ajouter un bon nombre d'heures de travail.

[SergioMaster]

Merci pour ces infos

Conclusion, il va falloir que je vois avec le client comment cibler chaque ligne de façon unique quand c'est possible, ou ajouter une clé primaire dans le cas contraire.
Et vu le nombre de composants touchés par ce problème, ça va ajouter un bon nombre d'heures de travail.

Rien ne t'empêche (et AMHA tu devrais certainement le faire) de créer une colonne auto-incrément qui serait la clé primaire
L'autre solution : utiliser les couples FDQuery/FDUpdateSQL à la place d'un FDTable

[Papy214]

Créer des colonnes autoinc bien sûr que c'est la solution.
Le hic c'est qu'il y a des centaines de composants TFDTable (anciennement TTable) dans l'application.
Et je pense qu'ajouter une colonne dans MySQL ne suffira pas.
Il faudra très certainement ajouter ce champ à tous les les composants dans l'application. C'est ça qui me fait peur.
Sinon, ajouter des clés autoinc à toutes les tables, je fais ça avec une procédure stockée bien ficelée et basta
Il faut que je teste l'ajout d'une clé sans modification d'un composant lié pour voir ce que ça donne.
Si ça fonctionne, j'ai gagné beaucoup de temps.
Dans le cas contraire, ça va être la galère ............
Mais comme je dis souvent: "faire et défaire c'est toujours travailler"

[SergioMaster]

Et je pense qu'ajouter une colonne dans MySQL ne suffira pas.

si les champs sont déclarés dans le dfm c'est même certain

Sinon, ajouter des clés autoinc à toutes les tables, je fais ça avec une procédure stockée bien ficelée et basta

D'un autre côté, modifier les DFM pour déclarer ce champ supplémentaire avec un programme cela me semble jouable surtout si le nom de cette colonne auto incrémentée est toujours le même

Mais comme je dis souvent: "faire et défaire c'est toujours travailler"

on en a souvent la preuve sur nos routes de provinces ou même dans les villes et ce surtout pendant les vacances !

[Papy214]

on en a souvent la preuve sur nos routes de provinces ou même dans les villes et ce surtout pendant les vacances !