Version imprimable
Salut à tous,
j'essaie de remplir un DBGrid avec le contenu d'une table se trouvant dans une base mysql. J'utilise un sqlclientdataset pour remplir le DBGrid
Je le fait exactement comme :
http://www.developpez.net/forums/vie....php?p=1074808
mais dès que je veux activer le sqlclientdataset il me met :
Je n'ai pas ce problème avec les sqldatasets (ils se remplissent normalement).Code:DBX error : invalid translation
Merci pour votre aide
Salut,Citation:
Envoyé par billoum
Je n'avais pas relevé ton post quand j'ai fait une recherche à mes fins personnelles (j'ai le même problème (cfMessage 386163)) car tu as le message d'erreur en anglais et moi en français.
Visiblement, ça n'inspire pas grand monde et moi je sèche lamentablement sur cette bizzarrerie. Voilà un élément au cas où ça pourrait aider à la résolution:
Chez moi tout marchait bien jusqu'à ce que je change la définition d'une colonne de la table pour y incorporer un "AUTO_INCREMENT" ! Depuis, j'ai redéfini la colonne comme elle était avant mais sans effet. J'ignore si cela a un rapport, mais je pense que oui étant donné que le code n'a pas changé...
Confirmation: mes tests de ce matin montrent que l'activation du composant SQLClientDataSet ne tolère pas qu'il y ait un champ autoincrémenté dans la table: j'ai vérifié avec des tables sans et d'autres avec: blocage dans ce dernier cas, pas dans le premier. C'est quand même un peu fort de café, non ?
Quelqu'un a -t'il une solution ou, faute de mieux, une explication ???
Salut pjtuloup,
je croyait être la seule victime de cette erreur, tu me rassures, je ne suis donc pas seul.
Mais bon, chez moi pas de champ auto-incrémenté, ça ne marche dans aucun cas.
Le pire avec ça, c'est qu'il n'y a aucune infos sur cette erreur sur le net, à croire qu'on est les deux seuls à avoir eu le coup.
Pour l'instant mySql avec c++builder, j'aime pas trop. Après avoir essayé (sans succès) d'utiliser l'API mysql, j'étais tout content de pouvoir me connecter avec dbexpress ... ben voilà
:arf:
a+
Salut Billoum,Citation:
Envoyé par billoum
Le peu de réactions enregistrées et le peu d'occurences à ce sujet dans les moteurs de recherches m'étonne moi aussi, mais ce problème doit être très rare: moi-même j'ai développé l'an dernier pour le boulot une grosse application en C++ Builder avec Mysql sans aucun problème (et heureusement parce qu'alors mes nerfs auraient lâché pour de bon...)
Bon, Venons-en au fait: J'ai résolu le problème en ce qui me concerne alors je te livre le fruit de mes observations, on ne sait jamais.
Le problème était bien lié au fait que j'avais changé la définition d'une colonne pour lui ajouter l'attribut auto-incrément. Mais note bien qu'il a persisté alors que j'étais revenu à la situation antérieure en ôtant cet attribut auto-increment de la définition de la colonne en cause (Je présume que cela est lié au fait que l'attribut Primary Key ait subsisté lui aussi)! J'ai dû finalement exporter les données vers un fichier texte, supprimer la table, recréer la table, importer les données et là, plus de problème, ça passe...
Voici pour finir un récapitulatif des commandes Show Columns pour chaque état de la table, avec le résultat vis à vis du programme C++ Builder quand il l'utilise (activation du Dataset):
1° (table avec Colonne modifiée par Alter Table Change Column pour introduire Autoincrément)
Field Type Null Key Default Extra
IDDOM TINYINT (4) PRI NULL AUTO_INCREMENT =>Problème
LIBELLE VARCHAR(20) YES NULL
2° (table après Colonne remodifiée par Alter table Change Column pour supprimer Autoincrément)
Field Type Null Key Default Extra
IDDOM TINYINT (4) PRI 0 =>Problème
LIBELLE VARCHAR(20) YES NULL
3° (table après suppression et recréation)
Field Type Null Key Default Extra
IDDOM TINYINT (4) YES NULL =>Pas de Problème
LIBELLE VARCHAR(20) YES NULL
Je vais mettre le Tag [Résolu] sur mon propre fil et je te souhaite bon courage si tout cela ne se révèle pas utile pour toi...
ALLELUIA, j'ai trouvé :yaisse2: (bon d'accord j'ai mis le temps).
C'était dû au fait que que j'utilisais des tables InnoDB qui sont des tables transactionnelles et donc il fallait mettre un verrou de lecture :
Bon là-dessus je vais devoir me mettre au transaction (donc à très bientôt :wink: ).Code:SELECT * FROM t LOCK IN SHARE MODE;
a+
J'ai eu le même problème avec une base mysql... j'ai donc mis lock in share mode.
Mais j'ai un problème maintenant quand je veux lié 2 tables en utilisant mastersource. A l'execution, il me met une erreur dans la requête.
I'm Colombian, I speak spanish. If you want to understand me, take the text and go to a translator, like google's one and translate it.
Hola! he tenido el mismo maldito problema con el dbexpress para conectarme a mysql. Lei sus ideas y comprobé que efectivamente al quitar los primary key se soluciona todo... todo excepto que uno necesita los primary keys. entonces, después de muchos intentos y experimentos, logré que mi aplicación corra sin problema y con sus primary keys como deben ser.
La solución fue "ZEOS". Son unas librerias que hacen algo similar a dbexpress pero sin tantos errores fastidiosos. Les recomiendo que usen la versión 5.4. aunque ya van en la 6.x, la 5.4 corre sin problemas.
Cuando hallan instalado ZEOS, solo tienen que remplazar los componentes DBExpress por sus equivalentes Zeos. Por ejemplo, una tabla Dbexpress se reemplaza por una tabla zeos. Las tablas zeos requieren otro componente zeos llamado transaction, pero usarlo no es ningun problema. La tabla zeos va ligada a una base de datos zeos que remplaza la conexion dbexpress.
En mi caso, uso TClientDataSet. así que sólo tube que decirle al TProvider que no tomara como dataset a la tabla DBExpress sino a la tabal Zeos. Eso arregló el problema de raiz.
Si les gusta la idea de Zeos, pueden buscar en google y encontrarán los istios de descarga (es free software GNU) y mucha información sobre la utilización de Zeos.
Espero haber podido explicar bien mi idea.
Con cariño desde mi hermoso país, COLOMBIA, les mando un abrazo.
Chao
8)