Il semble que 2 Go soit la taille maximale d'une base ACCESS 2000 :
au-dessus, elle explose !
En approchant des 2 Go (1,8 Go), le compactage est problématique.
Y-a-t-il un moyen (patch ou autres) de dépasser cette limite de 2 Go (même
après compactage) ?
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
Bonjour,
1.8 Go après compactage ???????
Je ne sais pas ce tui stockes, mais si ce sont des images, il vaut mieux les laisser en dehors de la base Si c'est du texte, tu peux mettre certaines tables dans une base et d'autres dans une autre base, mais tu perdras l'intégrité référentielle (liaisons)
Mais bon 1.8Go de texte, c'est plus que toutes les encyclopédies universalis réunies !!
a+ -- Arnaud --------------------------------------------- infos, conseils et liens : http://www.mpfa.info ---------------------------------------------
"Richard_35" a écrit dans le message de news:
Bonjour,
Il semble que 2 Go soit la taille maximale d'une base ACCESS 2000 : au-dessus, elle explose ! En approchant des 2 Go (1,8 Go), le compactage est problématique. Y-a-t-il un moyen (patch ou autres) de dépasser cette limite de 2 Go (même après compactage) ?
Merci d'avance pour votre aide.
Richard.
Bonjour,
1.8 Go après compactage ???????
Je ne sais pas ce tui stockes, mais si ce sont des images, il vaut mieux les laisser en dehors de la base
Si c'est du texte, tu peux mettre certaines tables dans une base et d'autres dans une autre base, mais
tu perdras l'intégrité référentielle (liaisons)
Mais bon 1.8Go de texte, c'est plus que toutes les encyclopédies universalis réunies !!
a+
--
Arnaud
---------------------------------------------
infos, conseils et liens : http://www.mpfa.info
---------------------------------------------
"Richard_35" <richard.cohen@laposte.net> a écrit dans le message de news: uCKiTvXZGHA.4688@TK2MSFTNGP04.phx.gbl...
Bonjour,
Il semble que 2 Go soit la taille maximale d'une base ACCESS 2000 : au-dessus, elle explose !
En approchant des 2 Go (1,8 Go), le compactage est problématique.
Y-a-t-il un moyen (patch ou autres) de dépasser cette limite de 2 Go (même après compactage) ?
Je ne sais pas ce tui stockes, mais si ce sont des images, il vaut mieux les laisser en dehors de la base Si c'est du texte, tu peux mettre certaines tables dans une base et d'autres dans une autre base, mais tu perdras l'intégrité référentielle (liaisons)
Mais bon 1.8Go de texte, c'est plus que toutes les encyclopédies universalis réunies !!
a+ -- Arnaud --------------------------------------------- infos, conseils et liens : http://www.mpfa.info ---------------------------------------------
"Richard_35" a écrit dans le message de news:
Bonjour,
Il semble que 2 Go soit la taille maximale d'une base ACCESS 2000 : au-dessus, elle explose ! En approchant des 2 Go (1,8 Go), le compactage est problématique. Y-a-t-il un moyen (patch ou autres) de dépasser cette limite de 2 Go (même après compactage) ?
Merci d'avance pour votre aide.
Richard.
Richard_35
Il s'agit d'un .mdb qui importe des tables d'un gros système distant. Le .mdb comporte plusieurs tables : le .mdb > 1,8 Go. Y-a-t-il une solution sans scinder le .mdb ? Merci.
<Anor> a écrit dans le message de news:
Bonjour,
1.8 Go après compactage ???????
Je ne sais pas ce tui stockes, mais si ce sont des images, il vaut mieux les laisser en dehors de la base Si c'est du texte, tu peux mettre certaines tables dans une base et d'autres dans une autre base, mais tu perdras l'intégrité référentielle (liaisons)
Mais bon 1.8Go de texte, c'est plus que toutes les encyclopédies universalis réunies !!
a+ -- Arnaud --------------------------------------------- infos, conseils et liens : http://www.mpfa.info ---------------------------------------------
"Richard_35" a écrit dans le message de news:
Bonjour,
Il semble que 2 Go soit la taille maximale d'une base ACCESS 2000 : au-dessus, elle explose ! En approchant des 2 Go (1,8 Go), le compactage est problématique. Y-a-t-il un moyen (patch ou autres) de dépasser cette limite de 2 Go (même après compactage) ?
Merci d'avance pour votre aide.
Richard.
Il s'agit d'un .mdb qui importe des tables d'un gros système distant.
Le .mdb comporte plusieurs tables : le .mdb > 1,8 Go.
Y-a-t-il une solution sans scinder le .mdb ?
Merci.
<Anor> a écrit dans le message de news:
O1LWg3XZGHA.3652@TK2MSFTNGP03.phx.gbl...
Bonjour,
1.8 Go après compactage ???????
Je ne sais pas ce tui stockes, mais si ce sont des images, il vaut mieux
les laisser en dehors de la base
Si c'est du texte, tu peux mettre certaines tables dans une base et
d'autres dans une autre base, mais
tu perdras l'intégrité référentielle (liaisons)
Mais bon 1.8Go de texte, c'est plus que toutes les encyclopédies
universalis réunies !!
a+
--
Arnaud
---------------------------------------------
infos, conseils et liens : http://www.mpfa.info
---------------------------------------------
"Richard_35" <richard.cohen@laposte.net> a écrit dans le message de news:
uCKiTvXZGHA.4688@TK2MSFTNGP04.phx.gbl...
Bonjour,
Il semble que 2 Go soit la taille maximale d'une base ACCESS 2000 :
au-dessus, elle explose !
En approchant des 2 Go (1,8 Go), le compactage est problématique.
Y-a-t-il un moyen (patch ou autres) de dépasser cette limite de 2 Go
(même après compactage) ?
Il s'agit d'un .mdb qui importe des tables d'un gros système distant. Le .mdb comporte plusieurs tables : le .mdb > 1,8 Go. Y-a-t-il une solution sans scinder le .mdb ? Merci.
<Anor> a écrit dans le message de news:
Bonjour,
1.8 Go après compactage ???????
Je ne sais pas ce tui stockes, mais si ce sont des images, il vaut mieux les laisser en dehors de la base Si c'est du texte, tu peux mettre certaines tables dans une base et d'autres dans une autre base, mais tu perdras l'intégrité référentielle (liaisons)
Mais bon 1.8Go de texte, c'est plus que toutes les encyclopédies universalis réunies !!
a+ -- Arnaud --------------------------------------------- infos, conseils et liens : http://www.mpfa.info ---------------------------------------------
"Richard_35" a écrit dans le message de news:
Bonjour,
Il semble que 2 Go soit la taille maximale d'une base ACCESS 2000 : au-dessus, elle explose ! En approchant des 2 Go (1,8 Go), le compactage est problématique. Y-a-t-il un moyen (patch ou autres) de dépasser cette limite de 2 Go (même après compactage) ?
Merci d'avance pour votre aide.
Richard.
Non malheureusement pour toi, pas de solution, à part lorgner du côté de SQL server.. a+ -- Arnaud --------------------------------------------- infos, conseils et liens : http://www.mpfa.info ---------------------------------------------
"Richard_35" a écrit dans le message de news:
Il s'agit d'un .mdb qui importe des tables d'un gros système distant. Le .mdb comporte plusieurs tables : le .mdb > 1,8 Go. Y-a-t-il une solution sans scinder le .mdb ? Merci.
<Anor> a écrit dans le message de news:
Bonjour,
1.8 Go après compactage ???????
Je ne sais pas ce tui stockes, mais si ce sont des images, il vaut mieux les laisser en dehors de la base Si c'est du texte, tu peux mettre certaines tables dans une base et d'autres dans une autre base, mais tu perdras l'intégrité référentielle (liaisons)
Mais bon 1.8Go de texte, c'est plus que toutes les encyclopédies universalis réunies !!
a+ -- Arnaud --------------------------------------------- infos, conseils et liens : http://www.mpfa.info ---------------------------------------------
"Richard_35" a écrit dans le message de news:
Bonjour,
Il semble que 2 Go soit la taille maximale d'une base ACCESS 2000 : au-dessus, elle explose ! En approchant des 2 Go (1,8 Go), le compactage est problématique. Y-a-t-il un moyen (patch ou autres) de dépasser cette limite de 2 Go (même après compactage) ?
Merci d'avance pour votre aide.
Richard.
Non malheureusement pour toi, pas de solution, à part lorgner du côté de SQL server..
a+
--
Arnaud
---------------------------------------------
infos, conseils et liens : http://www.mpfa.info
---------------------------------------------
"Richard_35" <richard.cohen@laposte.net> a écrit dans le message de news: utio6CYZGHA.3532@TK2MSFTNGP05.phx.gbl...
Il s'agit d'un .mdb qui importe des tables d'un gros système distant.
Le .mdb comporte plusieurs tables : le .mdb > 1,8 Go.
Y-a-t-il une solution sans scinder le .mdb ?
Merci.
<Anor> a écrit dans le message de news: O1LWg3XZGHA.3652@TK2MSFTNGP03.phx.gbl...
Bonjour,
1.8 Go après compactage ???????
Je ne sais pas ce tui stockes, mais si ce sont des images, il vaut mieux les laisser en dehors de la base
Si c'est du texte, tu peux mettre certaines tables dans une base et d'autres dans une autre base, mais
tu perdras l'intégrité référentielle (liaisons)
Mais bon 1.8Go de texte, c'est plus que toutes les encyclopédies universalis réunies !!
a+
--
Arnaud
---------------------------------------------
infos, conseils et liens : http://www.mpfa.info
---------------------------------------------
"Richard_35" <richard.cohen@laposte.net> a écrit dans le message de news: uCKiTvXZGHA.4688@TK2MSFTNGP04.phx.gbl...
Bonjour,
Il semble que 2 Go soit la taille maximale d'une base ACCESS 2000 : au-dessus, elle explose !
En approchant des 2 Go (1,8 Go), le compactage est problématique.
Y-a-t-il un moyen (patch ou autres) de dépasser cette limite de 2 Go (même après compactage) ?
Non malheureusement pour toi, pas de solution, à part lorgner du côté de SQL server.. a+ -- Arnaud --------------------------------------------- infos, conseils et liens : http://www.mpfa.info ---------------------------------------------
"Richard_35" a écrit dans le message de news:
Il s'agit d'un .mdb qui importe des tables d'un gros système distant. Le .mdb comporte plusieurs tables : le .mdb > 1,8 Go. Y-a-t-il une solution sans scinder le .mdb ? Merci.
<Anor> a écrit dans le message de news:
Bonjour,
1.8 Go après compactage ???????
Je ne sais pas ce tui stockes, mais si ce sont des images, il vaut mieux les laisser en dehors de la base Si c'est du texte, tu peux mettre certaines tables dans une base et d'autres dans une autre base, mais tu perdras l'intégrité référentielle (liaisons)
Mais bon 1.8Go de texte, c'est plus que toutes les encyclopédies universalis réunies !!
a+ -- Arnaud --------------------------------------------- infos, conseils et liens : http://www.mpfa.info ---------------------------------------------
"Richard_35" a écrit dans le message de news:
Bonjour,
Il semble que 2 Go soit la taille maximale d'une base ACCESS 2000 : au-dessus, elle explose ! En approchant des 2 Go (1,8 Go), le compactage est problématique. Y-a-t-il un moyen (patch ou autres) de dépasser cette limite de 2 Go (même après compactage) ?
Merci d'avance pour votre aide.
Richard.
J-Pierre
Quelle est la taille maximale de SQL server 2005 express ? Parce qu'il est gratuit...
J-Pierre
Quelle est la taille maximale de SQL server 2005 express ? Parce qu'il est gratuit...
a+ -- Arnaud --------------------------------------------- infos, conseils et liens : http://www.mpfa.info --------------------------------------------- "J-Pierre" a écrit dans le message de news: %
Quelle est la taille maximale de SQL server 2005 express ? Parce qu'il est gratuit...
a+
--
Arnaud
---------------------------------------------
infos, conseils et liens : http://www.mpfa.info
---------------------------------------------
"J-Pierre" <pas.de.pub.jpberchtold@hotmail.com> a écrit dans le message de news: %23ku5FufZGHA.1192@TK2MSFTNGP03.phx.gbl...
Quelle est la taille maximale de SQL server 2005 express ? Parce qu'il est gratuit...
a+ -- Arnaud --------------------------------------------- infos, conseils et liens : http://www.mpfa.info --------------------------------------------- "J-Pierre" a écrit dans le message de news: %
Quelle est la taille maximale de SQL server 2005 express ? Parce qu'il est gratuit...
ça doit être assez lent une bd access de cette taille
J-Pierre
Bonjour,
"SQL server 2005 express" n'est pas une BD Access, c'est une BD SQL Server, sans tous les outils de SQL Server (en particulier Enterprise Manager). Du moins, c'était le cas avec les versions précédentes (qui avaient des noms différents), Access jouant le rôle de client. Access permet également de maintenir la BD.
Et puis, la rapidité dépend essentiellement de la qualité de la conception de la base et de la qualité du développement, pas de la taille de ta base. Il est évident que si tu développes en utilisant les "techniques standard" (le terme adéquat m'échappe) d'Access pour l'accès aux données, ça va se traîner. Ces "techniques standard" sont parfaites pour des développeurs non-informaticiens, la base n'étant pas trop grosse, l'appli étant utilisée par un nombre restreint d'utilisateurs et sur un réseau local.
Si tu utilises SQL Server et un projet Access ADP comme client, je te garantis que ce sera aussi rapide que n'importe quoi d'autre. Même en liant les tables SQL Server dans un MDB, tu arrives à de très bonnes performances - moins bonnes qu'avec un projet ADP -, à condition de ne pas développer n'importe comment.
J-Pierre
Bonjour,
"SQL server 2005 express" n'est pas une BD Access, c'est une BD SQL Server, sans tous les outils de SQL Server (en
particulier Enterprise Manager). Du moins, c'était le cas avec les versions précédentes (qui avaient des noms différents),
Access jouant le rôle de client. Access permet également de maintenir la BD.
Et puis, la rapidité dépend essentiellement de la qualité de la conception de la base et de la qualité du développement, pas
de la taille de ta base. Il est évident que si tu développes en utilisant les "techniques standard" (le terme adéquat
m'échappe) d'Access pour l'accès aux données, ça va se traîner. Ces "techniques standard" sont parfaites pour des développeurs
non-informaticiens, la base n'étant pas trop grosse, l'appli étant utilisée par un nombre restreint d'utilisateurs et sur un
réseau local.
Si tu utilises SQL Server et un projet Access ADP comme client, je te garantis que ce sera aussi rapide que n'importe quoi
d'autre. Même en liant les tables SQL Server dans un MDB, tu arrives à de très bonnes performances - moins bonnes qu'avec un
projet ADP -, à condition de ne pas développer n'importe comment.
"SQL server 2005 express" n'est pas une BD Access, c'est une BD SQL Server, sans tous les outils de SQL Server (en particulier Enterprise Manager). Du moins, c'était le cas avec les versions précédentes (qui avaient des noms différents), Access jouant le rôle de client. Access permet également de maintenir la BD.
Et puis, la rapidité dépend essentiellement de la qualité de la conception de la base et de la qualité du développement, pas de la taille de ta base. Il est évident que si tu développes en utilisant les "techniques standard" (le terme adéquat m'échappe) d'Access pour l'accès aux données, ça va se traîner. Ces "techniques standard" sont parfaites pour des développeurs non-informaticiens, la base n'étant pas trop grosse, l'appli étant utilisée par un nombre restreint d'utilisateurs et sur un réseau local.
Si tu utilises SQL Server et un projet Access ADP comme client, je te garantis que ce sera aussi rapide que n'importe quoi d'autre. Même en liant les tables SQL Server dans un MDB, tu arrives à de très bonnes performances - moins bonnes qu'avec un projet ADP -, à condition de ne pas développer n'importe comment.
J-Pierre
Bonjour
"J-Pierre"
Si tu utilises SQL Server et un projet Access ADP comme client, je te garantis que ce sera aussi rapide que n'importe quoi d'autre. Même en liant les tables SQL Server dans un MDB, tu arrives à de très bonnes performances - moins bonnes qu'avec un projet ADP -, à condition de ne pas développer n'importe comment.
Et pour répondre à la question que tout le monde se pose : - "comment fait-t-on pour ne pas développer n'importe comment ?"
La réponse est : - on fait comme d'habitude et quand ça rame on essaye une autre méthode : si ça ne rame plus, alors c'est qu'en faisant comme ça, on a développé "comme il fallait" ;-))
-- Arnaud --------------------------------------------- infos, conseils et liens : http://www.mpfa.info ---------------------------------------------
Bonjour
"J-Pierre"
Si tu utilises SQL Server et un projet Access ADP comme client, je te garantis que ce sera aussi rapide que n'importe quoi
d'autre. Même en liant les tables SQL Server dans un MDB, tu arrives à de très bonnes performances - moins bonnes qu'avec un
projet ADP -, à condition de ne pas développer n'importe comment.
Et pour répondre à la question que tout le monde se pose :
- "comment fait-t-on pour ne pas développer n'importe comment ?"
La réponse est :
- on fait comme d'habitude et quand ça rame on essaye une autre méthode : si ça ne rame plus, alors c'est qu'en faisant comme ça, on
a développé "comme il fallait" ;-))
--
Arnaud
---------------------------------------------
infos, conseils et liens : http://www.mpfa.info
---------------------------------------------
Si tu utilises SQL Server et un projet Access ADP comme client, je te garantis que ce sera aussi rapide que n'importe quoi d'autre. Même en liant les tables SQL Server dans un MDB, tu arrives à de très bonnes performances - moins bonnes qu'avec un projet ADP -, à condition de ne pas développer n'importe comment.
Et pour répondre à la question que tout le monde se pose : - "comment fait-t-on pour ne pas développer n'importe comment ?"
La réponse est : - on fait comme d'habitude et quand ça rame on essaye une autre méthode : si ça ne rame plus, alors c'est qu'en faisant comme ça, on a développé "comme il fallait" ;-))
-- Arnaud --------------------------------------------- infos, conseils et liens : http://www.mpfa.info ---------------------------------------------
J-Pierre
Bonsoir Arnaud,
On peut aussi me demander :-)
Mais alors, très très très gentiment......
Et pourquoi que je sais et que les autres y savent pas ?
Parce que j'ai beaucoup ramé :-( et que ça rame plus :-)
Faut dire, aussi, que MS ne publie pas grand chose sur la cinématique d'accès aux tables, sans doute un grand secret......
J-Pierre
Tu ne lis qu'un message sur cinq, mais apparemment, tu lis les bons :-)
<Anor> a écrit dans le message de news:
Bonjour
"J-Pierre"
Si tu utilises SQL Server et un projet Access ADP comme client, je te garantis que ce sera aussi rapide que n'importe quoi d'autre. Même en liant les tables SQL Server dans un MDB, tu arrives à de très bonnes performances - moins bonnes qu'avec un projet ADP -, à condition de ne pas développer n'importe comment.
Et pour répondre à la question que tout le monde se pose : - "comment fait-t-on pour ne pas développer n'importe comment ?"
La réponse est : - on fait comme d'habitude et quand ça rame on essaye une autre méthode : si ça ne rame plus, alors c'est qu'en faisant comme ça, on a développé "comme il fallait" ;-))
-- Arnaud --------------------------------------------- infos, conseils et liens : http://www.mpfa.info ---------------------------------------------
Bonsoir Arnaud,
On peut aussi me demander :-)
Mais alors, très très très gentiment......
Et pourquoi que je sais et que les autres y savent pas ?
Parce que j'ai beaucoup ramé :-(
et que ça rame plus :-)
Faut dire, aussi, que MS ne publie pas grand chose sur la cinématique d'accès aux tables, sans doute un grand secret......
J-Pierre
Tu ne lis qu'un message sur cinq, mais apparemment, tu lis les bons :-)
<Anor> a écrit dans le message de news: OCBn7E9ZGHA.3736@TK2MSFTNGP04.phx.gbl...
Bonjour
"J-Pierre"
Si tu utilises SQL Server et un projet Access ADP comme client, je te garantis que ce sera aussi rapide que n'importe quoi
d'autre. Même en liant les tables SQL Server dans un MDB, tu arrives à de très bonnes performances - moins bonnes qu'avec
un projet ADP -, à condition de ne pas développer n'importe comment.
Et pour répondre à la question que tout le monde se pose :
- "comment fait-t-on pour ne pas développer n'importe comment ?"
La réponse est :
- on fait comme d'habitude et quand ça rame on essaye une autre méthode : si ça ne rame plus, alors c'est qu'en faisant
comme ça, on a développé "comme il fallait" ;-))
--
Arnaud
---------------------------------------------
infos, conseils et liens : http://www.mpfa.info
---------------------------------------------
Et pourquoi que je sais et que les autres y savent pas ?
Parce que j'ai beaucoup ramé :-( et que ça rame plus :-)
Faut dire, aussi, que MS ne publie pas grand chose sur la cinématique d'accès aux tables, sans doute un grand secret......
J-Pierre
Tu ne lis qu'un message sur cinq, mais apparemment, tu lis les bons :-)
<Anor> a écrit dans le message de news:
Bonjour
"J-Pierre"
Si tu utilises SQL Server et un projet Access ADP comme client, je te garantis que ce sera aussi rapide que n'importe quoi d'autre. Même en liant les tables SQL Server dans un MDB, tu arrives à de très bonnes performances - moins bonnes qu'avec un projet ADP -, à condition de ne pas développer n'importe comment.
Et pour répondre à la question que tout le monde se pose : - "comment fait-t-on pour ne pas développer n'importe comment ?"
La réponse est : - on fait comme d'habitude et quand ça rame on essaye une autre méthode : si ça ne rame plus, alors c'est qu'en faisant comme ça, on a développé "comme il fallait" ;-))
-- Arnaud --------------------------------------------- infos, conseils et liens : http://www.mpfa.info ---------------------------------------------
