base en réseau - performance

L'avantage aussi du .mdb est que je peux modifier mes
requêtes en cours d'exploitation voir en ajouter ou en faire une juste
ponctuellement, ça s'est simpa car j'ai souvent des utilisateurs qui ont
besoin d'un truc ponctuel.

Pour les bases nécessitant des requêtes ponctuelles (et tu as raison, il y
en a !), je me crée systématiquement une 3e base "à moi" (mdb) dans laquelle
toutes les tables sont également liées, mais qui ne contient rien d'autre
que mes requêtes. Car... elles sont ponctuelles... mais elles reviennent
quand même, une fois par an par exemple... Je les stocke donc dans cette
base "Nathalie_Requetes.mdb" et cela décharge le mdb/mde principal, lequel
contient trop souvent une multitude de requêtes "poubelles" (pardon...
ponctuelles ;-).
Généralement, je fais des exports Excel du résultat de ces requêtes que je
donne aux utilisateurs pour qu'ils manipulent les données comme ils veulent.

Pour le moment, je reste en version 2000 car j'ai peur des migrations et
des
anomalies qu'elles peuvent apporter.

Le passage 2000 à 2003 se passe plutôt bien.

Tes bases les plus gros ont atteind quelles tailles ?

Les datas : 210 Mo environ (65 tables de mémoire)
Le code : 280 Mo, mais je n'ai pas 600 formulaires ! C'est plutôt parce que
je crée des bases dont le look est proche du site web du client, et même si
j'utilise des images extrêmement légères et optimisées, cela alourdit un
peu.
Cela dit, je ne fais pas une fixation sur la taille. Je n'y pense même pas
;-)

Je vois que tu es pro d'Access, 10 ans !

Pro... toutes PROportions gardées : interactivité, look, sécurité, bref,
l'Access "bureautique", oui...
PROgrammation, non (ou à peine). Je fais appel aux services d'un programmeur
car je ne suis pas compétente en VB, même si cela me plaît (pas le temps de
tout faire).
Mais on ne fait jamais le tour complet d'Access.

Bonne continuation,
--
Tisane (les garçons du forum - ils sont nombreux - vont dire que les filles
sont des pipelettes ;-)

Quand tu dis partager ta base sur le serveur.
Dans le même repertoire, tu mets une base de données et une base de
code,
tu
lies la base de code aux données par tables liées. Je dois dire que
mettre
les deux bases sur le serveur, je n'ai pas encore essayé.

Oui. Par exemple, si ta base s'appelle Nathalie.mdb, tu en fais une copie
:
tu appelles l'une Nathalie_Data.mdb (ou Nathalie_Tables.mdb), l'autre
Nathalie_Code.mdb.
Dans la 1re, tu supprimes TOUT sauf les tables.
Dans la 2e, tu supprimes toutes les tables et tu les attaches (menu
Fichier
| Données externes | Lier les tables).
Tu peux aussi utiliser les assistants pour faire tout cela (menu Outils |
Utilitaires de base... | Fractionner une base).
Curieusement, j'ai plus confiance en moi qu'en certains assistants ;-)
J'ai fais comme toi pour diviser la base lorsque j'ai fais des essais. Moi

aussi je le fais manuellement, je ne suis pas pro assistant !

Par contre, ma base est une base .mdb et non mde comme toi apparemment.
Cela peut peut-être expliquer mes soucis.

Non. La conversion d'un mdb en mde (menu Outils | Utilitaires de base...
|
Créer un mde) ne fait qu'augmenter la protection d'une base. Pas dans le
sens d'une corruption, mais plutôt d'accès aux objets (pas d'accès aux
formulaires, états, macros, modules en mode création). C'est tout.
D'ailleurs, je ne crée le mde que pour le "code". Je laisse les tables en
mdb.
Attention : si tu crées un mde, garde *précieusement* le mdb en
triiiiiiiiiple exemplaire quelque part. Si tu perds le mdb, tu ne pourras
plus modifier ta base. Autrement dit, on fait toujours les modifs sur le
mdb, et chaque fois on recrée le mde. Cela prend une minute.
Nathalie

--
Tisane
[...]

