Bonjour,
J'ai un probl=E8me d'=E9criture dans une cellule.
Je souhaite =E9crire une chaine de caract=E8re dans une cellule, mais
cette chaine fait plus de 1024 caract=E8res.
Je ne peux pas car j'ai une erreur "m=E9moire insuffisante".
Pourtant, quand je me sers de microsoft queries
(donn=E9es->donn=E9es externes->cr=E9er une requ=EAte)
J'arrive =E0 importer des cellules de plus de 1600 caract=E8res.
Il doit donc y avoir un moyen de d=E9passer cette limitation.
Es-ce que quelqu'un la connait?
J'ai testé à nouveau la procédure initiale que j'ai faite.
J'ai créé une "base de données" dans access avec seulement une table : Table1 Dans cette table, il n'y a que deux champs : Data et Data1 ayant le type mémo. et dans le champ data de l'enregistrement 1 il y a 63186 caractères et 9 autres enregistrements ont plus de 32800 caractères. À l'exécution de la procécure, il y a bien 32767 caractères dans les cellules d'excel. C'est la limite bien connu d'une cellule de la feuille de calcul.
Aucune difficulté avec la procédure, aucun message d'erreur. Ceci a été testé sous Windows Xp pro et Excel 2003.
La bibliothèque ADO utilisé fut pour le test : "Microsoft Activex Data Object 2.0 Librairy"
En Théorie et en pratique, cette procédure fonctionne très bien. Cependant, si tu as beaucoup de champs et beaucoup d'enregistrements à transférer dont le type de données de ta base (mdb) est "mémo"... il est peut être possible de dépasser les limites permises. Quelles sont ces limites si elles existent je ne le sais pas !!! Delà à dire que ceci ne fonctionne pas, il y a un pas que je ne franchira pas!
Salutations!
"Bowen" a écrit dans le message de news:
Bonjour,
J'ai pu tester sur un poste avec office 2003, et le problème persiste. Je n'ai plus d'autre choix que celui de tronquer le champ en avertissant l'utilisateur.
Merci encore à Michdenis pour ton aide précieuse.
Bowen.
Bonjour Bowen,
J'ai testé à nouveau la procédure initiale que j'ai faite.
J'ai créé une "base de données" dans access avec seulement une table : Table1
Dans cette table, il n'y a que deux champs : Data et Data1 ayant le type mémo.
et dans le champ data de l'enregistrement 1 il y a 63186 caractères et 9
autres enregistrements ont plus de 32800 caractères. À l'exécution de
la procécure, il y a bien 32767 caractères dans les cellules d'excel.
C'est la limite bien connu d'une cellule de la feuille de calcul.
Aucune difficulté avec la procédure, aucun message d'erreur.
Ceci a été testé sous Windows Xp pro et Excel 2003.
La bibliothèque ADO utilisé fut pour le test :
"Microsoft Activex Data Object 2.0 Librairy"
En Théorie et en pratique, cette procédure fonctionne très bien.
Cependant, si tu as beaucoup de champs et beaucoup d'enregistrements
à transférer dont le type de données de ta base (mdb) est "mémo"... il est
peut être possible de dépasser les limites permises. Quelles sont ces
limites si elles existent je ne le sais pas !!! Delà à dire que ceci ne
fonctionne pas, il y a un pas que je ne franchira pas!
Salutations!
"Bowen" <joel.cocandeau.mailings@gmail.com> a écrit dans le message de news:
1137510462.247031.151850@z14g2000cwz.googlegroups.com...
Bonjour,
J'ai pu tester sur un poste avec office 2003, et le problème persiste.
Je n'ai plus d'autre choix que celui de tronquer le champ en
avertissant l'utilisateur.
J'ai testé à nouveau la procédure initiale que j'ai faite.
J'ai créé une "base de données" dans access avec seulement une table : Table1 Dans cette table, il n'y a que deux champs : Data et Data1 ayant le type mémo. et dans le champ data de l'enregistrement 1 il y a 63186 caractères et 9 autres enregistrements ont plus de 32800 caractères. À l'exécution de la procécure, il y a bien 32767 caractères dans les cellules d'excel. C'est la limite bien connu d'une cellule de la feuille de calcul.
Aucune difficulté avec la procédure, aucun message d'erreur. Ceci a été testé sous Windows Xp pro et Excel 2003.
La bibliothèque ADO utilisé fut pour le test : "Microsoft Activex Data Object 2.0 Librairy"
En Théorie et en pratique, cette procédure fonctionne très bien. Cependant, si tu as beaucoup de champs et beaucoup d'enregistrements à transférer dont le type de données de ta base (mdb) est "mémo"... il est peut être possible de dépasser les limites permises. Quelles sont ces limites si elles existent je ne le sais pas !!! Delà à dire que ceci ne fonctionne pas, il y a un pas que je ne franchira pas!
Salutations!
"Bowen" a écrit dans le message de news:
Bonjour,
J'ai pu tester sur un poste avec office 2003, et le problème persiste. Je n'ai plus d'autre choix que celui de tronquer le champ en avertissant l'utilisateur.
Merci encore à Michdenis pour ton aide précieuse.
Bowen.
Bowen
En fait, je dis juste que ça ne fonctionne pas chez moi... La version ado est 2.8 La table contient peu données (environ 70 lignes pour 30 colonnes dont un champ memo contenant au plus 1600 caractères), mais l'écriture de cette table dans le tableau excel me créé une erreur mémoire à chaque fois.
Le plus rageant est que cette erreur ne se produit pas si les données ne viennent pas de la base mais d'une saisie manuelle bidon!
Voila, je crois que c'est la conclusion... et c'est bien dommage.
En fait, je dis juste que ça ne fonctionne pas chez moi...
La version ado est 2.8
La table contient peu données
(environ 70 lignes pour 30 colonnes dont un champ memo contenant au
plus 1600 caractères),
mais l'écriture de cette table dans le tableau excel me créé une
erreur mémoire à chaque fois.
Le plus rageant est que cette erreur ne se produit pas
si les données ne viennent pas de la base mais d'une saisie manuelle
bidon!
Voila, je crois que c'est la conclusion...
et c'est bien dommage.
En fait, je dis juste que ça ne fonctionne pas chez moi... La version ado est 2.8 La table contient peu données (environ 70 lignes pour 30 colonnes dont un champ memo contenant au plus 1600 caractères), mais l'écriture de cette table dans le tableau excel me créé une erreur mémoire à chaque fois.
Le plus rageant est que cette erreur ne se produit pas si les données ne viennent pas de la base mais d'une saisie manuelle bidon!
Voila, je crois que c'est la conclusion... et c'est bien dommage.
