y a t-il un risque d'erreur quand il y a trop de ligne
dans une table si oui environ combien, y a t-il un
maximun ?
Je sais je suis embetant ... lol
Merci
Manu
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
hm15
Bonjour Manu,
Raymond t'a donné la réponse. Même si c'est pour 2000 et plus, de mémoire, la plupart des valeurs sont les mêmes avec 97. La limite n'est pas en nombre d'enregistrements dans une table mais c'est la taille totale de la base qui compte (avec Access 97, c'est 1 Go). Si cela peut te rassurer, j'ai une base qui compte près de 100 000 contacts dans une table et ce n'est sans doute pas un record !
"manu" a écrit dans le message de news: 034001c3d565$69651030$
y a t-il un risque d'erreur quand il y a trop de ligne dans une table si oui environ combien, y a t-il un maximun ? Je sais je suis embetant ... lol Merci Manu
Bonjour Manu,
Raymond t'a donné la réponse.
Même si c'est pour 2000 et plus, de mémoire, la plupart des valeurs sont les
mêmes avec 97.
La limite n'est pas en nombre d'enregistrements dans une table mais c'est la
taille totale de la base qui compte (avec Access 97, c'est 1 Go).
Si cela peut te rassurer, j'ai une base qui compte près de 100 000 contacts
dans une table et ce n'est sans doute pas un record !
"manu" <anonymous@discussions.microsoft.com> a écrit dans le message de
news: 034001c3d565$69651030$a401280a@phx.gbl...
y a t-il un risque d'erreur quand il y a trop de ligne
dans une table si oui environ combien, y a t-il un
maximun ?
Je sais je suis embetant ... lol
Merci
Manu
Raymond t'a donné la réponse. Même si c'est pour 2000 et plus, de mémoire, la plupart des valeurs sont les mêmes avec 97. La limite n'est pas en nombre d'enregistrements dans une table mais c'est la taille totale de la base qui compte (avec Access 97, c'est 1 Go). Si cela peut te rassurer, j'ai une base qui compte près de 100 000 contacts dans une table et ce n'est sans doute pas un record !
"manu" a écrit dans le message de news: 034001c3d565$69651030$
y a t-il un risque d'erreur quand il y a trop de ligne dans une table si oui environ combien, y a t-il un maximun ? Je sais je suis embetant ... lol Merci Manu
phil
Salut, Pour que ta base reste rapide, il faut limiter le nombre d'enregistrements à 1000 ou 2000. Si tu as une table qui devrait, avec le temps, prendre des proportions beaucoup plus importantes, il serait préférable :
1) d'avoir une table CONTRAT(par exemple) qui restera vide, 2) de créer une nouvelle table chaque mois ou année (selon le nombre de contrats). Cette table s'appelera ContratAnneeMois et sera une copie de la table CONTRAT.
Ainsi, tu ne travaille que sur une table en même temps. Ta base sera peut-être plus volumineuse avec le temps, mais elle restera rapide. Par contre, c'est plus difficile à mettre en oeuvre...
-----Message d'origine----- "manu" a écrit dans le message de
news: 034001c3d565$69651030$
y a t-il un risque d'erreur quand il y a trop de ligne dans une table si oui environ combien, y a t-il un maximun ? Je sais je suis embetant ... lol Merci Manu
.
Salut,
Pour que ta base reste rapide, il faut limiter le nombre
d'enregistrements à 1000 ou 2000. Si tu as une table qui
devrait, avec le temps, prendre des proportions beaucoup
plus importantes, il serait préférable :
1) d'avoir une table CONTRAT(par exemple) qui restera vide,
2) de créer une nouvelle table chaque mois ou année
(selon le nombre de contrats). Cette table s'appelera
ContratAnneeMois et sera une copie de la table CONTRAT.
Ainsi, tu ne travaille que sur une table en même temps. Ta
base sera peut-être plus volumineuse avec le temps, mais
elle restera rapide.
Par contre, c'est plus difficile à mettre en oeuvre...
-----Message d'origine-----
"manu" <anonymous@discussions.microsoft.com> a écrit dans
le message de
news: 034001c3d565$69651030$a401280a@phx.gbl...
y a t-il un risque d'erreur quand il y a trop de ligne
dans une table si oui environ combien, y a t-il un
maximun ?
Je sais je suis embetant ... lol
Merci
Manu
Salut, Pour que ta base reste rapide, il faut limiter le nombre d'enregistrements à 1000 ou 2000. Si tu as une table qui devrait, avec le temps, prendre des proportions beaucoup plus importantes, il serait préférable :
1) d'avoir une table CONTRAT(par exemple) qui restera vide, 2) de créer une nouvelle table chaque mois ou année (selon le nombre de contrats). Cette table s'appelera ContratAnneeMois et sera une copie de la table CONTRAT.
Ainsi, tu ne travaille que sur une table en même temps. Ta base sera peut-être plus volumineuse avec le temps, mais elle restera rapide. Par contre, c'est plus difficile à mettre en oeuvre...
-----Message d'origine----- "manu" a écrit dans le message de
news: 034001c3d565$69651030$
y a t-il un risque d'erreur quand il y a trop de ligne dans une table si oui environ combien, y a t-il un maximun ? Je sais je suis embetant ... lol Merci Manu
.
Benoit Compoint [MS]
Bonjour,
Je suis d'accord avec la réponse d'Annette mais pas avec celle de Phil qui a "Pour que ta base reste rapide, il faut limiter le nombre d'enregistrements à 1000 ou 2000."
Access 97 peut gérer des tables de plusieurs milliers d'enregistrements sans dégrader sensiblement les performances. Pour reprendre l'exemple donné par Phil, la table CONTRAT pourrait contenir plusieurs dizaines de milliers d'enregistrements tout en conservant des performances acceptables à condition d'indexer judicieusement cette table. Au lieu de vider la table CONTRAT chaque mois ou chaque année, il suffirait d'indexer un champ "Date_Creation" dans cette table, et de créer une requête "Contrats du mois" ou une requête "Contrats de l'année" comportant un critère sur le champ "Date_Creation". On créerait ensuite la plupart des formulaires et des états en se basant sur ce genre de requêtes plutôt que directement sur la table CONTRAT.
Cependant la limitation à 1000 ou 2000 enregistrements suggérée par Phil peut s'avérer utile dans certains cas particuliers comme l'accès à une base de données MDB via une ligne à faible débit, par exemple l'accès à un serveur RAS via Numeris (et a fortiori via le réseau téléphonique commuté classique).
Benoît Compoint
"phil" wrote in message news:020a01c3d5bc$d7110290$ Salut, Pour que ta base reste rapide, il faut limiter le nombre d'enregistrements à 1000 ou 2000. Si tu as une table qui devrait, avec le temps, prendre des proportions beaucoup plus importantes, il serait préférable :
1) d'avoir une table CONTRAT(par exemple) qui restera vide, 2) de créer une nouvelle table chaque mois ou année (selon le nombre de contrats). Cette table s'appelera ContratAnneeMois et sera une copie de la table CONTRAT.
Ainsi, tu ne travaille que sur une table en même temps. Ta base sera peut-être plus volumineuse avec le temps, mais elle restera rapide. Par contre, c'est plus difficile à mettre en oeuvre...
-----Message d'origine----- "manu" a écrit dans le message de
news: 034001c3d565$69651030$
y a t-il un risque d'erreur quand il y a trop de ligne dans une table si oui environ combien, y a t-il un maximun ? Je sais je suis embetant ... lol Merci Manu
.
Bonjour,
Je suis d'accord avec la réponse d'Annette mais pas avec celle de Phil qui a
"Pour que ta base reste rapide, il faut limiter le nombre d'enregistrements
à 1000 ou 2000."
Access 97 peut gérer des tables de plusieurs milliers d'enregistrements sans
dégrader sensiblement les performances.
Pour reprendre l'exemple donné par Phil, la table CONTRAT pourrait contenir
plusieurs dizaines de milliers d'enregistrements tout en conservant des
performances acceptables à condition d'indexer judicieusement cette table.
Au lieu de vider la table CONTRAT chaque mois ou chaque année, il suffirait
d'indexer un champ "Date_Creation" dans cette table, et de créer une requête
"Contrats du mois" ou une requête "Contrats de l'année" comportant un
critère sur le champ "Date_Creation".
On créerait ensuite la plupart des formulaires et des états en se basant sur
ce genre de requêtes plutôt que directement sur la table CONTRAT.
Cependant la limitation à 1000 ou 2000 enregistrements suggérée par Phil
peut s'avérer utile dans certains cas particuliers comme l'accès à une base
de données MDB via une ligne à faible débit, par exemple l'accès à un
serveur RAS via Numeris (et a fortiori via le réseau téléphonique commuté
classique).
Benoît Compoint
"phil" <anonymous@discussions.microsoft.com> wrote in message
news:020a01c3d5bc$d7110290$a001280a@phx.gbl...
Salut,
Pour que ta base reste rapide, il faut limiter le nombre
d'enregistrements à 1000 ou 2000. Si tu as une table qui
devrait, avec le temps, prendre des proportions beaucoup
plus importantes, il serait préférable :
1) d'avoir une table CONTRAT(par exemple) qui restera vide,
2) de créer une nouvelle table chaque mois ou année
(selon le nombre de contrats). Cette table s'appelera
ContratAnneeMois et sera une copie de la table CONTRAT.
Ainsi, tu ne travaille que sur une table en même temps. Ta
base sera peut-être plus volumineuse avec le temps, mais
elle restera rapide.
Par contre, c'est plus difficile à mettre en oeuvre...
-----Message d'origine-----
"manu" <anonymous@discussions.microsoft.com> a écrit dans
le message de
news: 034001c3d565$69651030$a401280a@phx.gbl...
y a t-il un risque d'erreur quand il y a trop de ligne
dans une table si oui environ combien, y a t-il un
maximun ?
Je sais je suis embetant ... lol
Merci
Manu
Je suis d'accord avec la réponse d'Annette mais pas avec celle de Phil qui a "Pour que ta base reste rapide, il faut limiter le nombre d'enregistrements à 1000 ou 2000."
Access 97 peut gérer des tables de plusieurs milliers d'enregistrements sans dégrader sensiblement les performances. Pour reprendre l'exemple donné par Phil, la table CONTRAT pourrait contenir plusieurs dizaines de milliers d'enregistrements tout en conservant des performances acceptables à condition d'indexer judicieusement cette table. Au lieu de vider la table CONTRAT chaque mois ou chaque année, il suffirait d'indexer un champ "Date_Creation" dans cette table, et de créer une requête "Contrats du mois" ou une requête "Contrats de l'année" comportant un critère sur le champ "Date_Creation". On créerait ensuite la plupart des formulaires et des états en se basant sur ce genre de requêtes plutôt que directement sur la table CONTRAT.
Cependant la limitation à 1000 ou 2000 enregistrements suggérée par Phil peut s'avérer utile dans certains cas particuliers comme l'accès à une base de données MDB via une ligne à faible débit, par exemple l'accès à un serveur RAS via Numeris (et a fortiori via le réseau téléphonique commuté classique).
Benoît Compoint
"phil" wrote in message news:020a01c3d5bc$d7110290$ Salut, Pour que ta base reste rapide, il faut limiter le nombre d'enregistrements à 1000 ou 2000. Si tu as une table qui devrait, avec le temps, prendre des proportions beaucoup plus importantes, il serait préférable :
1) d'avoir une table CONTRAT(par exemple) qui restera vide, 2) de créer une nouvelle table chaque mois ou année (selon le nombre de contrats). Cette table s'appelera ContratAnneeMois et sera une copie de la table CONTRAT.
Ainsi, tu ne travaille que sur une table en même temps. Ta base sera peut-être plus volumineuse avec le temps, mais elle restera rapide. Par contre, c'est plus difficile à mettre en oeuvre...
-----Message d'origine----- "manu" a écrit dans le message de
news: 034001c3d565$69651030$
y a t-il un risque d'erreur quand il y a trop de ligne dans une table si oui environ combien, y a t-il un maximun ? Je sais je suis embetant ... lol Merci Manu
.
manu
merci à tous pour ces info bien utiles. Ps: j'ai une table avec plus de 150 000 lignes liée avec une autre base d'où ma question. Merci encore à tous Cordialement Manu
merci à tous pour ces info bien utiles.
Ps: j'ai une table avec plus de 150 000 lignes liée avec
une autre base d'où ma question.
Merci encore à tous
Cordialement
Manu
merci à tous pour ces info bien utiles. Ps: j'ai une table avec plus de 150 000 lignes liée avec une autre base d'où ma question. Merci encore à tous Cordialement Manu
