je viens de developper pour la première fois une base access un peu plus
évoluée que d'habitude (gestion utilisateurs, vba, scission de la base et du
front), mais voila, je trouve l'application lente en réseau, je voudrais
aller plus loin, ne serait-ce que pour le fun...mon budget étant clairement
de 0 euro.
A ce jour, je me dis que pour améliorer un client et surtout shunter le fait
qu'il faille une licence access sur chaque client, on peut d'apres mes
lectures :
- passer en asp (désolé, mais je ne suis pas du tout un developpeur pro et
je bloque devant trop de html)
- passer en runtime (pas la licence dans mon entreprise)
- passer en excel (ne rigolez pas, je le fais vu que tout le monde en
entreprise a une licence xl)
- passer en vb (doit-on recommencer à zero?, est-ce long?)
- autre... => si vous avez des idées jouables, je suis preneur
Et pour faire évoluer la base :
- passer en msde (j'ai 5 utilisateurs au max, ce sera mieux ?)
- passer en sql server version free (j'ai 5 utilisateurs au max, ce sera
mieux ?)
- autre ....=> si vous avez des idées, je suis preneur
Vous l'aurez compris, l'idée de mon post est de receuillir un maximum d'idée
pour les développements, sachant qu'une veritable expérience vaut bien plus
qu'une pub à mes yeux.
Je remercie tout temoignage indiquant la complexité, les avantages et
inconvénients de leurs diverses expériences access. Ca me sera utilse pour
cette expérience ainsi que les prochaines.
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
LiR
Bonjour,
Je pense que toute personne qui a créé sa première base avec tables liées est passées par les mêmes questions que les tiennes.
En ce qui concerne Acees et les performances, il faut savoir qu'il existe énormément de paramètres qui peuvent te permettre d'améliorer l'efficacuté de ton application.
En gros, on peut retenir les 3 critères déterminants suivants :
1. Avoir un recordset caché et ouvert en permanence vers la base contenant les tables (par exemple avoir un formulaire caché qui se charge à l'ouverture, qui reste TOUJOURS ouvert et qui utilise un recordset éditable ayant comme source une des tables liées - n'importe laquelle, avec aucun enregistrement et juste un champ pour minimiser le temps de chargement).
2. Définir à [NONE] la propriété "Nom Sous-feuille données" de CHAQUE table de la base source.
Voir pour cela l'article 275085 de la KB : "BOGUE : performance faible sur les tables liées dans Access 2002 et Office Access 2003" ici : http://support.microsoft.com/default.aspx?scid=kb;fr;275085
3. Utiliser une convention de nom 8.3 pour le nom complet de la base source. Mettre la base source à la racine d'un lecteur ou, si ce n'est pas possible, dans un dossier du nom le plus court possible.
LES POINTS 1 et 3 sont presque VITAUX à toute application en base frontale/clients sur un réseau. Pour des cas testés, il multiplient les temps d'accès par 20 et peuvent aboutir à une utilisation identique à celle d'une base locale.
Par ailleurs, il y a un article de la KB qui donne certains autres paramétrages déterminants qui peuvent être utilisés conjointement aux 3 précédents.
Il s'agit de l'article KB 889588 "How to optimize Office Access and Jet database engine network performance with Windows 2000-based and Windows XP-based clients", ici : http://support.microsoft.com/kb/889588/en-us
En espérant que cela vous aidera...
Bonjour,
je viens de developper pour la première fois une base access un peu plus évoluée que d'habitude (gestion utilisateurs, vba, scission de la base et du front), mais voila, je trouve l'application lente en réseau, je voudrais aller plus loin, ne serait-ce que pour le fun...mon budget étant clairement de 0 euro.
A ce jour, je me dis que pour améliorer un client et surtout shunter le fait qu'il faille une licence access sur chaque client, on peut d'apres mes lectures :
- passer en asp (désolé, mais je ne suis pas du tout un developpeur pro et je bloque devant trop de html) - passer en runtime (pas la licence dans mon entreprise) - passer en excel (ne rigolez pas, je le fais vu que tout le monde en entreprise a une licence xl) - passer en vb (doit-on recommencer à zero?, est-ce long?) - autre... => si vous avez des idées jouables, je suis preneur
Et pour faire évoluer la base :
- passer en msde (j'ai 5 utilisateurs au max, ce sera mieux ?) - passer en sql server version free (j'ai 5 utilisateurs au max, ce sera mieux ?) - autre ....=> si vous avez des idées, je suis preneur
Vous l'aurez compris, l'idée de mon post est de receuillir un maximum d'idée pour les développements, sachant qu'une veritable expérience vaut bien plus qu'une pub à mes yeux.
Je remercie tout temoignage indiquant la complexité, les avantages et inconvénients de leurs diverses expériences access. Ca me sera utilse pour cette expérience ainsi que les prochaines.
Merci d'avance.
Poulpor
Bonjour,
Je pense que toute personne qui a créé sa première base avec tables liées
est passées par les mêmes questions que les tiennes.
En ce qui concerne Acees et les performances, il faut savoir qu'il existe
énormément de paramètres qui peuvent te permettre d'améliorer l'efficacuté de
ton application.
En gros, on peut retenir les 3 critères déterminants suivants :
1. Avoir un recordset caché et ouvert en permanence vers la base contenant
les tables (par exemple avoir un formulaire caché qui se charge à
l'ouverture, qui reste TOUJOURS ouvert et qui utilise un recordset éditable
ayant comme source une des tables liées - n'importe laquelle, avec aucun
enregistrement et juste un champ pour minimiser le temps de chargement).
2. Définir à [NONE] la propriété "Nom Sous-feuille données" de CHAQUE table
de la base source.
Voir pour cela l'article 275085 de la KB : "BOGUE : performance faible sur
les tables liées dans Access 2002 et Office Access 2003" ici :
http://support.microsoft.com/default.aspx?scid=kb;fr;275085
3. Utiliser une convention de nom 8.3 pour le nom complet de la base source.
Mettre la base source à la racine d'un lecteur ou, si ce n'est pas possible,
dans un dossier du nom le plus court possible.
LES POINTS 1 et 3 sont presque VITAUX à toute application en base
frontale/clients sur un réseau. Pour des cas testés, il multiplient les temps
d'accès par 20 et peuvent aboutir à une utilisation identique à celle d'une
base locale.
Par ailleurs, il y a un article de la KB qui donne certains autres
paramétrages déterminants qui peuvent être utilisés conjointement aux 3
précédents.
Il s'agit de l'article KB 889588 "How to optimize Office Access and Jet
database engine network performance with Windows 2000-based and Windows
XP-based clients", ici :
http://support.microsoft.com/kb/889588/en-us
En espérant que cela vous aidera...
Bonjour,
je viens de developper pour la première fois une base access un peu plus
évoluée que d'habitude (gestion utilisateurs, vba, scission de la base et du
front), mais voila, je trouve l'application lente en réseau, je voudrais
aller plus loin, ne serait-ce que pour le fun...mon budget étant clairement
de 0 euro.
A ce jour, je me dis que pour améliorer un client et surtout shunter le fait
qu'il faille une licence access sur chaque client, on peut d'apres mes
lectures :
- passer en asp (désolé, mais je ne suis pas du tout un developpeur pro et
je bloque devant trop de html)
- passer en runtime (pas la licence dans mon entreprise)
- passer en excel (ne rigolez pas, je le fais vu que tout le monde en
entreprise a une licence xl)
- passer en vb (doit-on recommencer à zero?, est-ce long?)
- autre... => si vous avez des idées jouables, je suis preneur
Et pour faire évoluer la base :
- passer en msde (j'ai 5 utilisateurs au max, ce sera mieux ?)
- passer en sql server version free (j'ai 5 utilisateurs au max, ce sera
mieux ?)
- autre ....=> si vous avez des idées, je suis preneur
Vous l'aurez compris, l'idée de mon post est de receuillir un maximum d'idée
pour les développements, sachant qu'une veritable expérience vaut bien plus
qu'une pub à mes yeux.
Je remercie tout temoignage indiquant la complexité, les avantages et
inconvénients de leurs diverses expériences access. Ca me sera utilse pour
cette expérience ainsi que les prochaines.
Je pense que toute personne qui a créé sa première base avec tables liées est passées par les mêmes questions que les tiennes.
En ce qui concerne Acees et les performances, il faut savoir qu'il existe énormément de paramètres qui peuvent te permettre d'améliorer l'efficacuté de ton application.
En gros, on peut retenir les 3 critères déterminants suivants :
1. Avoir un recordset caché et ouvert en permanence vers la base contenant les tables (par exemple avoir un formulaire caché qui se charge à l'ouverture, qui reste TOUJOURS ouvert et qui utilise un recordset éditable ayant comme source une des tables liées - n'importe laquelle, avec aucun enregistrement et juste un champ pour minimiser le temps de chargement).
2. Définir à [NONE] la propriété "Nom Sous-feuille données" de CHAQUE table de la base source.
Voir pour cela l'article 275085 de la KB : "BOGUE : performance faible sur les tables liées dans Access 2002 et Office Access 2003" ici : http://support.microsoft.com/default.aspx?scid=kb;fr;275085
3. Utiliser une convention de nom 8.3 pour le nom complet de la base source. Mettre la base source à la racine d'un lecteur ou, si ce n'est pas possible, dans un dossier du nom le plus court possible.
LES POINTS 1 et 3 sont presque VITAUX à toute application en base frontale/clients sur un réseau. Pour des cas testés, il multiplient les temps d'accès par 20 et peuvent aboutir à une utilisation identique à celle d'une base locale.
Par ailleurs, il y a un article de la KB qui donne certains autres paramétrages déterminants qui peuvent être utilisés conjointement aux 3 précédents.
Il s'agit de l'article KB 889588 "How to optimize Office Access and Jet database engine network performance with Windows 2000-based and Windows XP-based clients", ici : http://support.microsoft.com/kb/889588/en-us
En espérant que cela vous aidera...
Bonjour,
je viens de developper pour la première fois une base access un peu plus évoluée que d'habitude (gestion utilisateurs, vba, scission de la base et du front), mais voila, je trouve l'application lente en réseau, je voudrais aller plus loin, ne serait-ce que pour le fun...mon budget étant clairement de 0 euro.
A ce jour, je me dis que pour améliorer un client et surtout shunter le fait qu'il faille une licence access sur chaque client, on peut d'apres mes lectures :
- passer en asp (désolé, mais je ne suis pas du tout un developpeur pro et je bloque devant trop de html) - passer en runtime (pas la licence dans mon entreprise) - passer en excel (ne rigolez pas, je le fais vu que tout le monde en entreprise a une licence xl) - passer en vb (doit-on recommencer à zero?, est-ce long?) - autre... => si vous avez des idées jouables, je suis preneur
Et pour faire évoluer la base :
- passer en msde (j'ai 5 utilisateurs au max, ce sera mieux ?) - passer en sql server version free (j'ai 5 utilisateurs au max, ce sera mieux ?) - autre ....=> si vous avez des idées, je suis preneur
Vous l'aurez compris, l'idée de mon post est de receuillir un maximum d'idée pour les développements, sachant qu'une veritable expérience vaut bien plus qu'une pub à mes yeux.
Je remercie tout temoignage indiquant la complexité, les avantages et inconvénients de leurs diverses expériences access. Ca me sera utilse pour cette expérience ainsi que les prochaines.
