Discussion :

[Papy214]

Bonjour

Je tourne en carré depuis un moment et je cherche une piste pour mon problème.

Je crée une base MySQL à partir d'une base SQLite.
La première table est chargée depuis SQLite avec un TFDTable et pour chaque ligne, j'ai une requête d'insert dans la table MySQL (créée par un script en début de procédure, donc vierge de données).
Dans mon code, je débute une transaction, puis je transfère ligne à ligne.

Après avoir créé et rempli ma table, je commit ma transaction puis je fais un select count(*) pour voir combien j'ai récupéré de lignes.
Et là, résultat = 0.

Je vais dans workbench, je fais la même requête et j'ai bien un peu plus de 1000 lignes.

Sur ce constat, je me dis qu'après avoir commité ma transaction, je vais fermer et réouvrir ma connexion pour forcer mon composant à trouver les données.
Mais là, c'est pareil.

Code :

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

1
2
3
4
5
 
    FDCnxmysql.Close;
    FDCnxmysql.Open;
    R := FDCnxmysql.ExecSQLScalar(Format('select count(*) from `%s`', [TblSrc.TableName]));
    Memo1.Lines.Add(Format('Table %s = %d', [TblSrc.TableName, R]));

R vaut 0 . Alors que la table est bien remplie.


Est-ce que je peux faire quelque chose de plus pour trouve mes lignes ?

Recréer un composant TFDConnection différent ?

[pprem]

C'est effectivement étrange. As-tu récupéré le texte des requêtes générées pour les lancer à la main à côté ?

Juste une question au passage, pourquoi passes-tu par Format() plutôt que d'utiliser la notation de paramètres en SQL de FireDAC ?

[Papy214]

Le texte de la requête est copié-collé mais même sans ça, le select count(*) est assez simple pour ne pas poser de problème.

Pour le format, c'est parce que je ne suis pas sûr qu'utilise un paramètre pour un nom de table soit possible mais c'est peut-être une erreur ?
J'avoue n'avoir pas essayé

[Papy214]

[pprem]

as-tu tenté sans les quotes autour du nom de table ?

[Papy214]

Non ! Comme la syntaxe pour MySQL, je n'ai pas pensé à essayer sans.
Je teste demain au bureau

[SergioMaster]

Bonjour,

Je prends le train en marche un peu tard, et j'ai toujours eu du mal avec ExecSQLScalar
un paramètre nom de table je n'ai jamais essayé pour ce genre de chose j'ai toujours essayé une macro &table mais dans le contexte d'un ExecSQL jamais
Je vais ouvrir la bible de Cary Jensen histoire d'en avoir le cœur net.

Dans l'aide j'ai vu cette syntaxe :

FDConnection1.ExecSQLScalar('select name from {id Employees} where id = :id', [100]);

qui permettrait au moins de s'affranchir des ' ', très mauvaise traduction dans le wiki mais l'exemple est "parlant"

{id <nom d'identificateur>} Se développe en syntaxe de l'identificateur délimité propre au SGBD. Par exemple : {id Order Details} -> “Order Details” sur Oracle.

N.B. rien dans la bible

Dans mon code, je débute une transaction, puis je transfère ligne à ligne.

as-tu pensé au TFDBatchMove ? Ou encore à l'utilisation d'ArrayDML, bien sûr il faudrait passer par une FDQuery mais du coup que de possibilités (macro sûre, propriété rowsaffected ...)

[Papy214]

avec ou sans ` c'est pareil.

[Papy214]

Pour le paramétrage du nom de la table, ça peut effectivement être une solution mais je ne vois pas trop ce que ça changerait saut à se passer du format.

Pour le TBacthmove, c'est une façon différente de le faire mais ça fera quoi de plus que de remplir ma table destination ?

Et pour le ExecSQLScalar, j'ai aussi testé avec un TFDQuery pour voir si ça changeait quelque chose mais sans succès.

Il y a forcément une raison côté Firedac qui fait les données ne sont pas trouvées mais la nuit n'a pas porté conseil.

A part pour une idée que je vais tester ce matin : Créer une seconde connexion sur la base pour voir si ça règle le problème.

à tout à l'heure pour des nouvelles sur ce point

[Papy214]

Plus ça va moins je comprends.

J'ai ajouté un second composant TFDConnection et je le paramètre de le même façon que le premier (copier-coller des lignes de code du paramétrage)
J'arrive à me connecter à la base mais quand je fais le ExecSQLScalar:



C'est si ma base n'existait pas alors que j'ai pu y envoyer des données.

Je sens que la journée va être longue .... longue ... très longue

[Papy214]

Ancien composant tfdconnection supprimé et remplacé par un sans aucun paramétrage dans l'inspecteur d'objet.
Nouvelle tentative et on dirait que ça fonctionne.
Il devait un truc qui gênait mais quoi ...

Ouf ... Je vais finir la semaine mieux que je ne pensais.

Merci à vous pour vos idées.

[pprem]

Tant mieux si ça s'est résolu, mais c'est quand même très louche cette histoire.

Si tu as une précédente version du .dfm ou .fmx, ça m'intéresserait de voir ce qui était au niveau du TFDConnection.

[Papy214]

Comme tu dis, l'important c'est que je m'en sois sorti avant ce soir.
J'ai encore eu une frayeur sur une table qui ne se transférait pas mais après vérification la source était vide. J'ai à nouveau dis ouf