Tout à fait d'accord, on ne fais jamais le tour d'Access !
Mes requêtes ponctuelles qui un jour, reviennent plusieurs fois,
annuellement ou chez nous par collection (donc deux fois par an car nous
sommes dans le textile) finissent par devenir des requêtes définitives. Je
les appelle alors dans un formulaire et effectivement, comme toi, dont le
résultat se met dans un excel que je fais afficher à l'utilisateur. Après, il
le sauvegarde où il veut et en fait ce qu'il veut.
L'objectif, pour une requête, qui revient périodiquement, est que si je ne
suis pas là, l'utilisateur soit capable d'avoir la même info (étant seul sur
site, je n'ai pas le choix).
Je te remercie de cet échange de méthode de travail.
Bonne continuation également et bon week-end.
A bientôt sur un autre sujet...
--
Nathalie

L'avantage aussi du .mdb est que je peux modifier mes
requêtes en cours d'exploitation voir en ajouter ou en faire une juste
ponctuellement, ça s'est simpa car j'ai souvent des utilisateurs qui ont
besoin d'un truc ponctuel.

Pour les bases nécessitant des requêtes ponctuelles (et tu as raison, il y
en a !), je me crée systématiquement une 3e base "à moi" (mdb) dans laquelle
toutes les tables sont également liées, mais qui ne contient rien d'autre
que mes requêtes. Car... elles sont ponctuelles... mais elles reviennent
quand même, une fois par an par exemple... Je les stocke donc dans cette
base "Nathalie_Requetes.mdb" et cela décharge le mdb/mde principal, lequel
contient trop souvent une multitude de requêtes "poubelles" (pardon...
ponctuelles ;-).
Généralement, je fais des exports Excel du résultat de ces requêtes que je
donne aux utilisateurs pour qu'ils manipulent les données comme ils veulent.

Pour le moment, je reste en version 2000 car j'ai peur des migrations et
des
anomalies qu'elles peuvent apporter.

Le passage 2000 à 2003 se passe plutôt bien.

Tes bases les plus gros ont atteind quelles tailles ?

Les datas : 210 Mo environ (65 tables de mémoire)
Le code : 280 Mo, mais je n'ai pas 600 formulaires ! C'est plutôt parce que
je crée des bases dont le look est proche du site web du client, et même si
j'utilise des images extrêmement légères et optimisées, cela alourdit un
peu.
Cela dit, je ne fais pas une fixation sur la taille. Je n'y pense même pas
;-)

Je vois que tu es pro d'Access, 10 ans !

Pro... toutes PROportions gardées : interactivité, look, sécurité, bref,
l'Access "bureautique", oui...
PROgrammation, non (ou à peine). Je fais appel aux services d'un programmeur
car je ne suis pas compétente en VB, même si cela me plaît (pas le temps de
tout faire).
Mais on ne fait jamais le tour complet d'Access.

Bonne continuation,
--
Tisane (les garçons du forum - ils sont nombreux - vont dire que les filles
sont des pipelettes ;-)

Quand tu dis partager ta base sur le serveur.
Dans le même repertoire, tu mets une base de données et une base de
code,
tu
lies la base de code aux données par tables liées. Je dois dire que
mettre
les deux bases sur le serveur, je n'ai pas encore essayé.

Oui. Par exemple, si ta base s'appelle Nathalie.mdb, tu en fais une copie
:
tu appelles l'une Nathalie_Data.mdb (ou Nathalie_Tables.mdb), l'autre
Nathalie_Code.mdb.
Dans la 1re, tu supprimes TOUT sauf les tables.
Dans la 2e, tu supprimes toutes les tables et tu les attaches (menu
Fichier
| Données externes | Lier les tables).
Tu peux aussi utiliser les assistants pour faire tout cela (menu Outils |
Utilitaires de base... | Fractionner une base).
Curieusement, j'ai plus confiance en moi qu'en certains assistants ;-)
J'ai fais comme toi pour diviser la base lorsque j'ai fais des essais. Moi

aussi je le fais manuellement, je ne suis pas pro assistant !

Par contre, ma base est une base .mdb et non mde comme toi apparemment.
Cela peut peut-être expliquer mes soucis.

Non. La conversion d'un mdb en mde (menu Outils | Utilitaires de base...
|
Créer un mde) ne fait qu'augmenter la protection d'une base. Pas dans le
sens d'une corruption, mais plutôt d'accès aux objets (pas d'accès aux
formulaires, états, macros, modules en mode création). C'est tout.
D'ailleurs, je ne crée le mde que pour le "code". Je laisse les tables en
mdb.
Attention : si tu crées un mde, garde *précieusement* le mdb en
triiiiiiiiiple exemplaire quelque part. Si tu perds le mdb, tu ne pourras
plus modifier ta base. Autrement dit, on fait toujours les modifs sur le
mdb, et chaque fois on recrée le mde. Cela prend une minute.
Nathalie

--
Tisane
[...]