Suite à une requête où je concatène des chaînes de caractères, je me
retrouve in fine avec une chaîne de plus de 255 caractères... qui est
bien entendu tronquée!
Comment faire pour qu'une chaîne de caractères soit plus longue que
255 caractères?
Ou existe-t-il un autre type de données, style "super chaîne de
caractères"?
Merci par avance pour vos réponses.
Christophe.
oddo@pasdespam2002webconcept.com
--------------------------------
"... Mais c'est de l'homme qu'il s'agit! [...]
Quelqu'un au monde élèvera-t-il la voix? [...]
Se hâter! se hâter! témoignage pour l'homme!"
(Saint-John Perse, Vents, III, 4)
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Gafish
Bonjour,
Tu as le type mémo qui peut stocker beaucoup plus de caractères.
Arnaud
"Christophe ODDO" a écrit dans le message news:
Bonjour à tous,
Suite à une requête où je concatène des chaînes de caractères, je me retrouve in fine avec une chaîne de plus de 255 caractères... qui est bien entendu tronquée!
Comment faire pour qu'une chaîne de caractères soit plus longue que 255 caractères?
Ou existe-t-il un autre type de données, style "super chaîne de caractères"?
Merci par avance pour vos réponses.
Christophe.
-------------------------------- "... Mais c'est de l'homme qu'il s'agit! [...] Quelqu'un au monde élèvera-t-il la voix? [...] Se hâter! se hâter! témoignage pour l'homme!" (Saint-John Perse, Vents, III, 4)
Bonjour,
Tu as le type mémo qui peut stocker beaucoup plus de caractères.
Arnaud
"Christophe ODDO" <oddo@pasdespam2002webconcept.com> a écrit dans le message
news: m6h911556apah0pg95a8g19d6tt3c968d8@4ax.com...
Bonjour à tous,
Suite à une requête où je concatène des chaînes de caractères, je me
retrouve in fine avec une chaîne de plus de 255 caractères... qui est
bien entendu tronquée!
Comment faire pour qu'une chaîne de caractères soit plus longue que
255 caractères?
Ou existe-t-il un autre type de données, style "super chaîne de
caractères"?
Merci par avance pour vos réponses.
Christophe.
oddo@pasdespam2002webconcept.com
--------------------------------
"... Mais c'est de l'homme qu'il s'agit! [...]
Quelqu'un au monde élèvera-t-il la voix? [...]
Se hâter! se hâter! témoignage pour l'homme!"
(Saint-John Perse, Vents, III, 4)
Tu as le type mémo qui peut stocker beaucoup plus de caractères.
Arnaud
"Christophe ODDO" a écrit dans le message news:
Bonjour à tous,
Suite à une requête où je concatène des chaînes de caractères, je me retrouve in fine avec une chaîne de plus de 255 caractères... qui est bien entendu tronquée!
Comment faire pour qu'une chaîne de caractères soit plus longue que 255 caractères?
Ou existe-t-il un autre type de données, style "super chaîne de caractères"?
Merci par avance pour vos réponses.
Christophe.
-------------------------------- "... Mais c'est de l'homme qu'il s'agit! [...] Quelqu'un au monde élèvera-t-il la voix? [...] Se hâter! se hâter! témoignage pour l'homme!" (Saint-John Perse, Vents, III, 4)
Christophe ODDO
Merci pour ta réponse,
Mais comment transformer, lors de ma requête, ma concaténation de "strings" en type mémo?
Y a-t-il une fonction pour cela?
Christophe.
Le Thu, 17 Feb 2005 17:57:45 +0100, "Gafish" a écrit:
Bonjour,
Tu as le type mémo qui peut stocker beaucoup plus de caractères.
Arnaud
Merci pour ta réponse,
Mais comment transformer, lors de ma requête, ma concaténation de
"strings" en type mémo?
Y a-t-il une fonction pour cela?
Christophe.
Le Thu, 17 Feb 2005 17:57:45 +0100, "Gafish"
<---gafish@free.fr----nospam> a écrit:
Bonjour,
Tu as le type mémo qui peut stocker beaucoup plus de caractères.
Mais comment transformer, lors de ma requête, ma concaténation de "strings" en type mémo?
Y a-t-il une fonction pour cela?
Christophe.
Le Thu, 17 Feb 2005 17:57:45 +0100, "Gafish" a écrit:
Bonjour,
Tu as le type mémo qui peut stocker beaucoup plus de caractères.
Arnaud
Raymond [mvp]
Bonsoir.
je me permets de mettre mon grain de sel. la concaténation de champs texte peut dépasser 255 caractères et n'est pas tronquée. sauf si le type de requête fait que la concaténation sera tronquée, par exemple, une requête union, une requête regroupement, un tri sur la concaténation etc........ et le problème ne sera pas résolu par un champ mémo qui ne peut exister que dans une table et non être créé dans une requête.
-- @+ Raymond Access MVP http://OfficeSystem.Access.free.fr/ http://OfficeSystem.Access.free.fr/runtime/ http://users.skynet.be/mpfa/ pour débuter sur le forum
"Christophe ODDO" a écrit dans le message de news:
Merci pour ta réponse,
Mais comment transformer, lors de ma requête, ma concaténation de "strings" en type mémo?
Y a-t-il une fonction pour cela?
Christophe.
Bonsoir.
je me permets de mettre mon grain de sel.
la concaténation de champs texte peut dépasser 255 caractères et n'est pas
tronquée. sauf si le type de requête fait que la concaténation sera
tronquée, par exemple, une requête union, une requête regroupement, un tri
sur la concaténation etc........ et le problème ne sera pas résolu par un
champ mémo qui ne peut exister que dans une table et non être créé dans une
requête.
--
@+
Raymond Access MVP
http://OfficeSystem.Access.free.fr/
http://OfficeSystem.Access.free.fr/runtime/
http://users.skynet.be/mpfa/ pour débuter sur le forum
"Christophe ODDO" <oddo@pasdespam2002webconcept.com> a écrit dans le message
de news: 2ej91153jpj71sviovae63mlv4329t1nj1@4ax.com...
Merci pour ta réponse,
Mais comment transformer, lors de ma requête, ma concaténation de
"strings" en type mémo?
je me permets de mettre mon grain de sel. la concaténation de champs texte peut dépasser 255 caractères et n'est pas tronquée. sauf si le type de requête fait que la concaténation sera tronquée, par exemple, une requête union, une requête regroupement, un tri sur la concaténation etc........ et le problème ne sera pas résolu par un champ mémo qui ne peut exister que dans une table et non être créé dans une requête.
-- @+ Raymond Access MVP http://OfficeSystem.Access.free.fr/ http://OfficeSystem.Access.free.fr/runtime/ http://users.skynet.be/mpfa/ pour débuter sur le forum
"Christophe ODDO" a écrit dans le message de news:
Merci pour ta réponse,
Mais comment transformer, lors de ma requête, ma concaténation de "strings" en type mémo?
Y a-t-il une fonction pour cela?
Christophe.
Christophe ODDO
En fait, voilà ce qui se passe.
J'ai une table contenant des champs "Oui/Non" sous forme de cases à cocher.
Une fois cette table renseignée, j'effectue une première requête, sur cette table, avec des instructions VraiFaux(), pour transformer mes champs "Oui/Non" en texte que je définie (si la valeur est Vrai) ou en "" (si la valeur est Faux).
J'effectue ensuite une seconde requête, sur la première requête, pour concaténer les résultats et faire disparaître les éventuels espaces, avec des SupprEspace(champ1 & " " & champ2...).
Et lorsque je veux faire apparaître le résultats de ces concaténations (de la deuxième requête donc) dans un état, je me retrouve avec des lignes tronquées...
J'ai supposé que cela venait du fait que le Vrai/Faux créait des champs "chaînes de caractères" et que la concaténation conservait ce type de données, limitées à 255 caractères. Peut-être ai-je mal analysé le problème.
D'après vous, d'où le problème provient-il?
Et surtout, comment le résoudre?
Merci par avance pour vos réponses.
Cordialement, Christophe.
Le Thu, 17 Feb 2005 19:44:00 +0100, "Raymond [mvp]" a écrit:
Bonsoir.
je me permets de mettre mon grain de sel. la concaténation de champs texte peut dépasser 255 caractères et n'est pas tronquée. sauf si le type de requête fait que la concaténation sera tronquée, par exemple, une requête union, une requête regroupement, un tri sur la concaténation etc........ et le problème ne sera pas résolu par un champ mémo qui ne peut exister que dans une table et non être créé dans une requête.
-------------------------------- "... Mais c'est de l'homme qu'il s'agit! [...] Quelqu'un au monde élèvera-t-il la voix? [...] Se hâter! se hâter! témoignage pour l'homme!" (Saint-John Perse, Vents, III, 4)
En fait, voilà ce qui se passe.
J'ai une table contenant des champs "Oui/Non" sous forme de cases à
cocher.
Une fois cette table renseignée, j'effectue une première requête, sur
cette table, avec des instructions VraiFaux(), pour transformer mes
champs "Oui/Non" en texte que je définie (si la valeur est Vrai) ou en
"" (si la valeur est Faux).
J'effectue ensuite une seconde requête, sur la première requête, pour
concaténer les résultats et faire disparaître les éventuels espaces,
avec des SupprEspace(champ1 & " " & champ2...).
Et lorsque je veux faire apparaître le résultats de ces concaténations
(de la deuxième requête donc) dans un état, je me retrouve avec des
lignes tronquées...
J'ai supposé que cela venait du fait que le Vrai/Faux créait des
champs "chaînes de caractères" et que la concaténation conservait ce
type de données, limitées à 255 caractères. Peut-être ai-je mal
analysé le problème.
D'après vous, d'où le problème provient-il?
Et surtout, comment le résoudre?
Merci par avance pour vos réponses.
Cordialement,
Christophe.
Le Thu, 17 Feb 2005 19:44:00 +0100, "Raymond [mvp]"
<XYZ.officesystem.access@free.fr> a écrit:
Bonsoir.
je me permets de mettre mon grain de sel.
la concaténation de champs texte peut dépasser 255 caractères et n'est pas
tronquée. sauf si le type de requête fait que la concaténation sera
tronquée, par exemple, une requête union, une requête regroupement, un tri
sur la concaténation etc........ et le problème ne sera pas résolu par un
champ mémo qui ne peut exister que dans une table et non être créé dans une
requête.
oddo@pasdespam2002webconcept.com
--------------------------------
"... Mais c'est de l'homme qu'il s'agit! [...]
Quelqu'un au monde élèvera-t-il la voix? [...]
Se hâter! se hâter! témoignage pour l'homme!"
(Saint-John Perse, Vents, III, 4)
J'ai une table contenant des champs "Oui/Non" sous forme de cases à cocher.
Une fois cette table renseignée, j'effectue une première requête, sur cette table, avec des instructions VraiFaux(), pour transformer mes champs "Oui/Non" en texte que je définie (si la valeur est Vrai) ou en "" (si la valeur est Faux).
J'effectue ensuite une seconde requête, sur la première requête, pour concaténer les résultats et faire disparaître les éventuels espaces, avec des SupprEspace(champ1 & " " & champ2...).
Et lorsque je veux faire apparaître le résultats de ces concaténations (de la deuxième requête donc) dans un état, je me retrouve avec des lignes tronquées...
J'ai supposé que cela venait du fait que le Vrai/Faux créait des champs "chaînes de caractères" et que la concaténation conservait ce type de données, limitées à 255 caractères. Peut-être ai-je mal analysé le problème.
D'après vous, d'où le problème provient-il?
Et surtout, comment le résoudre?
Merci par avance pour vos réponses.
Cordialement, Christophe.
Le Thu, 17 Feb 2005 19:44:00 +0100, "Raymond [mvp]" a écrit:
Bonsoir.
je me permets de mettre mon grain de sel. la concaténation de champs texte peut dépasser 255 caractères et n'est pas tronquée. sauf si le type de requête fait que la concaténation sera tronquée, par exemple, une requête union, une requête regroupement, un tri sur la concaténation etc........ et le problème ne sera pas résolu par un champ mémo qui ne peut exister que dans une table et non être créé dans une requête.
-------------------------------- "... Mais c'est de l'homme qu'il s'agit! [...] Quelqu'un au monde élèvera-t-il la voix? [...] Se hâter! se hâter! témoignage pour l'homme!" (Saint-John Perse, Vents, III, 4)
Raymond [mvp]
la suppression des espaces n'est pas la cause des lignes tronquées. est-ce que l'exécution de la requête où est faite la concaténation , si elle est lancée seule, tronque de la même façon ? -- @+ Raymond Access MVP http://OfficeSystem.Access.free.fr/ http://OfficeSystem.Access.free.fr/runtime/ http://users.skynet.be/mpfa/ pour débuter sur le forum
"Christophe ODDO" a écrit dans le message de news:
En fait, voilà ce qui se passe.
J'ai une table contenant des champs "Oui/Non" sous forme de cases à cocher.
Une fois cette table renseignée, j'effectue une première requête, sur cette table, avec des instructions VraiFaux(), pour transformer mes champs "Oui/Non" en texte que je définie (si la valeur est Vrai) ou en "" (si la valeur est Faux).
J'effectue ensuite une seconde requête, sur la première requête, pour concaténer les résultats et faire disparaître les éventuels espaces, avec des SupprEspace(champ1 & " " & champ2...).
Et lorsque je veux faire apparaître le résultats de ces concaténations (de la deuxième requête donc) dans un état, je me retrouve avec des lignes tronquées...
J'ai supposé que cela venait du fait que le Vrai/Faux créait des champs "chaînes de caractères" et que la concaténation conservait ce type de données, limitées à 255 caractères. Peut-être ai-je mal analysé le problème.
D'après vous, d'où le problème provient-il?
Et surtout, comment le résoudre?
Merci par avance pour vos réponses.
Cordialement, Christophe.
la suppression des espaces n'est pas la cause des lignes tronquées.
est-ce que l'exécution de la requête où est faite la concaténation , si elle
est lancée seule, tronque de la même façon ?
--
@+
Raymond Access MVP
http://OfficeSystem.Access.free.fr/
http://OfficeSystem.Access.free.fr/runtime/
http://users.skynet.be/mpfa/ pour débuter sur le forum
"Christophe ODDO" <oddo@pasdespam2002webconcept.com> a écrit dans le message
de news: hgv911ph6up8478een55gvgnh0dm92t7an@4ax.com...
En fait, voilà ce qui se passe.
J'ai une table contenant des champs "Oui/Non" sous forme de cases à
cocher.
Une fois cette table renseignée, j'effectue une première requête, sur
cette table, avec des instructions VraiFaux(), pour transformer mes
champs "Oui/Non" en texte que je définie (si la valeur est Vrai) ou en
"" (si la valeur est Faux).
J'effectue ensuite une seconde requête, sur la première requête, pour
concaténer les résultats et faire disparaître les éventuels espaces,
avec des SupprEspace(champ1 & " " & champ2...).
Et lorsque je veux faire apparaître le résultats de ces concaténations
(de la deuxième requête donc) dans un état, je me retrouve avec des
lignes tronquées...
J'ai supposé que cela venait du fait que le Vrai/Faux créait des
champs "chaînes de caractères" et que la concaténation conservait ce
type de données, limitées à 255 caractères. Peut-être ai-je mal
analysé le problème.
la suppression des espaces n'est pas la cause des lignes tronquées. est-ce que l'exécution de la requête où est faite la concaténation , si elle est lancée seule, tronque de la même façon ? -- @+ Raymond Access MVP http://OfficeSystem.Access.free.fr/ http://OfficeSystem.Access.free.fr/runtime/ http://users.skynet.be/mpfa/ pour débuter sur le forum
"Christophe ODDO" a écrit dans le message de news:
En fait, voilà ce qui se passe.
J'ai une table contenant des champs "Oui/Non" sous forme de cases à cocher.
Une fois cette table renseignée, j'effectue une première requête, sur cette table, avec des instructions VraiFaux(), pour transformer mes champs "Oui/Non" en texte que je définie (si la valeur est Vrai) ou en "" (si la valeur est Faux).
J'effectue ensuite une seconde requête, sur la première requête, pour concaténer les résultats et faire disparaître les éventuels espaces, avec des SupprEspace(champ1 & " " & champ2...).
Et lorsque je veux faire apparaître le résultats de ces concaténations (de la deuxième requête donc) dans un état, je me retrouve avec des lignes tronquées...
J'ai supposé que cela venait du fait que le Vrai/Faux créait des champs "chaînes de caractères" et que la concaténation conservait ce type de données, limitées à 255 caractères. Peut-être ai-je mal analysé le problème.
D'après vous, d'où le problème provient-il?
Et surtout, comment le résoudre?
Merci par avance pour vos réponses.
Cordialement, Christophe.
Christophe ODDO
Et bien, lors de la première requête (celle qui transforme les Oui/Non en chaînes de caractères), rien n'est tronqué puisque les chaînes font moins de 255 caractères.
C'est lors de la seconde requête (celle qui concatène à partir des résultats de la première requête et qui supprime les espaces) que mes résultats sont tronqués. En fait, la concaténation et la suppression des espaces sont effectuées dans une même requête par un: SupprEspace(champ1 & " " & champ2 & " " & champ3 & ... etc).
Difficile d'expliquer le problème quand on n'est pas un habitué d'Access... Désolé! ;-)
Christophe
Le Thu, 17 Feb 2005 21:55:54 +0100, "Raymond [mvp]" a écrit:
la suppression des espaces n'est pas la cause des lignes tronquées. est-ce que l'exécution de la requête où est faite la concaténation , si elle est lancée seule, tronque de la même façon ?
Et bien, lors de la première requête (celle qui transforme les Oui/Non
en chaînes de caractères), rien n'est tronqué puisque les chaînes font
moins de 255 caractères.
C'est lors de la seconde requête (celle qui concatène à partir des
résultats de la première requête et qui supprime les espaces) que mes
résultats sont tronqués. En fait, la concaténation et la suppression
des espaces sont effectuées dans une même requête par un:
SupprEspace(champ1 & " " & champ2 & " " & champ3 & ... etc).
Difficile d'expliquer le problème quand on n'est pas un habitué
d'Access... Désolé! ;-)
Christophe
Le Thu, 17 Feb 2005 21:55:54 +0100, "Raymond [mvp]"
<XYZ.officesystem.access@free.fr> a écrit:
la suppression des espaces n'est pas la cause des lignes tronquées.
est-ce que l'exécution de la requête où est faite la concaténation , si elle
est lancée seule, tronque de la même façon ?
Et bien, lors de la première requête (celle qui transforme les Oui/Non en chaînes de caractères), rien n'est tronqué puisque les chaînes font moins de 255 caractères.
C'est lors de la seconde requête (celle qui concatène à partir des résultats de la première requête et qui supprime les espaces) que mes résultats sont tronqués. En fait, la concaténation et la suppression des espaces sont effectuées dans une même requête par un: SupprEspace(champ1 & " " & champ2 & " " & champ3 & ... etc).
Difficile d'expliquer le problème quand on n'est pas un habitué d'Access... Désolé! ;-)
Christophe
Le Thu, 17 Feb 2005 21:55:54 +0100, "Raymond [mvp]" a écrit:
la suppression des espaces n'est pas la cause des lignes tronquées. est-ce que l'exécution de la requête où est faite la concaténation , si elle est lancée seule, tronque de la même façon ?
Raymond [mvp]
Tu as une option qui fait que c'est tronqué, mais le trim n'a jamais fait tronqué les concaténations, jusqu'à maintenant. tu veux bien me passer tes 2 requêtes et un minimum de données pour voir ? enlève XYZ. (le point aussi) dans mon adresse.
-- @+ Raymond Access MVP http://OfficeSystem.Access.free.fr/ http://OfficeSystem.Access.free.fr/runtime/ http://users.skynet.be/mpfa/ pour débuter sur le forum
"Christophe ODDO" a écrit dans le message de news:
Et bien, lors de la première requête (celle qui transforme les Oui/Non en chaînes de caractères), rien n'est tronqué puisque les chaînes font moins de 255 caractères.
C'est lors de la seconde requête (celle qui concatène à partir des résultats de la première requête et qui supprime les espaces) que mes résultats sont tronqués. En fait, la concaténation et la suppression des espaces sont effectuées dans une même requête par un: SupprEspace(champ1 & " " & champ2 & " " & champ3 & ... etc).
Difficile d'expliquer le problème quand on n'est pas un habitué d'Access... Désolé! ;-)
Christophe
Tu as une option qui fait que c'est tronqué, mais le trim n'a jamais fait
tronqué les concaténations, jusqu'à maintenant.
tu veux bien me passer tes 2 requêtes et un minimum de données pour voir ?
enlève XYZ. (le point aussi) dans mon adresse.
--
@+
Raymond Access MVP
http://OfficeSystem.Access.free.fr/
http://OfficeSystem.Access.free.fr/runtime/
http://users.skynet.be/mpfa/ pour débuter sur le forum
"Christophe ODDO" <oddo@pasdespam2002webconcept.com> a écrit dans le message
de news: gn3a11pkjlrego1l6vg4oqkijp8jgi9f80@4ax.com...
Et bien, lors de la première requête (celle qui transforme les Oui/Non
en chaînes de caractères), rien n'est tronqué puisque les chaînes font
moins de 255 caractères.
C'est lors de la seconde requête (celle qui concatène à partir des
résultats de la première requête et qui supprime les espaces) que mes
résultats sont tronqués. En fait, la concaténation et la suppression
des espaces sont effectuées dans une même requête par un:
SupprEspace(champ1 & " " & champ2 & " " & champ3 & ... etc).
Difficile d'expliquer le problème quand on n'est pas un habitué
d'Access... Désolé! ;-)
Tu as une option qui fait que c'est tronqué, mais le trim n'a jamais fait tronqué les concaténations, jusqu'à maintenant. tu veux bien me passer tes 2 requêtes et un minimum de données pour voir ? enlève XYZ. (le point aussi) dans mon adresse.
-- @+ Raymond Access MVP http://OfficeSystem.Access.free.fr/ http://OfficeSystem.Access.free.fr/runtime/ http://users.skynet.be/mpfa/ pour débuter sur le forum
"Christophe ODDO" a écrit dans le message de news:
Et bien, lors de la première requête (celle qui transforme les Oui/Non en chaînes de caractères), rien n'est tronqué puisque les chaînes font moins de 255 caractères.
C'est lors de la seconde requête (celle qui concatène à partir des résultats de la première requête et qui supprime les espaces) que mes résultats sont tronqués. En fait, la concaténation et la suppression des espaces sont effectuées dans une même requête par un: SupprEspace(champ1 & " " & champ2 & " " & champ3 & ... etc).
Difficile d'expliquer le problème quand on n'est pas un habitué d'Access... Désolé! ;-)
Christophe
Christophe ODDO
Bonjour Raymond,
En voulant recréer (pour vous l'envoyer) une table similaire à la mienne, mais plus petite (la mienne fait 7 Mo... d'ailleurs, je ne comprends pas qu'elle ait une taille si importante, compte-tenu du nombre limité d'informations qu'elle contient), j'ai résolu le problème.
Il semblerait que l'assistant de requête interdise des requêtes ou plutôt des lignes de requêtes trop longues. Du coup, mes lignes de concaténation étaient tronquées, mais bien terminées par une parenthèse, ce qui assurait leur exécution. J'ai donc coupé en deux ces lignes trop longues (dans deux colonnes différentes), puis j'ai concaténé leur résultat (dans une troisième colonne)... et tout a marché.
En tout cas, un énorme merci pour votre contribution, et plus généralement pour votre participation active à ce groupe... puisque vous semblez venir en aide à beaucoup de personnes qui ont des difficultés avec Access...
C'est assez rare de nos jours pour que l'on vous en remercie officiellement.
Cordialement,
Christophe.
Le Fri, 18 Feb 2005 09:16:18 +0100, "Raymond [mvp]" a écrit:
Tu as une option qui fait que c'est tronqué, mais le trim n'a jamais fait tronqué les concaténations, jusqu'à maintenant. tu veux bien me passer tes 2 requêtes et un minimum de données pour voir ? enlève XYZ. (le point aussi) dans mon adresse.
-------------------------------- "... Mais c'est de l'homme qu'il s'agit! [...] Quelqu'un au monde élèvera-t-il la voix? [...] Se hâter! se hâter! témoignage pour l'homme!" (Saint-John Perse, Vents, III, 4)
Bonjour Raymond,
En voulant recréer (pour vous l'envoyer) une table similaire à la
mienne, mais plus petite (la mienne fait 7 Mo... d'ailleurs, je ne
comprends pas qu'elle ait une taille si importante, compte-tenu du
nombre limité d'informations qu'elle contient), j'ai résolu le
problème.
Il semblerait que l'assistant de requête interdise des requêtes ou
plutôt des lignes de requêtes trop longues.
Du coup, mes lignes de concaténation étaient tronquées, mais bien
terminées par une parenthèse, ce qui assurait leur exécution.
J'ai donc coupé en deux ces lignes trop longues (dans deux colonnes
différentes), puis j'ai concaténé leur résultat (dans une troisième
colonne)... et tout a marché.
En tout cas, un énorme merci pour votre contribution, et plus
généralement pour votre participation active à ce groupe... puisque
vous semblez venir en aide à beaucoup de personnes qui ont des
difficultés avec Access...
C'est assez rare de nos jours pour que l'on vous en remercie
officiellement.
Cordialement,
Christophe.
Le Fri, 18 Feb 2005 09:16:18 +0100, "Raymond [mvp]"
<XYZ.officesystem.access@free.fr> a écrit:
Tu as une option qui fait que c'est tronqué, mais le trim n'a jamais fait
tronqué les concaténations, jusqu'à maintenant.
tu veux bien me passer tes 2 requêtes et un minimum de données pour voir ?
enlève XYZ. (le point aussi) dans mon adresse.
oddo@pasdespam2002webconcept.com
--------------------------------
"... Mais c'est de l'homme qu'il s'agit! [...]
Quelqu'un au monde élèvera-t-il la voix? [...]
Se hâter! se hâter! témoignage pour l'homme!"
(Saint-John Perse, Vents, III, 4)
En voulant recréer (pour vous l'envoyer) une table similaire à la mienne, mais plus petite (la mienne fait 7 Mo... d'ailleurs, je ne comprends pas qu'elle ait une taille si importante, compte-tenu du nombre limité d'informations qu'elle contient), j'ai résolu le problème.
Il semblerait que l'assistant de requête interdise des requêtes ou plutôt des lignes de requêtes trop longues. Du coup, mes lignes de concaténation étaient tronquées, mais bien terminées par une parenthèse, ce qui assurait leur exécution. J'ai donc coupé en deux ces lignes trop longues (dans deux colonnes différentes), puis j'ai concaténé leur résultat (dans une troisième colonne)... et tout a marché.
En tout cas, un énorme merci pour votre contribution, et plus généralement pour votre participation active à ce groupe... puisque vous semblez venir en aide à beaucoup de personnes qui ont des difficultés avec Access...
C'est assez rare de nos jours pour que l'on vous en remercie officiellement.
Cordialement,
Christophe.
Le Fri, 18 Feb 2005 09:16:18 +0100, "Raymond [mvp]" a écrit:
Tu as une option qui fait que c'est tronqué, mais le trim n'a jamais fait tronqué les concaténations, jusqu'à maintenant. tu veux bien me passer tes 2 requêtes et un minimum de données pour voir ? enlève XYZ. (le point aussi) dans mon adresse.
-------------------------------- "... Mais c'est de l'homme qu'il s'agit! [...] Quelqu'un au monde élèvera-t-il la voix? [...] Se hâter! se hâter! témoignage pour l'homme!" (Saint-John Perse, Vents, III, 4)
