Au maximum, combien d'enregistrements peut traiter Access 2000?
Au maximum, combien d'enregistrements peut traiter Access 2000?
Au maximum, combien d'enregistrements peut traiter Access 2000?
Au maximum, combien d'enregistrements peut traiter Access 2000?
Au maximum, combien d'enregistrements peut traiter Access 2000?
Au maximum, combien d'enregistrements peut traiter Access 2000?
Bonjour.
avec access on ne raisonne pas enregistrements mais taille globale de
base.
la taille globale sur les versions antérieurs à 2000 est de 1Go et de 2 Go
pour les versions 2000 et +
pour raisonner à l'absurde, une base de 1 formulaire + 1 état + une table
contenant des enregistrements de 100 caractères peut contenir environ
20.000.000 d'enregistrements sans compter toutes les tables attachées dans
des bases externes qu'on peut déclarer.
--
@+
Raymond Access MVP
http://access.seneque.free.fr/
http://access.vba.free.fr/
http://access2003.free.fr/
http://users.skynet.be/mpfa/ pour débuter sur le forum
Bonjour.
avec access on ne raisonne pas enregistrements mais taille globale de
base.
la taille globale sur les versions antérieurs à 2000 est de 1Go et de 2 Go
pour les versions 2000 et +
pour raisonner à l'absurde, une base de 1 formulaire + 1 état + une table
contenant des enregistrements de 100 caractères peut contenir environ
20.000.000 d'enregistrements sans compter toutes les tables attachées dans
des bases externes qu'on peut déclarer.
--
@+
Raymond Access MVP
http://access.seneque.free.fr/
http://access.vba.free.fr/
http://access2003.free.fr/
http://users.skynet.be/mpfa/ pour débuter sur le forum
Bonjour.
avec access on ne raisonne pas enregistrements mais taille globale de
base.
la taille globale sur les versions antérieurs à 2000 est de 1Go et de 2 Go
pour les versions 2000 et +
pour raisonner à l'absurde, une base de 1 formulaire + 1 état + une table
contenant des enregistrements de 100 caractères peut contenir environ
20.000.000 d'enregistrements sans compter toutes les tables attachées dans
des bases externes qu'on peut déclarer.
--
@+
Raymond Access MVP
http://access.seneque.free.fr/
http://access.vba.free.fr/
http://access2003.free.fr/
http://users.skynet.be/mpfa/ pour débuter sur le forum
Bonjour Raymond!
Juste pour pinailler sur des details, dans ton exemple, on ne poura
stocker
que 10.000.000 d'enregistrements. Par defaut, depuis Access 2000, le
stockage se fait en Unicode, qui prend deux octets par charactere, d'ou
l'augmentation de 1 a 2 GB de la limite, et le rallentissement notable
entre
Access 97 et 2000.
De plus, je ne pense pas que l'on parvienne a "briser" la limite des 2GB
en
utilisant des tables attachees. La limite des 2GB se situe au niveau de
Jet,
on ne pourra donc pas "re-assembler" un recordset plus gros que ca. Ceci
dit, j'attend une confirmation (ou infirmation) empirique de cet enonce.
Bonne journee Raymond.
--
Daniel :-)
Bonjour Raymond!
Juste pour pinailler sur des details, dans ton exemple, on ne poura
stocker
que 10.000.000 d'enregistrements. Par defaut, depuis Access 2000, le
stockage se fait en Unicode, qui prend deux octets par charactere, d'ou
l'augmentation de 1 a 2 GB de la limite, et le rallentissement notable
entre
Access 97 et 2000.
De plus, je ne pense pas que l'on parvienne a "briser" la limite des 2GB
en
utilisant des tables attachees. La limite des 2GB se situe au niveau de
Jet,
on ne pourra donc pas "re-assembler" un recordset plus gros que ca. Ceci
dit, j'attend une confirmation (ou infirmation) empirique de cet enonce.
Bonne journee Raymond.
--
Daniel :-)
Bonjour Raymond!
Juste pour pinailler sur des details, dans ton exemple, on ne poura
stocker
que 10.000.000 d'enregistrements. Par defaut, depuis Access 2000, le
stockage se fait en Unicode, qui prend deux octets par charactere, d'ou
l'augmentation de 1 a 2 GB de la limite, et le rallentissement notable
entre
Access 97 et 2000.
De plus, je ne pense pas que l'on parvienne a "briser" la limite des 2GB
en
utilisant des tables attachees. La limite des 2GB se situe au niveau de
Jet,
on ne pourra donc pas "re-assembler" un recordset plus gros que ca. Ceci
dit, j'attend une confirmation (ou infirmation) empirique de cet enonce.
Bonne journee Raymond.
--
Daniel :-)
-----Message d'origine-----
Bonjour,
Eh bien moi, j'ai trouvé la démonstration de Daniel tout
à fait
intéressante, et pas pinaillante du tout :-)
Reste à trouver des béta testeurs ...
--
a+
Arnaud
--------------------------------------------------
Conseils d'utilisation : http://users.skynet.be/mpfa/
Site Perso : http://memoaccess.free.fr
/Réponses souhaitées sur ce forum, merci/
--------------------------------------------------
Raymond [mvp] wrote:
| Bonjour Daniel.
|
| Bien sûr tu as raison, mais tu pinailles car j'ai dit :
pour raisonner
| jusqu'à l'absurde; pour tout simplement dire que les
propros sont
| hors de propos et que ce n'est pas le bon chemin.
| Bonne journée.
|
| "Daniel Carollo"
tech.com> a écrit
| dans le message de
news:
|| Bonjour Raymond!
||
|| Juste pour pinailler sur des details, dans ton
exemple, on ne poura
|| stocker que 10.000.000 d'enregistrements. Par defaut,
depuis Access
|| 2000, le stockage se fait en Unicode, qui prend deux
octets par
|| charactere, d'ou l'augmentation de 1 a 2 GB de la
limite, et le
|| rallentissement notable entre Access 97 et 2000.
||
|| De plus, je ne pense pas que l'on parvienne a "briser"
la limite des
|| 2GB en utilisant des tables attachees. La limite des
2GB se situe au
|| niveau de Jet, on ne pourra donc pas "re-assembler" un
recordset
|| plus gros que ca. Ceci dit, j'attend une confirmation
(ou
|| infirmation) empirique de cet enonce.
||
|| Bonne journee Raymond.
||
|| --
|| Daniel :-)
.
-----Message d'origine-----
Bonjour,
Eh bien moi, j'ai trouvé la démonstration de Daniel tout
à fait
intéressante, et pas pinaillante du tout :-)
Reste à trouver des béta testeurs ...
--
a+
Arnaud
--------------------------------------------------
Conseils d'utilisation : http://users.skynet.be/mpfa/
Site Perso : http://memoaccess.free.fr
/Réponses souhaitées sur ce forum, merci/
--------------------------------------------------
Raymond [mvp] wrote:
| Bonjour Daniel.
|
| Bien sûr tu as raison, mais tu pinailles car j'ai dit :
pour raisonner
| jusqu'à l'absurde; pour tout simplement dire que les
propros sont
| hors de propos et que ce n'est pas le bon chemin.
| Bonne journée.
|
| "Daniel Carollo" <danielc@NO_SPAM_PLEASE.computing-
tech.com> a écrit
| dans le message de
news:uYnUmS6REHA.3716@TK2MSFTNGP09.phx.gbl...
|| Bonjour Raymond!
||
|| Juste pour pinailler sur des details, dans ton
exemple, on ne poura
|| stocker que 10.000.000 d'enregistrements. Par defaut,
depuis Access
|| 2000, le stockage se fait en Unicode, qui prend deux
octets par
|| charactere, d'ou l'augmentation de 1 a 2 GB de la
limite, et le
|| rallentissement notable entre Access 97 et 2000.
||
|| De plus, je ne pense pas que l'on parvienne a "briser"
la limite des
|| 2GB en utilisant des tables attachees. La limite des
2GB se situe au
|| niveau de Jet, on ne pourra donc pas "re-assembler" un
recordset
|| plus gros que ca. Ceci dit, j'attend une confirmation
(ou
|| infirmation) empirique de cet enonce.
||
|| Bonne journee Raymond.
||
|| --
|| Daniel :-)
.
-----Message d'origine-----
Bonjour,
Eh bien moi, j'ai trouvé la démonstration de Daniel tout
à fait
intéressante, et pas pinaillante du tout :-)
Reste à trouver des béta testeurs ...
--
a+
Arnaud
--------------------------------------------------
Conseils d'utilisation : http://users.skynet.be/mpfa/
Site Perso : http://memoaccess.free.fr
/Réponses souhaitées sur ce forum, merci/
--------------------------------------------------
Raymond [mvp] wrote:
| Bonjour Daniel.
|
| Bien sûr tu as raison, mais tu pinailles car j'ai dit :
pour raisonner
| jusqu'à l'absurde; pour tout simplement dire que les
propros sont
| hors de propos et que ce n'est pas le bon chemin.
| Bonne journée.
|
| "Daniel Carollo"
tech.com> a écrit
| dans le message de
news:
|| Bonjour Raymond!
||
|| Juste pour pinailler sur des details, dans ton
exemple, on ne poura
|| stocker que 10.000.000 d'enregistrements. Par defaut,
depuis Access
|| 2000, le stockage se fait en Unicode, qui prend deux
octets par
|| charactere, d'ou l'augmentation de 1 a 2 GB de la
limite, et le
|| rallentissement notable entre Access 97 et 2000.
||
|| De plus, je ne pense pas que l'on parvienne a "briser"
la limite des
|| 2GB en utilisant des tables attachees. La limite des
2GB se situe au
|| niveau de Jet, on ne pourra donc pas "re-assembler" un
recordset
|| plus gros que ca. Ceci dit, j'attend une confirmation
(ou
|| infirmation) empirique de cet enonce.
||
|| Bonne journee Raymond.
||
|| --
|| Daniel :-)
.
-----Message d'origine-----
Bonjour michel.
bon exemple d'utilisation.
tout en tutoyant les limites quand même.
Tant que tu es présent, ok, le jour que tu n'es plus là,
faudra craindre le
pire.
--
@+
Raymond Access MVP
http://access.seneque.free.fr/
http://access.vba.free.fr/
http://access2003.free.fr/
http://users.skynet.be/mpfa/ pour débuter sur le forum
"Michel Gesnot" a
écrit dans le
message de news:1723701c448a7$5a7ce790$
Bonjour aux métainformaticiens !
Une petite contribution.
Nous avons une application en développement qui nous pose
des problèmes de "volume". J'en avais déjà parlé ici.
La solution actuelle est la suivante :
une bd avec les formes, états, requêtes et modules, ainsi
que les fichiers de référence (environ 200 MB)
une bd avec une seule table pour chaque lot de
statistiques annuelles, soit 20-22 millions de lignes dans
une seule table et une taille de 1,8-1,9 GB.
Les 5 bd annuelles (1998-2002) sont
- d'une part attachées pour utilisation individuelle
- d'autre part, utilisées pour les recherches générales
via une requête selection sql union .
Donc, disons une table virtuelle de 100 millions de lignes
et de 9,5 GB.
Et nous ajouterons 2003 dans les semaines qui viennent.
C'est pas un foudre de guerre, mais pour le moment cela
tourne sur un vieux PC avec, en sus, du mapping de
disques.
Donc, je pense que les temps devraient être tout à fait
corrects en utilisation individuelle sur un PC actuel.
Voilà un élément de réponse.
Bonnes réflexions métainformaticiennes.
M. Gesnot
.
-----Message d'origine-----
Bonjour michel.
bon exemple d'utilisation.
tout en tutoyant les limites quand même.
Tant que tu es présent, ok, le jour que tu n'es plus là,
faudra craindre le
pire.
--
@+
Raymond Access MVP
http://access.seneque.free.fr/
http://access.vba.free.fr/
http://access2003.free.fr/
http://users.skynet.be/mpfa/ pour débuter sur le forum
"Michel Gesnot" <anonymous@discussions.microsoft.com> a
écrit dans le
message de news:1723701c448a7$5a7ce790$a501280a@phx.gbl...
Bonjour aux métainformaticiens !
Une petite contribution.
Nous avons une application en développement qui nous pose
des problèmes de "volume". J'en avais déjà parlé ici.
La solution actuelle est la suivante :
une bd avec les formes, états, requêtes et modules, ainsi
que les fichiers de référence (environ 200 MB)
une bd avec une seule table pour chaque lot de
statistiques annuelles, soit 20-22 millions de lignes dans
une seule table et une taille de 1,8-1,9 GB.
Les 5 bd annuelles (1998-2002) sont
- d'une part attachées pour utilisation individuelle
- d'autre part, utilisées pour les recherches générales
via une requête selection sql union .
Donc, disons une table virtuelle de 100 millions de lignes
et de 9,5 GB.
Et nous ajouterons 2003 dans les semaines qui viennent.
C'est pas un foudre de guerre, mais pour le moment cela
tourne sur un vieux PC avec, en sus, du mapping de
disques.
Donc, je pense que les temps devraient être tout à fait
corrects en utilisation individuelle sur un PC actuel.
Voilà un élément de réponse.
Bonnes réflexions métainformaticiennes.
M. Gesnot
.
-----Message d'origine-----
Bonjour michel.
bon exemple d'utilisation.
tout en tutoyant les limites quand même.
Tant que tu es présent, ok, le jour que tu n'es plus là,
faudra craindre le
pire.
--
@+
Raymond Access MVP
http://access.seneque.free.fr/
http://access.vba.free.fr/
http://access2003.free.fr/
http://users.skynet.be/mpfa/ pour débuter sur le forum
"Michel Gesnot" a
écrit dans le
message de news:1723701c448a7$5a7ce790$
Bonjour aux métainformaticiens !
Une petite contribution.
Nous avons une application en développement qui nous pose
des problèmes de "volume". J'en avais déjà parlé ici.
La solution actuelle est la suivante :
une bd avec les formes, états, requêtes et modules, ainsi
que les fichiers de référence (environ 200 MB)
une bd avec une seule table pour chaque lot de
statistiques annuelles, soit 20-22 millions de lignes dans
une seule table et une taille de 1,8-1,9 GB.
Les 5 bd annuelles (1998-2002) sont
- d'une part attachées pour utilisation individuelle
- d'autre part, utilisées pour les recherches générales
via une requête selection sql union .
Donc, disons une table virtuelle de 100 millions de lignes
et de 9,5 GB.
Et nous ajouterons 2003 dans les semaines qui viennent.
C'est pas un foudre de guerre, mais pour le moment cela
tourne sur un vieux PC avec, en sus, du mapping de
disques.
Donc, je pense que les temps devraient être tout à fait
corrects en utilisation individuelle sur un PC actuel.
Voilà un élément de réponse.
Bonnes réflexions métainformaticiennes.
M. Gesnot
.