Le 16/03/07, Ludovic CHEVALIER<[EMAIL PROTECTED]> a écrit :
Bonjour et merci. Ça me fait avancer.
Bonjour,
Docgranville a écrit :
> J'imagine que ce n'est pas ça (beaucoup trop simple), mais sait-on
> jamais, autant fermer cette porte tout de suite ;
Ce n'est effectivement pas ça. Car, si je n'ajoute que l'ID dans la
table, ça fonctionne.
> tu mentionnes que ta
> table de destination comporte un clef primaire ; tu as vérifié qu'elle
> n'était pas en autovalue ?
Et même en autovalue, ça fonctionne.
>
> En dehors de cette hypothèse tu es certain qu'aucune colonne mentionnée
> avec une contrainte "unique" ne comporte deux valeurs semblables ?
Non,non. Ça c'est tout bon.
>
> La dernière possibilité qui me semble se présenter souvent, est celle
> d'une valeur de ta table d'origine dépassant les limites fixées dans la
> définition d'une colonne de la table de destination.
Oui. Je crois que tu touche le fond du problème.
Mais ajouts de données fonctionne bien à condition que j'y mette bien le
champ correspondant à la clé primaire, et surtout, que je désactive
l'import de données dates.
J'ai donc modifier les champs date de destination de date à datetime
sans plus de résultat.
J'ai remarqué que les données date une fois dans calc étaient notées
'JJ/MM/AAAA (avec apostrophe). Peut-être est-ce donc considéré comme du
texte.
le format de date pour hsqldb est impérativement YYYY-MM-JJ,
normalement encadré de guillemet simple ('). essaye de changer le
format de date dans Calc.
En tous cas, ce sont bien des dates que je souhaite récuperer.
Je vais aller chercher dans les archives de la liste, mais si vous voyez
une soltuion, je suis preneur.
Note importante: quand je modifie un champ, celui ci se retrouve ensuite
en fin de table, sans que je puisse le déplacer, c'est particulièrement
embêtant.
Merci encore Docgranville pour ton aide.
Ludo
Manuel
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
