pourquoi ce message m'est il parvenu?
Ma proc=E9dure est elle vraiment trop longue?
C'est une proc qui copie des r=E9sultats dans des fichiers=20
excel pour des sauvegardes.
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
csl
Bonjour, j'ai déjà eu plusieurs fois ce message: il y a un nombre de lignes limite (je ne sais plus combien) et c'est vraiment ta procédure qui est trop longue il faut la couper en 2 ou la penser autrement
bon amusement
"seb" a écrit dans le message de news:070a01c3454c$4db11db0$ pourquoi ce message m'est il parvenu? Ma procédure est elle vraiment trop longue? C'est une proc qui copie des résultats dans des fichiers excel pour des sauvegardes.
Merci d'avance de m'aider
Bonjour,
j'ai déjà eu plusieurs fois ce message: il y a un nombre de lignes limite
(je ne sais plus combien)
et c'est vraiment ta procédure qui est trop longue
il faut la couper en 2
ou la penser autrement
bon amusement
"seb" <sebastanguy@aol.com> a écrit dans le message de
news:070a01c3454c$4db11db0$a001280a@phx.gbl...
pourquoi ce message m'est il parvenu?
Ma procédure est elle vraiment trop longue?
C'est une proc qui copie des résultats dans des fichiers
excel pour des sauvegardes.
Bonjour, j'ai déjà eu plusieurs fois ce message: il y a un nombre de lignes limite (je ne sais plus combien) et c'est vraiment ta procédure qui est trop longue il faut la couper en 2 ou la penser autrement
bon amusement
"seb" a écrit dans le message de news:070a01c3454c$4db11db0$ pourquoi ce message m'est il parvenu? Ma procédure est elle vraiment trop longue? C'est une proc qui copie des résultats dans des fichiers excel pour des sauvegardes.
Merci d'avance de m'aider
seb
Merci mais comment faire pour la couper car je créé un fichier excel au démarrage qui est utilisé dans toute la procédure?
-----Message d'origine----- Bonjour, j'ai déjà eu plusieurs fois ce message: il y a un nombre
de lignes limite
(je ne sais plus combien) et c'est vraiment ta procédure qui est trop longue il faut la couper en 2 ou la penser autrement
bon amusement
"seb" a écrit dans le message de news:070a01c3454c$4db11db0$ pourquoi ce message m'est il parvenu? Ma procédure est elle vraiment trop longue? C'est une proc qui copie des résultats dans des fichiers excel pour des sauvegardes.
Merci d'avance de m'aider
.
Merci
mais comment faire pour la couper car je créé un fichier
excel au démarrage qui est utilisé dans toute la procédure?
-----Message d'origine-----
Bonjour,
j'ai déjà eu plusieurs fois ce message: il y a un nombre
de lignes limite
(je ne sais plus combien)
et c'est vraiment ta procédure qui est trop longue
il faut la couper en 2
ou la penser autrement
bon amusement
"seb" <sebastanguy@aol.com> a écrit dans le message de
news:070a01c3454c$4db11db0$a001280a@phx.gbl...
pourquoi ce message m'est il parvenu?
Ma procédure est elle vraiment trop longue?
C'est une proc qui copie des résultats dans des fichiers
excel pour des sauvegardes.
Merci mais comment faire pour la couper car je créé un fichier excel au démarrage qui est utilisé dans toute la procédure?
-----Message d'origine----- Bonjour, j'ai déjà eu plusieurs fois ce message: il y a un nombre
de lignes limite
(je ne sais plus combien) et c'est vraiment ta procédure qui est trop longue il faut la couper en 2 ou la penser autrement
bon amusement
"seb" a écrit dans le message de news:070a01c3454c$4db11db0$ pourquoi ce message m'est il parvenu? Ma procédure est elle vraiment trop longue? C'est une proc qui copie des résultats dans des fichiers excel pour des sauvegardes.
Merci d'avance de m'aider
.
Zoury
Salut Seb! :O)
tiré de la MSDN :
"Procedures, Types, and Variables There is no limit on the number of procedures per module. Each procedure can contain up to 64K of code. If a procedure or module exceeds this limit, Visual Basic generates a compile-time error. If you encounter this error, you can avoid it by breaking extremely large procedures into several smaller procedures, or by moving module-level declarations into another module. Visual Basic uses tables to store the names of identifiers (variables, procedures, constants, and so on) in your code. Each table is limited to 64K."
je dois t'avouer que j'ai les jambes sciées!!! tu as réellement codé une procédure de plus de 64K?!?
Un concept ***fondamental*** en programmation, est de **séparer** les **différents traitements** en **différentes fonctions/subs**. Une fonction n'est *pas* un programme mais bien 1 traitement.
Si tu dois exécuter une requête, modifier des données et effectuant des calculs, stocker les modifications tout en mettant les registres et qui, finalement, re-sauvegarde les données dans la bd, tu devrais avoir un *minimum* de 5 à 8 fonctions différentes. Quelque chose comme ObtenirDonnees(), ModifierDonnees(), CalculerDonnees(), OuvrirFichier(), EcrireFichier(), FermerFichier(), EcrireRegistre(), SauvegardeDonnees().
"Procedures, Types, and Variables
There is no limit on the number of procedures per module. Each procedure can
contain up to 64K of code. If a procedure or module exceeds this limit, Visual
Basic generates a compile-time error. If you encounter this error, you can avoid
it by breaking extremely large procedures into several smaller procedures, or by
moving module-level declarations into another module.
Visual Basic uses tables to store the names of identifiers (variables,
procedures, constants, and so on) in your code. Each table is limited to 64K."
je dois t'avouer que j'ai les jambes sciées!!! tu as réellement codé une
procédure de plus de 64K?!?
Un concept ***fondamental*** en programmation, est de **séparer** les
**différents traitements** en **différentes fonctions/subs**. Une fonction n'est
*pas* un programme mais bien 1 traitement.
Si tu dois exécuter une requête, modifier des données et effectuant des calculs,
stocker les modifications tout en mettant les registres et qui, finalement,
re-sauvegarde les données dans la bd, tu devrais avoir un *minimum* de 5 à 8
fonctions différentes. Quelque chose comme ObtenirDonnees(), ModifierDonnees(),
CalculerDonnees(), OuvrirFichier(), EcrireFichier(), FermerFichier(),
EcrireRegistre(), SauvegardeDonnees().
"Procedures, Types, and Variables There is no limit on the number of procedures per module. Each procedure can contain up to 64K of code. If a procedure or module exceeds this limit, Visual Basic generates a compile-time error. If you encounter this error, you can avoid it by breaking extremely large procedures into several smaller procedures, or by moving module-level declarations into another module. Visual Basic uses tables to store the names of identifiers (variables, procedures, constants, and so on) in your code. Each table is limited to 64K."
je dois t'avouer que j'ai les jambes sciées!!! tu as réellement codé une procédure de plus de 64K?!?
Un concept ***fondamental*** en programmation, est de **séparer** les **différents traitements** en **différentes fonctions/subs**. Une fonction n'est *pas* un programme mais bien 1 traitement.
Si tu dois exécuter une requête, modifier des données et effectuant des calculs, stocker les modifications tout en mettant les registres et qui, finalement, re-sauvegarde les données dans la bd, tu devrais avoir un *minimum* de 5 à 8 fonctions différentes. Quelque chose comme ObtenirDonnees(), ModifierDonnees(), CalculerDonnees(), OuvrirFichier(), EcrireFichier(), FermerFichier(), EcrireRegistre(), SauvegardeDonnees().
: j'ai déjà eu plusieurs fois ce message Aaaaaaahhhhhhhh!!
: il y a un nombre de lignes limite (je ne sais plus combien) 64 k...
: il faut la couper en 2 ... je dirais en *beaucoup* plus que ça.... Les limitations de VB sont tellement grande, qu'il est même impensable d'arriver un tantinet proche de les atteindre. Si tel est le cas, je ne me ferais même pas payer un million pour la débugguer..
: ou la penser autrement hhaaa!! beaucoup mieux ;O)
: j'ai déjà eu plusieurs fois ce message
Aaaaaaahhhhhhhh!!
: il y a un nombre de lignes limite (je ne sais plus combien)
64 k...
: il faut la couper en 2
... je dirais en *beaucoup* plus que ça.... Les limitations de VB sont tellement
grande, qu'il est même impensable d'arriver un tantinet proche de les atteindre.
Si tel est le cas, je ne me ferais même pas payer un million pour la débugguer..
: ou la penser autrement
hhaaa!! beaucoup mieux ;O)
: j'ai déjà eu plusieurs fois ce message Aaaaaaahhhhhhhh!!
: il y a un nombre de lignes limite (je ne sais plus combien) 64 k...
: il faut la couper en 2 ... je dirais en *beaucoup* plus que ça.... Les limitations de VB sont tellement grande, qu'il est même impensable d'arriver un tantinet proche de les atteindre. Si tel est le cas, je ne me ferais même pas payer un million pour la débugguer..
: ou la penser autrement hhaaa!! beaucoup mieux ;O)
Merci de ta remarque et je suis entièrement d'accord avec toi sur le principe de la programmation. Cependant cette procédure qui amène des données vers un et un seul fichier excel ne peut pas vraiment être coupée car elle utilise ce fichier tout au long de son déroulement.
Voila mon problème.
-----Message d'origine----- Salut Seb! :O)
tiré de la MSDN :
"Procedures, Types, and Variables There is no limit on the number of procedures per module. Each procedure can contain up to 64K of code. If a procedure or module exceeds this limit, Visual Basic generates a compile-time error. If you encounter this error, you can avoid it by breaking extremely large procedures into several smaller procedures, or by moving module-level declarations into another module. Visual Basic uses tables to store the names of identifiers (variables, procedures, constants, and so on) in your code. Each table is limited to 64K."
je dois t'avouer que j'ai les jambes sciées!!! tu as réellement codé une procédure de plus de 64K?!?
Un concept ***fondamental*** en programmation, est de **séparer** les **différents traitements** en **différentes
fonctions/subs**. Une fonction n'est
*pas* un programme mais bien 1 traitement.
Si tu dois exécuter une requête, modifier des données et effectuant des calculs, stocker les modifications tout en mettant les registres et qui, finalement, re-sauvegarde les données dans la bd, tu devrais avoir un *minimum* de 5 à 8 fonctions différentes. Quelque chose comme ObtenirDonnees (), ModifierDonnees(), CalculerDonnees(), OuvrirFichier(), EcrireFichier(), FermerFichier(), EcrireRegistre(), SauvegardeDonnees().
Merci de ta remarque et je suis entièrement d'accord avec
toi sur le principe de la programmation.
Cependant cette procédure qui amène des données vers un et
un seul fichier excel ne peut pas vraiment être coupée car
elle utilise ce fichier tout au long de son déroulement.
Voila mon problème.
-----Message d'origine-----
Salut Seb! :O)
tiré de la MSDN :
"Procedures, Types, and Variables
There is no limit on the number of procedures per module. Each
procedure can contain up to 64K of code. If a procedure or module
exceeds this limit, Visual Basic generates a compile-time error. If
you encounter this error, you can avoid it by breaking extremely
large procedures into several smaller procedures, or by moving
module-level declarations into another module. Visual Basic uses
tables to store the names of identifiers (variables, procedures,
constants, and so on) in your code. Each table is limited to 64K."
je dois t'avouer que j'ai les jambes sciées!!! tu as réellement codé
une procédure de plus de 64K?!?
Un concept ***fondamental*** en programmation, est de **séparer** les
**différents traitements** en **différentes
fonctions/subs**. Une fonction n'est
*pas* un programme mais bien 1 traitement.
Si tu dois exécuter une requête, modifier des données et effectuant
des calculs, stocker les modifications tout en mettant les registres
et qui, finalement, re-sauvegarde les données dans la bd, tu devrais
avoir un *minimum* de 5 à 8 fonctions différentes. Quelque chose
comme ObtenirDonnees (), ModifierDonnees(), CalculerDonnees(),
OuvrirFichier(), EcrireFichier(), FermerFichier(), EcrireRegistre(),
SauvegardeDonnees().
Merci de ta remarque et je suis entièrement d'accord avec toi sur le principe de la programmation. Cependant cette procédure qui amène des données vers un et un seul fichier excel ne peut pas vraiment être coupée car elle utilise ce fichier tout au long de son déroulement.
Voila mon problème.
-----Message d'origine----- Salut Seb! :O)
tiré de la MSDN :
"Procedures, Types, and Variables There is no limit on the number of procedures per module. Each procedure can contain up to 64K of code. If a procedure or module exceeds this limit, Visual Basic generates a compile-time error. If you encounter this error, you can avoid it by breaking extremely large procedures into several smaller procedures, or by moving module-level declarations into another module. Visual Basic uses tables to store the names of identifiers (variables, procedures, constants, and so on) in your code. Each table is limited to 64K."
je dois t'avouer que j'ai les jambes sciées!!! tu as réellement codé une procédure de plus de 64K?!?
Un concept ***fondamental*** en programmation, est de **séparer** les **différents traitements** en **différentes
fonctions/subs**. Une fonction n'est
*pas* un programme mais bien 1 traitement.
Si tu dois exécuter une requête, modifier des données et effectuant des calculs, stocker les modifications tout en mettant les registres et qui, finalement, re-sauvegarde les données dans la bd, tu devrais avoir un *minimum* de 5 à 8 fonctions différentes. Quelque chose comme ObtenirDonnees (), ModifierDonnees(), CalculerDonnees(), OuvrirFichier(), EcrireFichier(), FermerFichier(), EcrireRegistre(), SauvegardeDonnees().
Merci de ta remarque et je suis entièrement d'accord avec toi sur le principe de la programmation. Cependant cette procédure qui amène des données vers un et un seul fichier excel ne peut pas vraiment être coupée car elle utilise ce fichier tout au long de son déroulement.
Voila mon problème.
-----Message d'origine----- Salut Seb! :O)
tiré de la MSDN :
"Procedures, Types, and Variables There is no limit on the number of procedures per module.
Each procedure can
contain up to 64K of code. If a procedure or module
exceeds this limit, Visual
Basic generates a compile-time error. If you encounter
this error, you can avoid
it by breaking extremely large procedures into several
smaller procedures, or by
moving module-level declarations into another module. Visual Basic uses tables to store the names of
identifiers (variables,
procedures, constants, and so on) in your code. Each
table is limited to 64K."
je dois t'avouer que j'ai les jambes sciées!!! tu as
réellement codé une
procédure de plus de 64K?!?
Un concept ***fondamental*** en programmation, est de
**séparer** les
**différents traitements** en **différentes
fonctions/subs**. Une fonction n'est
*pas* un programme mais bien 1 traitement.
Si tu dois exécuter une requête, modifier des données et
effectuant des calculs,
stocker les modifications tout en mettant les registres
et qui, finalement,
re-sauvegarde les données dans la bd, tu devrais avoir un
*minimum* de 5 à 8
fonctions différentes. Quelque chose comme ObtenirDonnees
Merci de ta remarque et je suis entièrement d'accord avec
toi sur le principe de la programmation.
Cependant cette procédure qui amène des données vers un et
un seul fichier excel ne peut pas vraiment être coupée car
elle utilise ce fichier tout au long de son déroulement.
Voila mon problème.
-----Message d'origine-----
Salut Seb! :O)
tiré de la MSDN :
"Procedures, Types, and Variables
There is no limit on the number of procedures per module.
Each procedure can
contain up to 64K of code. If a procedure or module
exceeds this limit, Visual
Basic generates a compile-time error. If you encounter
this error, you can avoid
it by breaking extremely large procedures into several
smaller procedures, or by
moving module-level declarations into another module.
Visual Basic uses tables to store the names of
identifiers (variables,
procedures, constants, and so on) in your code. Each
table is limited to 64K."
je dois t'avouer que j'ai les jambes sciées!!! tu as
réellement codé une
procédure de plus de 64K?!?
Un concept ***fondamental*** en programmation, est de
**séparer** les
**différents traitements** en **différentes
fonctions/subs**. Une fonction n'est
*pas* un programme mais bien 1 traitement.
Si tu dois exécuter une requête, modifier des données et
effectuant des calculs,
stocker les modifications tout en mettant les registres
et qui, finalement,
re-sauvegarde les données dans la bd, tu devrais avoir un
*minimum* de 5 à 8
fonctions différentes. Quelque chose comme ObtenirDonnees
Merci de ta remarque et je suis entièrement d'accord avec toi sur le principe de la programmation. Cependant cette procédure qui amène des données vers un et un seul fichier excel ne peut pas vraiment être coupée car elle utilise ce fichier tout au long de son déroulement.
Voila mon problème.
-----Message d'origine----- Salut Seb! :O)
tiré de la MSDN :
"Procedures, Types, and Variables There is no limit on the number of procedures per module.
Each procedure can
contain up to 64K of code. If a procedure or module
exceeds this limit, Visual
Basic generates a compile-time error. If you encounter
this error, you can avoid
it by breaking extremely large procedures into several
smaller procedures, or by
moving module-level declarations into another module. Visual Basic uses tables to store the names of
identifiers (variables,
procedures, constants, and so on) in your code. Each
table is limited to 64K."
je dois t'avouer que j'ai les jambes sciées!!! tu as
réellement codé une
procédure de plus de 64K?!?
Un concept ***fondamental*** en programmation, est de
**séparer** les
**différents traitements** en **différentes
fonctions/subs**. Une fonction n'est
*pas* un programme mais bien 1 traitement.
Si tu dois exécuter une requête, modifier des données et
effectuant des calculs,
stocker les modifications tout en mettant les registres
et qui, finalement,
re-sauvegarde les données dans la bd, tu devrais avoir un
*minimum* de 5 à 8
fonctions différentes. Quelque chose comme ObtenirDonnees
