Bonjour,
"Nathalie Lebas"
[...]
| J'ai tenté en créant une seule base et en la mettant
| sur le serveur et là pas de problème. J'ai donc continué ainsi.
Mettre la base (frontale + dorsale) sur le serveur n'est jamais une bonne solution
(en dehors de tests comme indiqué par Tisane)
Perso (en dehors des toutes petites application mono-poste), je scinde toujours
mes bases en frontale-dorsale, même lorsque les deux se trouvent sur un seul
et même poste. Cela apporte une solidité incroyable à la base.
Même des dizaines de sorties "sauvages" par des utilisateurs peu scrupuleux
et sans formation, n'ont eu raison d'une seule de mes bases - corruption zéro !
| Cependant je me pose souvent ce problème surtout en voyant mes deux bases
| grossir. Je sais (en lisant ce forum) que le fait de partager en deux bases
| lorsque l'on travaille en réseau est important.
Il est normal qu'une base que l'on utilise grossisse.
Le tout est de voir si c'est en rapport avec les saisies qui sont réalisées.
Même les interrogations suivis de suppressions font grossir la base. Car les
suppression doivent êtrent suivies d'un compactage pour avoir de l'effet.
Une base qui gonfle sans rapport avec les saisies serait un signe de corruption.
| Depuis plusieurs mois, je cherche ici en locale (car je manque de temps) une
| formation d'optimisation de base et de développement. Mais nous sommes dans
| une petite ville de province et ce n'est pas simple.
| Le seul conseil que l'on me donne est de passer sur SQL Server, le problème
| est que cela demande du temps que je n'ai pas. Je préfèrerais pouvoir
| optimiser ma base actuelle.
Tu ne trouveras pas de "formation d'optimisation", ville de province ou non.
Ce qui défini le choix de la base de données est la destination et l'usage...
Si, au regard de la quantité de données, le nombre d'utilisateurs simultanés,
et le trafic engendré, une base Access suffit - il est idiot de répondre :
"passe à SQL Serveur" !
C'est comme si on avait un petit transport à effectuer, mais que l'on roule
avec l'embrayage qui patine, le frein à main serré, les pneus dégonflés
et que l'on te dise : prends un camion ;-))
Soit Access convient; est à la limite; ou ne convient pas !
Mais il faut savoir pourquoi, dans chacun des cas.
| Concernant le formulaire qui me pose problème aujourd'hui, je vais le
| diviser en deux et ainsi partager entre deux formulaires les onglets, dans un
| premier temps.
Cela indiquerait que ces sous formulaire n'avaient rien à faire là...
Les sous formulaire ne doivent se trouver dans un même formulaire principal
que si la saisie doit se faire à tour de rôle dans tous ces sous formulaire.
Autrement dit : si dans le formulaire principal, tu passe d'un enregistrement
au suivant et que tu n'utilise lors d'un traitement x qu'un seul et même sous
formulaires... les autres sous-form n'ont rien à faire là - sauf à bloquer la base
et à ralentir tout le monde.
Une règle intrangisante à respercter :
N'ouvrir que le recordset nécessaire à l'édition prévue. Ne rammener que les
données absolument obligatoires - rien de plus !
Ne pas ouvrir en dynamique pour une simple consultation. Cela est d'autant plus
important lorsque que l'on utilise beaucoup de tables secondaires (annexes)
et qui risquent d'être bloquantes.
Tout cela est à vérifier et à maitriser lors de la conception. Les modifications
ultérieures demandent parfois à revoir des pans entiers d'une base.
--
A+
Pierre (3stone) Access MVP
Perso: http://www.3stone.be/
MPFA: http://www.mpfa.info/ (infos générales)
Bonjour,
"Nathalie Lebas"
[...]
| J'ai tenté en créant une seule base et en la mettant
| sur le serveur et là pas de problème. J'ai donc continué ainsi.
Mettre la base (frontale + dorsale) sur le serveur n'est jamais une bonne solution
(en dehors de tests comme indiqué par Tisane)
Perso (en dehors des toutes petites application mono-poste), je scinde toujours
mes bases en frontale-dorsale, même lorsque les deux se trouvent sur un seul
et même poste. Cela apporte une solidité incroyable à la base.
Même des dizaines de sorties "sauvages" par des utilisateurs peu scrupuleux
et sans formation, n'ont eu raison d'une seule de mes bases - corruption zéro !
| Cependant je me pose souvent ce problème surtout en voyant mes deux bases
| grossir. Je sais (en lisant ce forum) que le fait de partager en deux bases
| lorsque l'on travaille en réseau est important.
Il est normal qu'une base que l'on utilise grossisse.
Le tout est de voir si c'est en rapport avec les saisies qui sont réalisées.
Même les interrogations suivis de suppressions font grossir la base. Car les
suppression doivent êtrent suivies d'un compactage pour avoir de l'effet.
Une base qui gonfle sans rapport avec les saisies serait un signe de corruption.
| Depuis plusieurs mois, je cherche ici en locale (car je manque de temps) une
| formation d'optimisation de base et de développement. Mais nous sommes dans
| une petite ville de province et ce n'est pas simple.
| Le seul conseil que l'on me donne est de passer sur SQL Server, le problème
| est que cela demande du temps que je n'ai pas. Je préfèrerais pouvoir
| optimiser ma base actuelle.
Tu ne trouveras pas de "formation d'optimisation", ville de province ou non.
Ce qui défini le choix de la base de données est la destination et l'usage...
Si, au regard de la quantité de données, le nombre d'utilisateurs simultanés,
et le trafic engendré, une base Access suffit - il est idiot de répondre :
"passe à SQL Serveur" !
C'est comme si on avait un petit transport à effectuer, mais que l'on roule
avec l'embrayage qui patine, le frein à main serré, les pneus dégonflés
et que l'on te dise : prends un camion ;-))
Soit Access convient; est à la limite; ou ne convient pas !
Mais il faut savoir pourquoi, dans chacun des cas.
| Concernant le formulaire qui me pose problème aujourd'hui, je vais le
| diviser en deux et ainsi partager entre deux formulaires les onglets, dans un
| premier temps.
Cela indiquerait que ces sous formulaire n'avaient rien à faire là...
Les sous formulaire ne doivent se trouver dans un même formulaire principal
que si la saisie doit se faire à tour de rôle dans tous ces sous formulaire.
Autrement dit : si dans le formulaire principal, tu passe d'un enregistrement
au suivant et que tu n'utilise lors d'un traitement x qu'un seul et même sous
formulaires... les autres sous-form n'ont rien à faire là - sauf à bloquer la base
et à ralentir tout le monde.
Une règle intrangisante à respercter :
N'ouvrir que le recordset nécessaire à l'édition prévue. Ne rammener que les
données absolument obligatoires - rien de plus !
Ne pas ouvrir en dynamique pour une simple consultation. Cela est d'autant plus
important lorsque que l'on utilise beaucoup de tables secondaires (annexes)
et qui risquent d'être bloquantes.
Tout cela est à vérifier et à maitriser lors de la conception. Les modifications
ultérieures demandent parfois à revoir des pans entiers d'une base.
--
A+
Pierre (3stone) Access MVP
Perso: http://www.3stone.be/
MPFA: http://www.mpfa.info/ (infos générales)
Bonjour,
"Nathalie Lebas"
[...]
| J'ai tenté en créant une seule base et en la mettant
| sur le serveur et là pas de problème. J'ai donc continué ainsi.
Mettre la base (frontale + dorsale) sur le serveur n'est jamais une bonne solution
(en dehors de tests comme indiqué par Tisane)
Perso (en dehors des toutes petites application mono-poste), je scinde toujours
mes bases en frontale-dorsale, même lorsque les deux se trouvent sur un seul
et même poste. Cela apporte une solidité incroyable à la base.
Même des dizaines de sorties "sauvages" par des utilisateurs peu scrupuleux
et sans formation, n'ont eu raison d'une seule de mes bases - corruption zéro !
| Cependant je me pose souvent ce problème surtout en voyant mes deux bases
| grossir. Je sais (en lisant ce forum) que le fait de partager en deux bases
| lorsque l'on travaille en réseau est important.
Il est normal qu'une base que l'on utilise grossisse.
Le tout est de voir si c'est en rapport avec les saisies qui sont réalisées.
Même les interrogations suivis de suppressions font grossir la base. Car les
suppression doivent êtrent suivies d'un compactage pour avoir de l'effet.
Une base qui gonfle sans rapport avec les saisies serait un signe de corruption.
| Depuis plusieurs mois, je cherche ici en locale (car je manque de temps) une
| formation d'optimisation de base et de développement. Mais nous sommes dans
| une petite ville de province et ce n'est pas simple.
| Le seul conseil que l'on me donne est de passer sur SQL Server, le problème
| est que cela demande du temps que je n'ai pas. Je préfèrerais pouvoir
| optimiser ma base actuelle.
Tu ne trouveras pas de "formation d'optimisation", ville de province ou non.
Ce qui défini le choix de la base de données est la destination et l'usage...
Si, au regard de la quantité de données, le nombre d'utilisateurs simultanés,
et le trafic engendré, une base Access suffit - il est idiot de répondre :
"passe à SQL Serveur" !
C'est comme si on avait un petit transport à effectuer, mais que l'on roule
avec l'embrayage qui patine, le frein à main serré, les pneus dégonflés
et que l'on te dise : prends un camion ;-))
Soit Access convient; est à la limite; ou ne convient pas !
Mais il faut savoir pourquoi, dans chacun des cas.
| Concernant le formulaire qui me pose problème aujourd'hui, je vais le
| diviser en deux et ainsi partager entre deux formulaires les onglets, dans un
| premier temps.
Cela indiquerait que ces sous formulaire n'avaient rien à faire là...
Les sous formulaire ne doivent se trouver dans un même formulaire principal
que si la saisie doit se faire à tour de rôle dans tous ces sous formulaire.
Autrement dit : si dans le formulaire principal, tu passe d'un enregistrement
au suivant et que tu n'utilise lors d'un traitement x qu'un seul et même sous
formulaires... les autres sous-form n'ont rien à faire là - sauf à bloquer la base
et à ralentir tout le monde.
Une règle intrangisante à respercter :
N'ouvrir que le recordset nécessaire à l'édition prévue. Ne rammener que les
données absolument obligatoires - rien de plus !
Ne pas ouvrir en dynamique pour une simple consultation. Cela est d'autant plus
important lorsque que l'on utilise beaucoup de tables secondaires (annexes)
et qui risquent d'être bloquantes.
Tout cela est à vérifier et à maitriser lors de la conception. Les modifications
ultérieures demandent parfois à revoir des pans entiers d'une base.
--
A+
Pierre (3stone) Access MVP
Perso: http://www.3stone.be/
MPFA: http://www.mpfa.info/ (infos générales)
Bonjour Pierre,
Comme je te l'ai écris, je vais à nouveau faire le test sur une pet ite base
en mettant la base de code sur les PC et je vous tiendrais au courant.
J'espère que nous n'aurons pas à nouveau cette situation de blocage que nous
avons déjà connu ici.
Je ne pense pas que nos bases grossissent anormalement. Si je prends la plus
grosse, hier soir elle était à 108160 ko après compactage elle es t passée à
103 500 ko. Nous sommes en pleine période de collection et l'activité sur la
base est importante donc cela me semble logique.
Concernant ma recherche de formation, cela peut-être également une
prestation. Je suis seule sur site et je pense que le contact avec quel qu'un
de bien plus qualifié que moi me ferais le plus grand bien ! Sur d'au tres
systèmes dans le passé, j'ai déjà procédé ainsi et le rés ultat était
intéressant. Ce type de prestation doit bien exister pour Access.
Concernant le choix d'Access ici il a été motivé par plusieurs ra isons:
1- lorsque je suis arrivée, il n'était pas question de développer des
applications importantes, seulement des petites donc naturellement Acce ss que
je connaissais, l'objectif était de remplacer l'AS400 par des progici els
2- l'achat de progiciels a été abandonné suite à de nombreux dé boires avec
les sociétés de services
3- notre société est en pleine croissance et en quelques mois,
l'informatique a dû évoluer considérablement (l'ancienne informat ique datait
de 20 ans sur AS400!) et surtout très rapidement
4- sur une des bases, j'ai 20 utilisateurs sur l'autre, une trentaine, je
pensais que cela ne posait pas de problème
5- le côté très pratique d'Access qui permet de transférer les bases sur un
portable et de partir à l'étranger pour visiter nos façonniers en Tunisie.
La raison qui m'a été donné pour passer à Sql Server est que la taille de ma
base principale (100000ko) posait problème. D'après mon interlocute ur, c'est
à partir de cette taille que les problèmes commencent à survenir avec Access
et qu'il faut en changer. Tisane m'a rassuré sur la taille de ma base !
Concernant le formulaire en cause, je l'ai donc divisé en deux hier. Il
s'agit d'un formulaire qui permet de créer une fiche produit. Il y av ait donc
un onglet :
- général (info général sur le produit, description, marque, th ème,
commentaires...)
- croquis (lien avec un .tif sur le serveur) + légende
- commentaire détaillé de conception
- fournitures le composant tous coloris
- coloris + fournitures déclinées au coloris
- commentaire proto
- calcul prix des matières
- calcul prix des fournitures
- calcul final du prix de revient
- entretien (détermination du code entretien à partir des matière s composant
le produit)
- composition (calcul de la composition du produit à partir des matiè res le
composant).
Sur ces onglets, des sous-formulaires se mettant à jour à partir de celui
des fournitures.
La partie prix, entretien et composition est moins "visité" que les p remiers
onglets, j'ai donc mis ces 5 onglets sur un autre formulaire, accessibl e par
un bouton. Cela semble convenir aux utilisateurs. Qu'en penses-tu ?
Concernant les données, rassures-toi, lorsque je fais des resquêtes , je
sélectionne les champs qui m'intéresse mais je ne prends pas tous l es champs
des tables comme je l'ai vu faire avec *.
J'ai un autre formulaire, de consultation pure, qui à mon avis demand e à
être revu mais je ne sais pas comment faire. Ta suggestion de ne pas lier les
sous-formulaires au départ m'intéresse. Ce formulaire permet de cho isir une
fourniture et d'obtenir à l'écran (et surtout sur le même écran ), le stock
présent chez nous, le stock chez chacun des façonniers, les command es en
cours non reçues, les commandes en cours partiellement reçues, les commandes
reçues et soldées, le reste à lancer. Pour chacun de ces élém ents, j'ai
utilisé un sous-formulaire. J'aimerais donc que ces sous-formulaires
deviennent "actifs" que lorsque la fourniture est sélectionnée. La sélection
de la fourniture se fait en 4 étapes :
- choisir un fournisseur
- choisir une fourniture de ce fournisseur
- choisir une dimension de cette fourniture
- choisir un coloris pour cette fourniture et dimension.
J'utilise pour ces sélections des listes déroulantes, cela "rame" u n peu
comme tu l'imagines. Ce formulaire étant très utilisé, j'aimerais l'optimiser.
Comment puis-je faire pour conditionner l'affichage des sous-formulaire s que
lorsque j'ai passé les 4 étapes de sélection de ma fourniture.
Merci de ton aide et de tes conseils, ils sont les bienvenus.
A+
Bonjour Pierre,
Comme je te l'ai écris, je vais à nouveau faire le test sur une pet ite base
en mettant la base de code sur les PC et je vous tiendrais au courant.
J'espère que nous n'aurons pas à nouveau cette situation de blocage que nous
avons déjà connu ici.
Je ne pense pas que nos bases grossissent anormalement. Si je prends la plus
grosse, hier soir elle était à 108160 ko après compactage elle es t passée à
103 500 ko. Nous sommes en pleine période de collection et l'activité sur la
base est importante donc cela me semble logique.
Concernant ma recherche de formation, cela peut-être également une
prestation. Je suis seule sur site et je pense que le contact avec quel qu'un
de bien plus qualifié que moi me ferais le plus grand bien ! Sur d'au tres
systèmes dans le passé, j'ai déjà procédé ainsi et le rés ultat était
intéressant. Ce type de prestation doit bien exister pour Access.
Concernant le choix d'Access ici il a été motivé par plusieurs ra isons:
1- lorsque je suis arrivée, il n'était pas question de développer des
applications importantes, seulement des petites donc naturellement Acce ss que
je connaissais, l'objectif était de remplacer l'AS400 par des progici els
2- l'achat de progiciels a été abandonné suite à de nombreux dé boires avec
les sociétés de services
3- notre société est en pleine croissance et en quelques mois,
l'informatique a dû évoluer considérablement (l'ancienne informat ique datait
de 20 ans sur AS400!) et surtout très rapidement
4- sur une des bases, j'ai 20 utilisateurs sur l'autre, une trentaine, je
pensais que cela ne posait pas de problème
5- le côté très pratique d'Access qui permet de transférer les bases sur un
portable et de partir à l'étranger pour visiter nos façonniers en Tunisie.
La raison qui m'a été donné pour passer à Sql Server est que la taille de ma
base principale (100000ko) posait problème. D'après mon interlocute ur, c'est
à partir de cette taille que les problèmes commencent à survenir avec Access
et qu'il faut en changer. Tisane m'a rassuré sur la taille de ma base !
Concernant le formulaire en cause, je l'ai donc divisé en deux hier. Il
s'agit d'un formulaire qui permet de créer une fiche produit. Il y av ait donc
un onglet :
- général (info général sur le produit, description, marque, th ème,
commentaires...)
- croquis (lien avec un .tif sur le serveur) + légende
- commentaire détaillé de conception
- fournitures le composant tous coloris
- coloris + fournitures déclinées au coloris
- commentaire proto
- calcul prix des matières
- calcul prix des fournitures
- calcul final du prix de revient
- entretien (détermination du code entretien à partir des matière s composant
le produit)
- composition (calcul de la composition du produit à partir des matiè res le
composant).
Sur ces onglets, des sous-formulaires se mettant à jour à partir de celui
des fournitures.
La partie prix, entretien et composition est moins "visité" que les p remiers
onglets, j'ai donc mis ces 5 onglets sur un autre formulaire, accessibl e par
un bouton. Cela semble convenir aux utilisateurs. Qu'en penses-tu ?
Concernant les données, rassures-toi, lorsque je fais des resquêtes , je
sélectionne les champs qui m'intéresse mais je ne prends pas tous l es champs
des tables comme je l'ai vu faire avec *.
J'ai un autre formulaire, de consultation pure, qui à mon avis demand e à
être revu mais je ne sais pas comment faire. Ta suggestion de ne pas lier les
sous-formulaires au départ m'intéresse. Ce formulaire permet de cho isir une
fourniture et d'obtenir à l'écran (et surtout sur le même écran ), le stock
présent chez nous, le stock chez chacun des façonniers, les command es en
cours non reçues, les commandes en cours partiellement reçues, les commandes
reçues et soldées, le reste à lancer. Pour chacun de ces élém ents, j'ai
utilisé un sous-formulaire. J'aimerais donc que ces sous-formulaires
deviennent "actifs" que lorsque la fourniture est sélectionnée. La sélection
de la fourniture se fait en 4 étapes :
- choisir un fournisseur
- choisir une fourniture de ce fournisseur
- choisir une dimension de cette fourniture
- choisir un coloris pour cette fourniture et dimension.
J'utilise pour ces sélections des listes déroulantes, cela "rame" u n peu
comme tu l'imagines. Ce formulaire étant très utilisé, j'aimerais l'optimiser.
Comment puis-je faire pour conditionner l'affichage des sous-formulaire s que
lorsque j'ai passé les 4 étapes de sélection de ma fourniture.
Merci de ton aide et de tes conseils, ils sont les bienvenus.
A+
Bonjour Pierre,
Comme je te l'ai écris, je vais à nouveau faire le test sur une pet ite base
en mettant la base de code sur les PC et je vous tiendrais au courant.
J'espère que nous n'aurons pas à nouveau cette situation de blocage que nous
avons déjà connu ici.
Je ne pense pas que nos bases grossissent anormalement. Si je prends la plus
grosse, hier soir elle était à 108160 ko après compactage elle es t passée à
103 500 ko. Nous sommes en pleine période de collection et l'activité sur la
base est importante donc cela me semble logique.
Concernant ma recherche de formation, cela peut-être également une
prestation. Je suis seule sur site et je pense que le contact avec quel qu'un
de bien plus qualifié que moi me ferais le plus grand bien ! Sur d'au tres
systèmes dans le passé, j'ai déjà procédé ainsi et le rés ultat était
intéressant. Ce type de prestation doit bien exister pour Access.
Concernant le choix d'Access ici il a été motivé par plusieurs ra isons:
1- lorsque je suis arrivée, il n'était pas question de développer des
applications importantes, seulement des petites donc naturellement Acce ss que
je connaissais, l'objectif était de remplacer l'AS400 par des progici els
2- l'achat de progiciels a été abandonné suite à de nombreux dé boires avec
les sociétés de services
3- notre société est en pleine croissance et en quelques mois,
l'informatique a dû évoluer considérablement (l'ancienne informat ique datait
de 20 ans sur AS400!) et surtout très rapidement
4- sur une des bases, j'ai 20 utilisateurs sur l'autre, une trentaine, je
pensais que cela ne posait pas de problème
5- le côté très pratique d'Access qui permet de transférer les bases sur un
portable et de partir à l'étranger pour visiter nos façonniers en Tunisie.
La raison qui m'a été donné pour passer à Sql Server est que la taille de ma
base principale (100000ko) posait problème. D'après mon interlocute ur, c'est
à partir de cette taille que les problèmes commencent à survenir avec Access
et qu'il faut en changer. Tisane m'a rassuré sur la taille de ma base !
Concernant le formulaire en cause, je l'ai donc divisé en deux hier. Il
s'agit d'un formulaire qui permet de créer une fiche produit. Il y av ait donc
un onglet :
- général (info général sur le produit, description, marque, th ème,
commentaires...)
- croquis (lien avec un .tif sur le serveur) + légende
- commentaire détaillé de conception
- fournitures le composant tous coloris
- coloris + fournitures déclinées au coloris
- commentaire proto
- calcul prix des matières
- calcul prix des fournitures
- calcul final du prix de revient
- entretien (détermination du code entretien à partir des matière s composant
le produit)
- composition (calcul de la composition du produit à partir des matiè res le
composant).
Sur ces onglets, des sous-formulaires se mettant à jour à partir de celui
des fournitures.
La partie prix, entretien et composition est moins "visité" que les p remiers
onglets, j'ai donc mis ces 5 onglets sur un autre formulaire, accessibl e par
un bouton. Cela semble convenir aux utilisateurs. Qu'en penses-tu ?
Concernant les données, rassures-toi, lorsque je fais des resquêtes , je
sélectionne les champs qui m'intéresse mais je ne prends pas tous l es champs
des tables comme je l'ai vu faire avec *.
J'ai un autre formulaire, de consultation pure, qui à mon avis demand e à
être revu mais je ne sais pas comment faire. Ta suggestion de ne pas lier les
sous-formulaires au départ m'intéresse. Ce formulaire permet de cho isir une
fourniture et d'obtenir à l'écran (et surtout sur le même écran ), le stock
présent chez nous, le stock chez chacun des façonniers, les command es en
cours non reçues, les commandes en cours partiellement reçues, les commandes
reçues et soldées, le reste à lancer. Pour chacun de ces élém ents, j'ai
utilisé un sous-formulaire. J'aimerais donc que ces sous-formulaires
deviennent "actifs" que lorsque la fourniture est sélectionnée. La sélection
de la fourniture se fait en 4 étapes :
- choisir un fournisseur
- choisir une fourniture de ce fournisseur
- choisir une dimension de cette fourniture
- choisir un coloris pour cette fourniture et dimension.
J'utilise pour ces sélections des listes déroulantes, cela "rame" u n peu
comme tu l'imagines. Ce formulaire étant très utilisé, j'aimerais l'optimiser.
Comment puis-je faire pour conditionner l'affichage des sous-formulaire s que
lorsque j'ai passé les 4 étapes de sélection de ma fourniture.
Merci de ton aide et de tes conseils, ils sont les bienvenus.
A+
Je me permets d'émettre mon grain de sel dans cette discussion.
Avez-vous spécifier la version d'Access?
Pour moi, il est préférable d'être en version 2002 ou supérieure
Si ce n'est pas le cas migrer peut-être votre base.
Quel est votre serveur Windows 2000,Windows 2003, Netware Novell?
Votre serveur est-il correctement dimensionné?
-au niveau de la mémoire
-au niveau du processeur
-au niveau du nombre de verrous sur les serveurs
-surcharge réseau
Point délicat:
Le passage à une autre Base de données pour moi se justifie plutot par
le nombre d'utilisateurs connectés. 30 pour moi, c'est énorme à part en
lecture mais en ajout/ modification.
A savoir que les bases de données msaccess génère un trafic assez
conséquent sur le réseau. Surtout si les critères, jointures ne sont pas
effectuées sur des champs indexés.
Au lancement d'une requête,Msaccess (Msjet) rapatrie tous les
enregistrements en local et filtre les données en locale puis envoie le
résultat au programme demandeur.
Un "vrai" SGBD va calculer le résultat sur le serveur et renvoyer
uniquement le nombre de lignes demandées.
LA charge réseau est donc beaucoup moins importante.
A noter aussi que lorsque le matériel réseau est défectueux, il peut y
avoir un risque de corruption de la base quasiment sytematique.
Retrouver un matériel réseau défectueux sur 30 postes, n'est pas une
chose aisée...
Pour moi access est bien pour 5 postes, maxi 10 au delà même si dans la
plupart des cas ça marche, ce n'est pas une solution pérenne.
Cordialement
(Allez-y, tirez vos boulets rouges!)Bonjour Pierre,
Comme je te l'ai écris, je vais à nouveau faire le test sur une petite base
en mettant la base de code sur les PC et je vous tiendrais au courant.
J'espère que nous n'aurons pas à nouveau cette situation de blocage que nous
avons déjà connu ici.
Je ne pense pas que nos bases grossissent anormalement. Si je prends la plus
grosse, hier soir elle était à 108160 ko après compactage elle est passée à
103 500 ko. Nous sommes en pleine période de collection et l'activité sur la
base est importante donc cela me semble logique.
Concernant ma recherche de formation, cela peut-être également une
prestation. Je suis seule sur site et je pense que le contact avec quelqu'un
de bien plus qualifié que moi me ferais le plus grand bien ! Sur d'autres
systèmes dans le passé, j'ai déjà procédé ainsi et le résultat était
intéressant. Ce type de prestation doit bien exister pour Access.
Concernant le choix d'Access ici il a été motivé par plusieurs raisons:
1- lorsque je suis arrivée, il n'était pas question de développer des
applications importantes, seulement des petites donc naturellement Access que
je connaissais, l'objectif était de remplacer l'AS400 par des progiciels
2- l'achat de progiciels a été abandonné suite à de nombreux déboires avec
les sociétés de services
3- notre société est en pleine croissance et en quelques mois,
l'informatique a dû évoluer considérablement (l'ancienne informatique datait
de 20 ans sur AS400!) et surtout très rapidement
4- sur une des bases, j'ai 20 utilisateurs sur l'autre, une trentaine, je
pensais que cela ne posait pas de problème
5- le côté très pratique d'Access qui permet de transférer les bases sur un
portable et de partir à l'étranger pour visiter nos façonniers en Tunisie.
La raison qui m'a été donné pour passer à Sql Server est que la taille de ma
base principale (100000ko) posait problème. D'après mon interlocuteur, c'est
à partir de cette taille que les problèmes commencent à survenir avec Access
et qu'il faut en changer. Tisane m'a rassuré sur la taille de ma base !
Concernant le formulaire en cause, je l'ai donc divisé en deux hier. Il
s'agit d'un formulaire qui permet de créer une fiche produit. Il y avait donc
un onglet :
- général (info général sur le produit, description, marque, thème,
commentaires...)
- croquis (lien avec un .tif sur le serveur) + légende
- commentaire détaillé de conception
- fournitures le composant tous coloris
- coloris + fournitures déclinées au coloris
- commentaire proto
- calcul prix des matières
- calcul prix des fournitures
- calcul final du prix de revient
- entretien (détermination du code entretien à partir des matières composant
le produit)
- composition (calcul de la composition du produit à partir des matières le
composant).
Sur ces onglets, des sous-formulaires se mettant à jour à partir de celui
des fournitures.
La partie prix, entretien et composition est moins "visité" que les premiers
onglets, j'ai donc mis ces 5 onglets sur un autre formulaire, accessible par
un bouton. Cela semble convenir aux utilisateurs. Qu'en penses-tu ?
Concernant les données, rassures-toi, lorsque je fais des resquêtes, je
sélectionne les champs qui m'intéresse mais je ne prends pas tous les champs
des tables comme je l'ai vu faire avec *.
J'ai un autre formulaire, de consultation pure, qui à mon avis demande à
être revu mais je ne sais pas comment faire. Ta suggestion de ne pas lier les
sous-formulaires au départ m'intéresse. Ce formulaire permet de choisir une
fourniture et d'obtenir à l'écran (et surtout sur le même écran), le stock
présent chez nous, le stock chez chacun des façonniers, les commandes en
cours non reçues, les commandes en cours partiellement reçues, les commandes
reçues et soldées, le reste à lancer. Pour chacun de ces éléments, j'ai
utilisé un sous-formulaire. J'aimerais donc que ces sous-formulaires
deviennent "actifs" que lorsque la fourniture est sélectionnée. La sélection
de la fourniture se fait en 4 étapes :
- choisir un fournisseur
- choisir une fourniture de ce fournisseur
- choisir une dimension de cette fourniture
- choisir un coloris pour cette fourniture et dimension.
J'utilise pour ces sélections des listes déroulantes, cela "rame" un peu
comme tu l'imagines. Ce formulaire étant très utilisé, j'aimerais l'optimiser.
Comment puis-je faire pour conditionner l'affichage des sous-formulaires que
lorsque j'ai passé les 4 étapes de sélection de ma fourniture.
Merci de ton aide et de tes conseils, ils sont les bienvenus.
A+
Je me permets d'émettre mon grain de sel dans cette discussion.
Avez-vous spécifier la version d'Access?
Pour moi, il est préférable d'être en version 2002 ou supérieure
Si ce n'est pas le cas migrer peut-être votre base.
Quel est votre serveur Windows 2000,Windows 2003, Netware Novell?
Votre serveur est-il correctement dimensionné?
-au niveau de la mémoire
-au niveau du processeur
-au niveau du nombre de verrous sur les serveurs
-surcharge réseau
Point délicat:
Le passage à une autre Base de données pour moi se justifie plutot par
le nombre d'utilisateurs connectés. 30 pour moi, c'est énorme à part en
lecture mais en ajout/ modification.
A savoir que les bases de données msaccess génère un trafic assez
conséquent sur le réseau. Surtout si les critères, jointures ne sont pas
effectuées sur des champs indexés.
Au lancement d'une requête,Msaccess (Msjet) rapatrie tous les
enregistrements en local et filtre les données en locale puis envoie le
résultat au programme demandeur.
Un "vrai" SGBD va calculer le résultat sur le serveur et renvoyer
uniquement le nombre de lignes demandées.
LA charge réseau est donc beaucoup moins importante.
A noter aussi que lorsque le matériel réseau est défectueux, il peut y
avoir un risque de corruption de la base quasiment sytematique.
Retrouver un matériel réseau défectueux sur 30 postes, n'est pas une
chose aisée...
Pour moi access est bien pour 5 postes, maxi 10 au delà même si dans la
plupart des cas ça marche, ce n'est pas une solution pérenne.
Cordialement
(Allez-y, tirez vos boulets rouges!)
Bonjour Pierre,
Comme je te l'ai écris, je vais à nouveau faire le test sur une petite base
en mettant la base de code sur les PC et je vous tiendrais au courant.
J'espère que nous n'aurons pas à nouveau cette situation de blocage que nous
avons déjà connu ici.
Je ne pense pas que nos bases grossissent anormalement. Si je prends la plus
grosse, hier soir elle était à 108160 ko après compactage elle est passée à
103 500 ko. Nous sommes en pleine période de collection et l'activité sur la
base est importante donc cela me semble logique.
Concernant ma recherche de formation, cela peut-être également une
prestation. Je suis seule sur site et je pense que le contact avec quelqu'un
de bien plus qualifié que moi me ferais le plus grand bien ! Sur d'autres
systèmes dans le passé, j'ai déjà procédé ainsi et le résultat était
intéressant. Ce type de prestation doit bien exister pour Access.
Concernant le choix d'Access ici il a été motivé par plusieurs raisons:
1- lorsque je suis arrivée, il n'était pas question de développer des
applications importantes, seulement des petites donc naturellement Access que
je connaissais, l'objectif était de remplacer l'AS400 par des progiciels
2- l'achat de progiciels a été abandonné suite à de nombreux déboires avec
les sociétés de services
3- notre société est en pleine croissance et en quelques mois,
l'informatique a dû évoluer considérablement (l'ancienne informatique datait
de 20 ans sur AS400!) et surtout très rapidement
4- sur une des bases, j'ai 20 utilisateurs sur l'autre, une trentaine, je
pensais que cela ne posait pas de problème
5- le côté très pratique d'Access qui permet de transférer les bases sur un
portable et de partir à l'étranger pour visiter nos façonniers en Tunisie.
La raison qui m'a été donné pour passer à Sql Server est que la taille de ma
base principale (100000ko) posait problème. D'après mon interlocuteur, c'est
à partir de cette taille que les problèmes commencent à survenir avec Access
et qu'il faut en changer. Tisane m'a rassuré sur la taille de ma base !
Concernant le formulaire en cause, je l'ai donc divisé en deux hier. Il
s'agit d'un formulaire qui permet de créer une fiche produit. Il y avait donc
un onglet :
- général (info général sur le produit, description, marque, thème,
commentaires...)
- croquis (lien avec un .tif sur le serveur) + légende
- commentaire détaillé de conception
- fournitures le composant tous coloris
- coloris + fournitures déclinées au coloris
- commentaire proto
- calcul prix des matières
- calcul prix des fournitures
- calcul final du prix de revient
- entretien (détermination du code entretien à partir des matières composant
le produit)
- composition (calcul de la composition du produit à partir des matières le
composant).
Sur ces onglets, des sous-formulaires se mettant à jour à partir de celui
des fournitures.
La partie prix, entretien et composition est moins "visité" que les premiers
onglets, j'ai donc mis ces 5 onglets sur un autre formulaire, accessible par
un bouton. Cela semble convenir aux utilisateurs. Qu'en penses-tu ?
Concernant les données, rassures-toi, lorsque je fais des resquêtes, je
sélectionne les champs qui m'intéresse mais je ne prends pas tous les champs
des tables comme je l'ai vu faire avec *.
J'ai un autre formulaire, de consultation pure, qui à mon avis demande à
être revu mais je ne sais pas comment faire. Ta suggestion de ne pas lier les
sous-formulaires au départ m'intéresse. Ce formulaire permet de choisir une
fourniture et d'obtenir à l'écran (et surtout sur le même écran), le stock
présent chez nous, le stock chez chacun des façonniers, les commandes en
cours non reçues, les commandes en cours partiellement reçues, les commandes
reçues et soldées, le reste à lancer. Pour chacun de ces éléments, j'ai
utilisé un sous-formulaire. J'aimerais donc que ces sous-formulaires
deviennent "actifs" que lorsque la fourniture est sélectionnée. La sélection
de la fourniture se fait en 4 étapes :
- choisir un fournisseur
- choisir une fourniture de ce fournisseur
- choisir une dimension de cette fourniture
- choisir un coloris pour cette fourniture et dimension.
J'utilise pour ces sélections des listes déroulantes, cela "rame" un peu
comme tu l'imagines. Ce formulaire étant très utilisé, j'aimerais l'optimiser.
Comment puis-je faire pour conditionner l'affichage des sous-formulaires que
lorsque j'ai passé les 4 étapes de sélection de ma fourniture.
Merci de ton aide et de tes conseils, ils sont les bienvenus.
A+
Je me permets d'émettre mon grain de sel dans cette discussion.
Avez-vous spécifier la version d'Access?
Pour moi, il est préférable d'être en version 2002 ou supérieure
Si ce n'est pas le cas migrer peut-être votre base.
Quel est votre serveur Windows 2000,Windows 2003, Netware Novell?
Votre serveur est-il correctement dimensionné?
-au niveau de la mémoire
-au niveau du processeur
-au niveau du nombre de verrous sur les serveurs
-surcharge réseau
Point délicat:
Le passage à une autre Base de données pour moi se justifie plutot par
le nombre d'utilisateurs connectés. 30 pour moi, c'est énorme à part en
lecture mais en ajout/ modification.
A savoir que les bases de données msaccess génère un trafic assez
conséquent sur le réseau. Surtout si les critères, jointures ne sont pas
effectuées sur des champs indexés.
Au lancement d'une requête,Msaccess (Msjet) rapatrie tous les
enregistrements en local et filtre les données en locale puis envoie le
résultat au programme demandeur.
Un "vrai" SGBD va calculer le résultat sur le serveur et renvoyer
uniquement le nombre de lignes demandées.
LA charge réseau est donc beaucoup moins importante.
A noter aussi que lorsque le matériel réseau est défectueux, il peut y
avoir un risque de corruption de la base quasiment sytematique.
Retrouver un matériel réseau défectueux sur 30 postes, n'est pas une
chose aisée...
Pour moi access est bien pour 5 postes, maxi 10 au delà même si dans la
plupart des cas ça marche, ce n'est pas une solution pérenne.
Cordialement
(Allez-y, tirez vos boulets rouges!)Bonjour Pierre,
Comme je te l'ai écris, je vais à nouveau faire le test sur une petite base
en mettant la base de code sur les PC et je vous tiendrais au courant.
J'espère que nous n'aurons pas à nouveau cette situation de blocage que nous
avons déjà connu ici.
Je ne pense pas que nos bases grossissent anormalement. Si je prends la plus
grosse, hier soir elle était à 108160 ko après compactage elle est passée à
103 500 ko. Nous sommes en pleine période de collection et l'activité sur la
base est importante donc cela me semble logique.
Concernant ma recherche de formation, cela peut-être également une
prestation. Je suis seule sur site et je pense que le contact avec quelqu'un
de bien plus qualifié que moi me ferais le plus grand bien ! Sur d'autres
systèmes dans le passé, j'ai déjà procédé ainsi et le résultat était
intéressant. Ce type de prestation doit bien exister pour Access.
Concernant le choix d'Access ici il a été motivé par plusieurs raisons:
1- lorsque je suis arrivée, il n'était pas question de développer des
applications importantes, seulement des petites donc naturellement Access que
je connaissais, l'objectif était de remplacer l'AS400 par des progiciels
2- l'achat de progiciels a été abandonné suite à de nombreux déboires avec
les sociétés de services
3- notre société est en pleine croissance et en quelques mois,
l'informatique a dû évoluer considérablement (l'ancienne informatique datait
de 20 ans sur AS400!) et surtout très rapidement
4- sur une des bases, j'ai 20 utilisateurs sur l'autre, une trentaine, je
pensais que cela ne posait pas de problème
5- le côté très pratique d'Access qui permet de transférer les bases sur un
portable et de partir à l'étranger pour visiter nos façonniers en Tunisie.
La raison qui m'a été donné pour passer à Sql Server est que la taille de ma
base principale (100000ko) posait problème. D'après mon interlocuteur, c'est
à partir de cette taille que les problèmes commencent à survenir avec Access
et qu'il faut en changer. Tisane m'a rassuré sur la taille de ma base !
Concernant le formulaire en cause, je l'ai donc divisé en deux hier. Il
s'agit d'un formulaire qui permet de créer une fiche produit. Il y avait donc
un onglet :
- général (info général sur le produit, description, marque, thème,
commentaires...)
- croquis (lien avec un .tif sur le serveur) + légende
- commentaire détaillé de conception
- fournitures le composant tous coloris
- coloris + fournitures déclinées au coloris
- commentaire proto
- calcul prix des matières
- calcul prix des fournitures
- calcul final du prix de revient
- entretien (détermination du code entretien à partir des matières composant
le produit)
- composition (calcul de la composition du produit à partir des matières le
composant).
Sur ces onglets, des sous-formulaires se mettant à jour à partir de celui
des fournitures.
La partie prix, entretien et composition est moins "visité" que les premiers
onglets, j'ai donc mis ces 5 onglets sur un autre formulaire, accessible par
un bouton. Cela semble convenir aux utilisateurs. Qu'en penses-tu ?
Concernant les données, rassures-toi, lorsque je fais des resquêtes, je
sélectionne les champs qui m'intéresse mais je ne prends pas tous les champs
des tables comme je l'ai vu faire avec *.
J'ai un autre formulaire, de consultation pure, qui à mon avis demande à
être revu mais je ne sais pas comment faire. Ta suggestion de ne pas lier les
sous-formulaires au départ m'intéresse. Ce formulaire permet de choisir une
fourniture et d'obtenir à l'écran (et surtout sur le même écran), le stock
présent chez nous, le stock chez chacun des façonniers, les commandes en
cours non reçues, les commandes en cours partiellement reçues, les commandes
reçues et soldées, le reste à lancer. Pour chacun de ces éléments, j'ai
utilisé un sous-formulaire. J'aimerais donc que ces sous-formulaires
deviennent "actifs" que lorsque la fourniture est sélectionnée. La sélection
de la fourniture se fait en 4 étapes :
- choisir un fournisseur
- choisir une fourniture de ce fournisseur
- choisir une dimension de cette fourniture
- choisir un coloris pour cette fourniture et dimension.
J'utilise pour ces sélections des listes déroulantes, cela "rame" un peu
comme tu l'imagines. Ce formulaire étant très utilisé, j'aimerais l'optimiser.
Comment puis-je faire pour conditionner l'affichage des sous-formulaires que
lorsque j'ai passé les 4 étapes de sélection de ma fourniture.
Merci de ton aide et de tes conseils, ils sont les bienvenus.
A+
Bonsoir Jerome,
Ton grain de sel est le bienvenue comme tous les autres grains de sel q ui
connaissent le sujet.
N'étant pas une pro, je cherche des infos.
La version d'Access que j'utilise est 2000, le serveur est en Windows 2 000
avec 2Go de mémoire et fonctionne plutôt vite et bien. Niveau rés eau, les
temps de transfert sont corrects et nous n'avons jusqu'ici pas de probl ème.
Quand je dis 30 utilisateurs, je pense qu'ils ne sont jamais 30 connect és
simultanément, entre 10 et 20 serait plus juste. Certains ne font que de la
consultation.
Je sais qu'Access génère beaucoup de trafic réseau comparé à d'autres bases.
Si je comprends bien, tu opterais pour une autre base de données, laq uelle ?
Mon problème est le temps. Si je décide d'abandonner Access, il fau t que je
me reforme et que je reprenne tout ce qui a été fait en plus de 2 a ns.
Le pire dans cette hypothèse est que je ne pourrais pas me consacrer à la
suite tout de suite et il y a urgence, il faut impérativement que je
développe la gestion des commandes et la facturation. Notre société évolue
vite et les programmes actuels de l'AS400 sont déjà obsolètes dep uis de
nombreuses années !
Ici, tous les utilisateurs "bidouillent" des fichiers excel dans tous l es
sens pour remplacer l'AS400 et surtout obtenir tout ce qu'il ne fait pa s et
je t'avoue que la liste est longue.
J'ai connu la même situation avec la gestion de production. Nous avon s
maintenant un outil qui correspond aux besoins de nos utilisateurs et s urtout
nous pouvons le faire évoluer. Nous commençons la 4éme collection avec ce
développement et à tous les postes nous gagnons du temps.
A +
et merci de ta participation
Bonsoir Jerome,
Ton grain de sel est le bienvenue comme tous les autres grains de sel q ui
connaissent le sujet.
N'étant pas une pro, je cherche des infos.
La version d'Access que j'utilise est 2000, le serveur est en Windows 2 000
avec 2Go de mémoire et fonctionne plutôt vite et bien. Niveau rés eau, les
temps de transfert sont corrects et nous n'avons jusqu'ici pas de probl ème.
Quand je dis 30 utilisateurs, je pense qu'ils ne sont jamais 30 connect és
simultanément, entre 10 et 20 serait plus juste. Certains ne font que de la
consultation.
Je sais qu'Access génère beaucoup de trafic réseau comparé à d'autres bases.
Si je comprends bien, tu opterais pour une autre base de données, laq uelle ?
Mon problème est le temps. Si je décide d'abandonner Access, il fau t que je
me reforme et que je reprenne tout ce qui a été fait en plus de 2 a ns.
Le pire dans cette hypothèse est que je ne pourrais pas me consacrer à la
suite tout de suite et il y a urgence, il faut impérativement que je
développe la gestion des commandes et la facturation. Notre société évolue
vite et les programmes actuels de l'AS400 sont déjà obsolètes dep uis de
nombreuses années !
Ici, tous les utilisateurs "bidouillent" des fichiers excel dans tous l es
sens pour remplacer l'AS400 et surtout obtenir tout ce qu'il ne fait pa s et
je t'avoue que la liste est longue.
J'ai connu la même situation avec la gestion de production. Nous avon s
maintenant un outil qui correspond aux besoins de nos utilisateurs et s urtout
nous pouvons le faire évoluer. Nous commençons la 4éme collection avec ce
développement et à tous les postes nous gagnons du temps.
A +
et merci de ta participation
Bonsoir Jerome,
Ton grain de sel est le bienvenue comme tous les autres grains de sel q ui
connaissent le sujet.
N'étant pas une pro, je cherche des infos.
La version d'Access que j'utilise est 2000, le serveur est en Windows 2 000
avec 2Go de mémoire et fonctionne plutôt vite et bien. Niveau rés eau, les
temps de transfert sont corrects et nous n'avons jusqu'ici pas de probl ème.
Quand je dis 30 utilisateurs, je pense qu'ils ne sont jamais 30 connect és
simultanément, entre 10 et 20 serait plus juste. Certains ne font que de la
consultation.
Je sais qu'Access génère beaucoup de trafic réseau comparé à d'autres bases.
Si je comprends bien, tu opterais pour une autre base de données, laq uelle ?
Mon problème est le temps. Si je décide d'abandonner Access, il fau t que je
me reforme et que je reprenne tout ce qui a été fait en plus de 2 a ns.
Le pire dans cette hypothèse est que je ne pourrais pas me consacrer à la
suite tout de suite et il y a urgence, il faut impérativement que je
développe la gestion des commandes et la facturation. Notre société évolue
vite et les programmes actuels de l'AS400 sont déjà obsolètes dep uis de
nombreuses années !
Ici, tous les utilisateurs "bidouillent" des fichiers excel dans tous l es
sens pour remplacer l'AS400 et surtout obtenir tout ce qu'il ne fait pa s et
je t'avoue que la liste est longue.
J'ai connu la même situation avec la gestion de production. Nous avon s
maintenant un outil qui correspond aux besoins de nos utilisateurs et s urtout
nous pouvons le faire évoluer. Nous commençons la 4éme collection avec ce
développement et à tous les postes nous gagnons du temps.
A +
et merci de ta participation
Bonjour,
Beaucoup de points soulevés:
1) Pour moi Access 2000 est la version la plus bugguée de chez Micros oft.
Avez-vous installer les services packs sur tous les postes?
2)L'environnement matériel et réseau semble correcte.
3)Changement de base de données n'est pas tout réapprendre mais il est
clair que la maintenance (quand c'est nécessaire ) est un peu plus
difficile à appréhender.
Pour le choix:
un comparatif ici:
http://fadace.developpez.com/sgbdcmp/
Mes préférences totalement subjectives:
-Sql Server (microsoft aime microsoft)
-PostGresSQL (a l'air trés robuste, installable sur Windows)
-FireBird (plus simple à administer)
En ce qui concerne le changement d'une base de données, le temps
nécessaire peut varier selon la méthode de programmation initiale ( DAO,
ADO, chaine de connexion dans une seule variable... etc)
4) Développer une gestion des commandes et des factures alors qu'il
existe tant de logiciels sur le marché !
A part une gestion spécifique je vous orienterais plutôt vers des
solutions commerciales.
Je connais assez bien le milieu du textile. (indice: recherchez dans
google "logiciel textile TAILLE COULEUR")
Je pense que vous devez travailler en taille/couleur.
ET c'est vrai qu'il y a beaucoup à faire en ce domaine.
Rien que pour la gestion des règlements, transferts comptable, je
chercherais un logiciel existant pour la facturation.
D'ailleurs, il peut être intéressant de voir quel logiciel de
comptabilité vous utilisez. Cegid, Sage...etc?
Bon Vendredi, je suis en RTT.
Je demanderais une barre de nougati la journée de "consulting".
CordialementBonsoir Jerome,
Ton grain de sel est le bienvenue comme tous les autres grains de sel
qui connaissent le sujet.
N'étant pas une pro, je cherche des infos.
La version d'Access que j'utilise est 2000, le serveur est en Windows
2000 avec 2Go de mémoire et fonctionne plutôt vite et bien. Niveau
réseau, les temps de transfert sont corrects et nous n'avons jusqu'i ci
pas de problème.
Quand je dis 30 utilisateurs, je pense qu'ils ne sont jamais 30
connectés simultanément, entre 10 et 20 serait plus juste. Certain s ne
font que de la consultation.
Je sais qu'Access génère beaucoup de trafic réseau comparé à d'autres
bases.
Si je comprends bien, tu opterais pour une autre base de données,
laquelle ?
Mon problème est le temps. Si je décide d'abandonner Access, il fa ut
que je me reforme et que je reprenne tout ce qui a été fait en plu s de
2 ans.
Le pire dans cette hypothèse est que je ne pourrais pas me consacrer à
la suite tout de suite et il y a urgence, il faut impérativement que
je développe la gestion des commandes et la facturation. Notre socié té
évolue vite et les programmes actuels de l'AS400 sont déjà obsol ètes
depuis de nombreuses années !
Ici, tous les utilisateurs "bidouillent" des fichiers excel dans tous
les sens pour remplacer l'AS400 et surtout obtenir tout ce qu'il ne
fait pas et je t'avoue que la liste est longue.
J'ai connu la même situation avec la gestion de production. Nous avo ns
maintenant un outil qui correspond aux besoins de nos utilisateurs et
surtout nous pouvons le faire évoluer. Nous commençons la 4éme
collection avec ce développement et à tous les postes nous gagnons du
temps.
A +
et merci de ta participation
Bonjour,
Beaucoup de points soulevés:
1) Pour moi Access 2000 est la version la plus bugguée de chez Micros oft.
Avez-vous installer les services packs sur tous les postes?
2)L'environnement matériel et réseau semble correcte.
3)Changement de base de données n'est pas tout réapprendre mais il est
clair que la maintenance (quand c'est nécessaire ) est un peu plus
difficile à appréhender.
Pour le choix:
un comparatif ici:
http://fadace.developpez.com/sgbdcmp/
Mes préférences totalement subjectives:
-Sql Server (microsoft aime microsoft)
-PostGresSQL (a l'air trés robuste, installable sur Windows)
-FireBird (plus simple à administer)
En ce qui concerne le changement d'une base de données, le temps
nécessaire peut varier selon la méthode de programmation initiale ( DAO,
ADO, chaine de connexion dans une seule variable... etc)
4) Développer une gestion des commandes et des factures alors qu'il
existe tant de logiciels sur le marché !
A part une gestion spécifique je vous orienterais plutôt vers des
solutions commerciales.
Je connais assez bien le milieu du textile. (indice: recherchez dans
google "logiciel textile TAILLE COULEUR")
Je pense que vous devez travailler en taille/couleur.
ET c'est vrai qu'il y a beaucoup à faire en ce domaine.
Rien que pour la gestion des règlements, transferts comptable, je
chercherais un logiciel existant pour la facturation.
D'ailleurs, il peut être intéressant de voir quel logiciel de
comptabilité vous utilisez. Cegid, Sage...etc?
Bon Vendredi, je suis en RTT.
Je demanderais une barre de nougati la journée de "consulting".
Cordialement
Bonsoir Jerome,
Ton grain de sel est le bienvenue comme tous les autres grains de sel
qui connaissent le sujet.
N'étant pas une pro, je cherche des infos.
La version d'Access que j'utilise est 2000, le serveur est en Windows
2000 avec 2Go de mémoire et fonctionne plutôt vite et bien. Niveau
réseau, les temps de transfert sont corrects et nous n'avons jusqu'i ci
pas de problème.
Quand je dis 30 utilisateurs, je pense qu'ils ne sont jamais 30
connectés simultanément, entre 10 et 20 serait plus juste. Certain s ne
font que de la consultation.
Je sais qu'Access génère beaucoup de trafic réseau comparé à d'autres
bases.
Si je comprends bien, tu opterais pour une autre base de données,
laquelle ?
Mon problème est le temps. Si je décide d'abandonner Access, il fa ut
que je me reforme et que je reprenne tout ce qui a été fait en plu s de
2 ans.
Le pire dans cette hypothèse est que je ne pourrais pas me consacrer à
la suite tout de suite et il y a urgence, il faut impérativement que
je développe la gestion des commandes et la facturation. Notre socié té
évolue vite et les programmes actuels de l'AS400 sont déjà obsol ètes
depuis de nombreuses années !
Ici, tous les utilisateurs "bidouillent" des fichiers excel dans tous
les sens pour remplacer l'AS400 et surtout obtenir tout ce qu'il ne
fait pas et je t'avoue que la liste est longue.
J'ai connu la même situation avec la gestion de production. Nous avo ns
maintenant un outil qui correspond aux besoins de nos utilisateurs et
surtout nous pouvons le faire évoluer. Nous commençons la 4éme
collection avec ce développement et à tous les postes nous gagnons du
temps.
A +
et merci de ta participation
Bonjour,
Beaucoup de points soulevés:
1) Pour moi Access 2000 est la version la plus bugguée de chez Micros oft.
Avez-vous installer les services packs sur tous les postes?
2)L'environnement matériel et réseau semble correcte.
3)Changement de base de données n'est pas tout réapprendre mais il est
clair que la maintenance (quand c'est nécessaire ) est un peu plus
difficile à appréhender.
Pour le choix:
un comparatif ici:
http://fadace.developpez.com/sgbdcmp/
Mes préférences totalement subjectives:
-Sql Server (microsoft aime microsoft)
-PostGresSQL (a l'air trés robuste, installable sur Windows)
-FireBird (plus simple à administer)
En ce qui concerne le changement d'une base de données, le temps
nécessaire peut varier selon la méthode de programmation initiale ( DAO,
ADO, chaine de connexion dans une seule variable... etc)
4) Développer une gestion des commandes et des factures alors qu'il
existe tant de logiciels sur le marché !
A part une gestion spécifique je vous orienterais plutôt vers des
solutions commerciales.
Je connais assez bien le milieu du textile. (indice: recherchez dans
google "logiciel textile TAILLE COULEUR")
Je pense que vous devez travailler en taille/couleur.
ET c'est vrai qu'il y a beaucoup à faire en ce domaine.
Rien que pour la gestion des règlements, transferts comptable, je
chercherais un logiciel existant pour la facturation.
D'ailleurs, il peut être intéressant de voir quel logiciel de
comptabilité vous utilisez. Cegid, Sage...etc?
Bon Vendredi, je suis en RTT.
Je demanderais une barre de nougati la journée de "consulting".
CordialementBonsoir Jerome,
Ton grain de sel est le bienvenue comme tous les autres grains de sel
qui connaissent le sujet.
N'étant pas une pro, je cherche des infos.
La version d'Access que j'utilise est 2000, le serveur est en Windows
2000 avec 2Go de mémoire et fonctionne plutôt vite et bien. Niveau
réseau, les temps de transfert sont corrects et nous n'avons jusqu'i ci
pas de problème.
Quand je dis 30 utilisateurs, je pense qu'ils ne sont jamais 30
connectés simultanément, entre 10 et 20 serait plus juste. Certain s ne
font que de la consultation.
Je sais qu'Access génère beaucoup de trafic réseau comparé à d'autres
bases.
Si je comprends bien, tu opterais pour une autre base de données,
laquelle ?
Mon problème est le temps. Si je décide d'abandonner Access, il fa ut
que je me reforme et que je reprenne tout ce qui a été fait en plu s de
2 ans.
Le pire dans cette hypothèse est que je ne pourrais pas me consacrer à
la suite tout de suite et il y a urgence, il faut impérativement que
je développe la gestion des commandes et la facturation. Notre socié té
évolue vite et les programmes actuels de l'AS400 sont déjà obsol ètes
depuis de nombreuses années !
Ici, tous les utilisateurs "bidouillent" des fichiers excel dans tous
les sens pour remplacer l'AS400 et surtout obtenir tout ce qu'il ne
fait pas et je t'avoue que la liste est longue.
J'ai connu la même situation avec la gestion de production. Nous avo ns
maintenant un outil qui correspond aux besoins de nos utilisateurs et
surtout nous pouvons le faire évoluer. Nous commençons la 4éme
collection avec ce développement et à tous les postes nous gagnons du
temps.
A +
et merci de ta participation
Je me réponds à moi-même, d'autres pistes!
j'ai réfléchi à votre problème.
Une solution serait peut-être d'archiver certaines données.
Je pense que vous devez travailler par saison donc, il pourrait être
rêvélateur d'archiver les données des anciennes saisons afin de ne
garder que l'utile dans votre base.
2)un lien intéressant sur la maintenance d'une base Access.
http://support.microsoft.com/kb/300216/frBonjour,
Beaucoup de points soulevés:
1) Pour moi Access 2000 est la version la plus bugguée de chez Microsoft.
Avez-vous installer les services packs sur tous les postes?
2)L'environnement matériel et réseau semble correcte.
3)Changement de base de données n'est pas tout réapprendre mais il est
clair que la maintenance (quand c'est nécessaire ) est un peu plus
difficile à appréhender.
Pour le choix:
un comparatif ici:
http://fadace.developpez.com/sgbdcmp/
Mes préférences totalement subjectives:
-Sql Server (microsoft aime microsoft)
-PostGresSQL (a l'air trés robuste, installable sur Windows)
-FireBird (plus simple à administer)
En ce qui concerne le changement d'une base de données, le temps
nécessaire peut varier selon la méthode de programmation initiale (DAO,
ADO, chaine de connexion dans une seule variable... etc)
4) Développer une gestion des commandes et des factures alors qu'il
existe tant de logiciels sur le marché !
A part une gestion spécifique je vous orienterais plutôt vers des
solutions commerciales.
Je connais assez bien le milieu du textile. (indice: recherchez dans
google "logiciel textile TAILLE COULEUR")
Je pense que vous devez travailler en taille/couleur.
ET c'est vrai qu'il y a beaucoup à faire en ce domaine.
Rien que pour la gestion des règlements, transferts comptable, je
chercherais un logiciel existant pour la facturation.
D'ailleurs, il peut être intéressant de voir quel logiciel de
comptabilité vous utilisez. Cegid, Sage...etc?
Bon Vendredi, je suis en RTT.
Je demanderais une barre de nougati la journée de "consulting".
CordialementBonsoir Jerome,
Ton grain de sel est le bienvenue comme tous les autres grains de sel
qui connaissent le sujet.
N'étant pas une pro, je cherche des infos.
La version d'Access que j'utilise est 2000, le serveur est en Windows
2000 avec 2Go de mémoire et fonctionne plutôt vite et bien. Niveau
réseau, les temps de transfert sont corrects et nous n'avons jusqu'ici
pas de problème.
Quand je dis 30 utilisateurs, je pense qu'ils ne sont jamais 30
connectés simultanément, entre 10 et 20 serait plus juste. Certains ne
font que de la consultation.
Je sais qu'Access génère beaucoup de trafic réseau comparé à d'autres
bases.
Si je comprends bien, tu opterais pour une autre base de données,
laquelle ?
Mon problème est le temps. Si je décide d'abandonner Access, il faut
que je me reforme et que je reprenne tout ce qui a été fait en plus de
2 ans.
Le pire dans cette hypothèse est que je ne pourrais pas me consacrer à
la suite tout de suite et il y a urgence, il faut impérativement que
je développe la gestion des commandes et la facturation. Notre société
évolue vite et les programmes actuels de l'AS400 sont déjà obsolètes
depuis de nombreuses années !
Ici, tous les utilisateurs "bidouillent" des fichiers excel dans tous
les sens pour remplacer l'AS400 et surtout obtenir tout ce qu'il ne
fait pas et je t'avoue que la liste est longue.
J'ai connu la même situation avec la gestion de production. Nous avons
maintenant un outil qui correspond aux besoins de nos utilisateurs et
surtout nous pouvons le faire évoluer. Nous commençons la 4éme
collection avec ce développement et à tous les postes nous gagnons du
temps.
A +
et merci de ta participation
Je me réponds à moi-même, d'autres pistes!
j'ai réfléchi à votre problème.
Une solution serait peut-être d'archiver certaines données.
Je pense que vous devez travailler par saison donc, il pourrait être
rêvélateur d'archiver les données des anciennes saisons afin de ne
garder que l'utile dans votre base.
2)un lien intéressant sur la maintenance d'une base Access.
http://support.microsoft.com/kb/300216/fr
Bonjour,
Beaucoup de points soulevés:
1) Pour moi Access 2000 est la version la plus bugguée de chez Microsoft.
Avez-vous installer les services packs sur tous les postes?
2)L'environnement matériel et réseau semble correcte.
3)Changement de base de données n'est pas tout réapprendre mais il est
clair que la maintenance (quand c'est nécessaire ) est un peu plus
difficile à appréhender.
Pour le choix:
un comparatif ici:
http://fadace.developpez.com/sgbdcmp/
Mes préférences totalement subjectives:
-Sql Server (microsoft aime microsoft)
-PostGresSQL (a l'air trés robuste, installable sur Windows)
-FireBird (plus simple à administer)
En ce qui concerne le changement d'une base de données, le temps
nécessaire peut varier selon la méthode de programmation initiale (DAO,
ADO, chaine de connexion dans une seule variable... etc)
4) Développer une gestion des commandes et des factures alors qu'il
existe tant de logiciels sur le marché !
A part une gestion spécifique je vous orienterais plutôt vers des
solutions commerciales.
Je connais assez bien le milieu du textile. (indice: recherchez dans
google "logiciel textile TAILLE COULEUR")
Je pense que vous devez travailler en taille/couleur.
ET c'est vrai qu'il y a beaucoup à faire en ce domaine.
Rien que pour la gestion des règlements, transferts comptable, je
chercherais un logiciel existant pour la facturation.
D'ailleurs, il peut être intéressant de voir quel logiciel de
comptabilité vous utilisez. Cegid, Sage...etc?
Bon Vendredi, je suis en RTT.
Je demanderais une barre de nougati la journée de "consulting".
Cordialement
Bonsoir Jerome,
Ton grain de sel est le bienvenue comme tous les autres grains de sel
qui connaissent le sujet.
N'étant pas une pro, je cherche des infos.
La version d'Access que j'utilise est 2000, le serveur est en Windows
2000 avec 2Go de mémoire et fonctionne plutôt vite et bien. Niveau
réseau, les temps de transfert sont corrects et nous n'avons jusqu'ici
pas de problème.
Quand je dis 30 utilisateurs, je pense qu'ils ne sont jamais 30
connectés simultanément, entre 10 et 20 serait plus juste. Certains ne
font que de la consultation.
Je sais qu'Access génère beaucoup de trafic réseau comparé à d'autres
bases.
Si je comprends bien, tu opterais pour une autre base de données,
laquelle ?
Mon problème est le temps. Si je décide d'abandonner Access, il faut
que je me reforme et que je reprenne tout ce qui a été fait en plus de
2 ans.
Le pire dans cette hypothèse est que je ne pourrais pas me consacrer à
la suite tout de suite et il y a urgence, il faut impérativement que
je développe la gestion des commandes et la facturation. Notre société
évolue vite et les programmes actuels de l'AS400 sont déjà obsolètes
depuis de nombreuses années !
Ici, tous les utilisateurs "bidouillent" des fichiers excel dans tous
les sens pour remplacer l'AS400 et surtout obtenir tout ce qu'il ne
fait pas et je t'avoue que la liste est longue.
J'ai connu la même situation avec la gestion de production. Nous avons
maintenant un outil qui correspond aux besoins de nos utilisateurs et
surtout nous pouvons le faire évoluer. Nous commençons la 4éme
collection avec ce développement et à tous les postes nous gagnons du
temps.
A +
et merci de ta participation
Je me réponds à moi-même, d'autres pistes!
j'ai réfléchi à votre problème.
Une solution serait peut-être d'archiver certaines données.
Je pense que vous devez travailler par saison donc, il pourrait être
rêvélateur d'archiver les données des anciennes saisons afin de ne
garder que l'utile dans votre base.
2)un lien intéressant sur la maintenance d'une base Access.
http://support.microsoft.com/kb/300216/frBonjour,
Beaucoup de points soulevés:
1) Pour moi Access 2000 est la version la plus bugguée de chez Microsoft.
Avez-vous installer les services packs sur tous les postes?
2)L'environnement matériel et réseau semble correcte.
3)Changement de base de données n'est pas tout réapprendre mais il est
clair que la maintenance (quand c'est nécessaire ) est un peu plus
difficile à appréhender.
Pour le choix:
un comparatif ici:
http://fadace.developpez.com/sgbdcmp/
Mes préférences totalement subjectives:
-Sql Server (microsoft aime microsoft)
-PostGresSQL (a l'air trés robuste, installable sur Windows)
-FireBird (plus simple à administer)
En ce qui concerne le changement d'une base de données, le temps
nécessaire peut varier selon la méthode de programmation initiale (DAO,
ADO, chaine de connexion dans une seule variable... etc)
4) Développer une gestion des commandes et des factures alors qu'il
existe tant de logiciels sur le marché !
A part une gestion spécifique je vous orienterais plutôt vers des
solutions commerciales.
Je connais assez bien le milieu du textile. (indice: recherchez dans
google "logiciel textile TAILLE COULEUR")
Je pense que vous devez travailler en taille/couleur.
ET c'est vrai qu'il y a beaucoup à faire en ce domaine.
Rien que pour la gestion des règlements, transferts comptable, je
chercherais un logiciel existant pour la facturation.
D'ailleurs, il peut être intéressant de voir quel logiciel de
comptabilité vous utilisez. Cegid, Sage...etc?
Bon Vendredi, je suis en RTT.
Je demanderais une barre de nougati la journée de "consulting".
CordialementBonsoir Jerome,
Ton grain de sel est le bienvenue comme tous les autres grains de sel
qui connaissent le sujet.
N'étant pas une pro, je cherche des infos.
La version d'Access que j'utilise est 2000, le serveur est en Windows
2000 avec 2Go de mémoire et fonctionne plutôt vite et bien. Niveau
réseau, les temps de transfert sont corrects et nous n'avons jusqu'ici
pas de problème.
Quand je dis 30 utilisateurs, je pense qu'ils ne sont jamais 30
connectés simultanément, entre 10 et 20 serait plus juste. Certains ne
font que de la consultation.
Je sais qu'Access génère beaucoup de trafic réseau comparé à d'autres
bases.
Si je comprends bien, tu opterais pour une autre base de données,
laquelle ?
Mon problème est le temps. Si je décide d'abandonner Access, il faut
que je me reforme et que je reprenne tout ce qui a été fait en plus de
2 ans.
Le pire dans cette hypothèse est que je ne pourrais pas me consacrer à
la suite tout de suite et il y a urgence, il faut impérativement que
je développe la gestion des commandes et la facturation. Notre société
évolue vite et les programmes actuels de l'AS400 sont déjà obsolètes
depuis de nombreuses années !
Ici, tous les utilisateurs "bidouillent" des fichiers excel dans tous
les sens pour remplacer l'AS400 et surtout obtenir tout ce qu'il ne
fait pas et je t'avoue que la liste est longue.
J'ai connu la même situation avec la gestion de production. Nous avons
maintenant un outil qui correspond aux besoins de nos utilisateurs et
surtout nous pouvons le faire évoluer. Nous commençons la 4éme
collection avec ce développement et à tous les postes nous gagnons du
temps.
A +
et merci de ta participation
Bonjour Jerome,
Oui, j'ai installé sur tous les postes les services pack en particuli er le 3.
Je vais effectivement faire une base d'archivage, nous démarrons notr e 4ème
saisons avec cette base. Lorsque nous en serons à la 5ème, j'archiv erais la
1ère.
J'aimerais laisser 4 saisons en ligne, si cela est possible.
Nous travaillons en produit/couleur/taille.
Effectivement l'idée de départ était de tout informatiser par pro giciel.
D'ailleurs j'ai été embauchée pour cela et pas pour développer. Lorsque je
suis arrivée, notre PDG avait déjà acheté la paie, la compta, l a prise
d'ordres sur portable pour les représentants et le logiciel caisse po ur nos
boutiques (back et front office). Les boutiques étaient déjà inst allées, la
prise d'ordres également mais avec beaucoup de soucis et de besoins n on
satisfaits. Tu l'a deviné, ces logiciels proviennent de CEGID. Ma pre mière
mission fut de mettre en place la paie et cela n'a pas été simple c ar elle ne
répond pas vraiement à nos besoins. Nous avons intéressement et
participation, Cegid ne pouvait pas mettre en place alors que le produi t nous
avait été vendu avec ces modules ! Résultat développement d'une base Access
pour compléter. La compta, même si ce n'est pas parfais, elle fonc tionne.
Notre PDG a alors découvert que je pouvais développer et cela lui a donné des
idées !
Lorsqu'il a été question de remplacer la gestion production, il n'a pas
hésité une seconde, il m'a demandé de la développer au plus vit e. Nous avons
donc aujourd'hui une GP qui part du dossier de style de nos stylistes p our
aller jusqu'aux nomenclatures, aux commandes fournitures, aux expédit ions
chez les façonniers et a leur suivi, en passant par le calcul des pri x de
revient ... bref, ce que nous n'arrivions pas à trouver sur le marché .
Surtout ce qui intéresse notre PDG, c'est que nous sommes libre de fa ire des
évolutions quand nous le souhaitons. Nous avons demandé certaines é volutions
à Cegid concernant la prise d'ordres et la paie, deux ans après nou s
attendons encore, ce qui fache notre PDG !
Au 15 juillet, je mets en place notre prise d'ordres "made in Pause Caf é"
c'est à dire développement interne pour remplacer le progiciel de C égid qui
ne nous convient pas.
Pour te donner un seul exemple d'une demande faite à Cegid depuis plu s de 2
ans et non satisfaite : lorsque nous récupérons les commandes prove nant des
portables des représentants, nous voudrions pouvoir sortir un état de date à
date. Impossible, on obtient seulement un état à la saison ou il fa ut
sélectionner les commandes une par une. Toi qui connaît comme moi l e
développement de ce type de fonction, tu ne vas pas me dire que c'est
impossible ou que c'est un travail important que de mettre une sélect ion de
date dans un état et de remonter que les commandes prises dans cette
fourchette de dates !
Pour la gestion commerciale, notre PDG n'a pas hésité et la encore, il ne
veut pas subir Cegid ou une autre société, il préfère notre ind épendance.
Donc développement. La contre partie du développement est que je su is très
chargée comme tu l'imagines, surtout que le quotidien est a gérer é galement.
Cependant je comprends la position de notre PDG et j'avoue que j'ai bie n du
mal a lui avancer des arguments positifs qui pourrait le faire changer d'avis
puisqu'à chaque fois qu'il veut quelque chose sur les progiciels Cegi d c'est
souvent compliqué, voir impossible de lui donner. D'ailleurs il me le
rappelle souvent.
Au finale, nous devrions garder en progiciel : la paie (avec un complé ment
de développement sur une base Access), la compta et notre réseau de boutiques
où la encore nous ne sommes pas vraiment satisfait !
En développement, nous aurons : la gestion de production, la prise d' ordres
et la gestion commerciale (inclus la facturation, les expéditions ... )
En conclusion, je souhaite progresser en optimisation de mes bases afin de
continuer nos projets et comme je l'ai déjà écris, il y a urgence . Nous nous
développons (cela n'est pas un secret) très vite à l'export et no tre système
actuel, sur AS400, ne sait pas ce que c'est l'export !!!
Je n'exclus pas de passer à SQL server mais pour cela, il me faudra d e la
formation, je ne veux pas m'improviser. Le problème est qu'à Troyes , je ne
trouve personne pour me former, on me conseille bien sûr d'aller à Paris mais
pour le moment, je n'ai pas le temps matériel !
Je te pose la question que j'ai posé à Pierre : connais-tu un prest ataire
qui pourrait m'assister dans l'optimisation de mes bases ? Cela me ferr a le
plus grand bien de travailler avec une personne largement plus compét ente que
moi.
Merci pour tes liens, bonne journée.
Je fais comment pour envoyer une barre de nougati par internet !!??
A +
Bonjour Jerome,
Oui, j'ai installé sur tous les postes les services pack en particuli er le 3.
Je vais effectivement faire une base d'archivage, nous démarrons notr e 4ème
saisons avec cette base. Lorsque nous en serons à la 5ème, j'archiv erais la
1ère.
J'aimerais laisser 4 saisons en ligne, si cela est possible.
Nous travaillons en produit/couleur/taille.
Effectivement l'idée de départ était de tout informatiser par pro giciel.
D'ailleurs j'ai été embauchée pour cela et pas pour développer. Lorsque je
suis arrivée, notre PDG avait déjà acheté la paie, la compta, l a prise
d'ordres sur portable pour les représentants et le logiciel caisse po ur nos
boutiques (back et front office). Les boutiques étaient déjà inst allées, la
prise d'ordres également mais avec beaucoup de soucis et de besoins n on
satisfaits. Tu l'a deviné, ces logiciels proviennent de CEGID. Ma pre mière
mission fut de mettre en place la paie et cela n'a pas été simple c ar elle ne
répond pas vraiement à nos besoins. Nous avons intéressement et
participation, Cegid ne pouvait pas mettre en place alors que le produi t nous
avait été vendu avec ces modules ! Résultat développement d'une base Access
pour compléter. La compta, même si ce n'est pas parfais, elle fonc tionne.
Notre PDG a alors découvert que je pouvais développer et cela lui a donné des
idées !
Lorsqu'il a été question de remplacer la gestion production, il n'a pas
hésité une seconde, il m'a demandé de la développer au plus vit e. Nous avons
donc aujourd'hui une GP qui part du dossier de style de nos stylistes p our
aller jusqu'aux nomenclatures, aux commandes fournitures, aux expédit ions
chez les façonniers et a leur suivi, en passant par le calcul des pri x de
revient ... bref, ce que nous n'arrivions pas à trouver sur le marché .
Surtout ce qui intéresse notre PDG, c'est que nous sommes libre de fa ire des
évolutions quand nous le souhaitons. Nous avons demandé certaines é volutions
à Cegid concernant la prise d'ordres et la paie, deux ans après nou s
attendons encore, ce qui fache notre PDG !
Au 15 juillet, je mets en place notre prise d'ordres "made in Pause Caf é"
c'est à dire développement interne pour remplacer le progiciel de C égid qui
ne nous convient pas.
Pour te donner un seul exemple d'une demande faite à Cegid depuis plu s de 2
ans et non satisfaite : lorsque nous récupérons les commandes prove nant des
portables des représentants, nous voudrions pouvoir sortir un état de date à
date. Impossible, on obtient seulement un état à la saison ou il fa ut
sélectionner les commandes une par une. Toi qui connaît comme moi l e
développement de ce type de fonction, tu ne vas pas me dire que c'est
impossible ou que c'est un travail important que de mettre une sélect ion de
date dans un état et de remonter que les commandes prises dans cette
fourchette de dates !
Pour la gestion commerciale, notre PDG n'a pas hésité et la encore, il ne
veut pas subir Cegid ou une autre société, il préfère notre ind épendance.
Donc développement. La contre partie du développement est que je su is très
chargée comme tu l'imagines, surtout que le quotidien est a gérer é galement.
Cependant je comprends la position de notre PDG et j'avoue que j'ai bie n du
mal a lui avancer des arguments positifs qui pourrait le faire changer d'avis
puisqu'à chaque fois qu'il veut quelque chose sur les progiciels Cegi d c'est
souvent compliqué, voir impossible de lui donner. D'ailleurs il me le
rappelle souvent.
Au finale, nous devrions garder en progiciel : la paie (avec un complé ment
de développement sur une base Access), la compta et notre réseau de boutiques
où la encore nous ne sommes pas vraiment satisfait !
En développement, nous aurons : la gestion de production, la prise d' ordres
et la gestion commerciale (inclus la facturation, les expéditions ... )
En conclusion, je souhaite progresser en optimisation de mes bases afin de
continuer nos projets et comme je l'ai déjà écris, il y a urgence . Nous nous
développons (cela n'est pas un secret) très vite à l'export et no tre système
actuel, sur AS400, ne sait pas ce que c'est l'export !!!
Je n'exclus pas de passer à SQL server mais pour cela, il me faudra d e la
formation, je ne veux pas m'improviser. Le problème est qu'à Troyes , je ne
trouve personne pour me former, on me conseille bien sûr d'aller à Paris mais
pour le moment, je n'ai pas le temps matériel !
Je te pose la question que j'ai posé à Pierre : connais-tu un prest ataire
qui pourrait m'assister dans l'optimisation de mes bases ? Cela me ferr a le
plus grand bien de travailler avec une personne largement plus compét ente que
moi.
Merci pour tes liens, bonne journée.
Je fais comment pour envoyer une barre de nougati par internet !!??
A +
Bonjour Jerome,
Oui, j'ai installé sur tous les postes les services pack en particuli er le 3.
Je vais effectivement faire une base d'archivage, nous démarrons notr e 4ème
saisons avec cette base. Lorsque nous en serons à la 5ème, j'archiv erais la
1ère.
J'aimerais laisser 4 saisons en ligne, si cela est possible.
Nous travaillons en produit/couleur/taille.
Effectivement l'idée de départ était de tout informatiser par pro giciel.
D'ailleurs j'ai été embauchée pour cela et pas pour développer. Lorsque je
suis arrivée, notre PDG avait déjà acheté la paie, la compta, l a prise
d'ordres sur portable pour les représentants et le logiciel caisse po ur nos
boutiques (back et front office). Les boutiques étaient déjà inst allées, la
prise d'ordres également mais avec beaucoup de soucis et de besoins n on
satisfaits. Tu l'a deviné, ces logiciels proviennent de CEGID. Ma pre mière
mission fut de mettre en place la paie et cela n'a pas été simple c ar elle ne
répond pas vraiement à nos besoins. Nous avons intéressement et
participation, Cegid ne pouvait pas mettre en place alors que le produi t nous
avait été vendu avec ces modules ! Résultat développement d'une base Access
pour compléter. La compta, même si ce n'est pas parfais, elle fonc tionne.
Notre PDG a alors découvert que je pouvais développer et cela lui a donné des
idées !
Lorsqu'il a été question de remplacer la gestion production, il n'a pas
hésité une seconde, il m'a demandé de la développer au plus vit e. Nous avons
donc aujourd'hui une GP qui part du dossier de style de nos stylistes p our
aller jusqu'aux nomenclatures, aux commandes fournitures, aux expédit ions
chez les façonniers et a leur suivi, en passant par le calcul des pri x de
revient ... bref, ce que nous n'arrivions pas à trouver sur le marché .
Surtout ce qui intéresse notre PDG, c'est que nous sommes libre de fa ire des
évolutions quand nous le souhaitons. Nous avons demandé certaines é volutions
à Cegid concernant la prise d'ordres et la paie, deux ans après nou s
attendons encore, ce qui fache notre PDG !
Au 15 juillet, je mets en place notre prise d'ordres "made in Pause Caf é"
c'est à dire développement interne pour remplacer le progiciel de C égid qui
ne nous convient pas.
Pour te donner un seul exemple d'une demande faite à Cegid depuis plu s de 2
ans et non satisfaite : lorsque nous récupérons les commandes prove nant des
portables des représentants, nous voudrions pouvoir sortir un état de date à
date. Impossible, on obtient seulement un état à la saison ou il fa ut
sélectionner les commandes une par une. Toi qui connaît comme moi l e
développement de ce type de fonction, tu ne vas pas me dire que c'est
impossible ou que c'est un travail important que de mettre une sélect ion de
date dans un état et de remonter que les commandes prises dans cette
fourchette de dates !
Pour la gestion commerciale, notre PDG n'a pas hésité et la encore, il ne
veut pas subir Cegid ou une autre société, il préfère notre ind épendance.
Donc développement. La contre partie du développement est que je su is très
chargée comme tu l'imagines, surtout que le quotidien est a gérer é galement.
Cependant je comprends la position de notre PDG et j'avoue que j'ai bie n du
mal a lui avancer des arguments positifs qui pourrait le faire changer d'avis
puisqu'à chaque fois qu'il veut quelque chose sur les progiciels Cegi d c'est
souvent compliqué, voir impossible de lui donner. D'ailleurs il me le
rappelle souvent.
Au finale, nous devrions garder en progiciel : la paie (avec un complé ment
de développement sur une base Access), la compta et notre réseau de boutiques
où la encore nous ne sommes pas vraiment satisfait !
En développement, nous aurons : la gestion de production, la prise d' ordres
et la gestion commerciale (inclus la facturation, les expéditions ... )
En conclusion, je souhaite progresser en optimisation de mes bases afin de
continuer nos projets et comme je l'ai déjà écris, il y a urgence . Nous nous
développons (cela n'est pas un secret) très vite à l'export et no tre système
actuel, sur AS400, ne sait pas ce que c'est l'export !!!
Je n'exclus pas de passer à SQL server mais pour cela, il me faudra d e la
formation, je ne veux pas m'improviser. Le problème est qu'à Troyes , je ne
trouve personne pour me former, on me conseille bien sûr d'aller à Paris mais
pour le moment, je n'ai pas le temps matériel !
Je te pose la question que j'ai posé à Pierre : connais-tu un prest ataire
qui pourrait m'assister dans l'optimisation de mes bases ? Cela me ferr a le
plus grand bien de travailler avec une personne largement plus compét ente que
moi.
Merci pour tes liens, bonne journée.
Je fais comment pour envoyer une barre de nougati par internet !!??
A +
Comme je comprends bien tout ça.
1) Un éditeur de logiciel ne modifiera jamais son logiciel en fonction
d'une demande d'un client.
C'est plutôt une démarche globale et si jamais une mise à jour (payante
bien sur) vous rends l'utilisation plus confortable. Tant mieux !
2)Le métier textile est très délicat et très particulier , je ne sais
pas s'il existe un logiciel qui rentre dans les clous pour tout le
monde. La gestion notamment du négoce, façonnier etc est propre à chacun
quasiment.
3) Pour infos, nous préférons se baser sur une solution de gestion
commerciale éprouvée mais avec la base ouverte (SAGE Lignee100 version
SQL SERVER pour ne pas la citer) afin de ne pas gérer tous les points
délicats:
multi devises, multi depots, multi reglements, gestion composantes,
nomenclatures, statistiques...etc, etc !!!
Grâce à l'ODBC, on peut mettre à jour les éléments sans trop se planter.
4) Pour une formation ou un support, c'est vrai que tu parais seule au
monde sur ce projet, alors le spécifique c'est bien mais il faut quand
même prendre ces précautions...
Il me semble étonnant de ne pas trouver de prestataire à Troyes.
5)Revenons à Ms access sinon on va se faire virer !
Pour moi, il faut clairement passer à SQL SERVER vu l'évolution du
projet, plutôt que de tout refaire à la fin de la prise de commande et
de la facturation.
Ou alors commencer la facturation en SQL SERVER et une fois Ok, passer
la GPAO en SQL SERVER.
6) Je suis sur Angers et Troyes est trop loin de notre Domaine
d'intervention
7) Demande une augmentation ma pauvre ;)Bonjour Jerome,
Oui, j'ai installé sur tous les postes les services pack en particulier le 3.
Je vais effectivement faire une base d'archivage, nous démarrons notre 4ème
saisons avec cette base. Lorsque nous en serons à la 5ème, j'archiverais la
1ère.
J'aimerais laisser 4 saisons en ligne, si cela est possible.
Nous travaillons en produit/couleur/taille.
Effectivement l'idée de départ était de tout informatiser par progiciel.
D'ailleurs j'ai été embauchée pour cela et pas pour développer. Lorsque je
suis arrivée, notre PDG avait déjà acheté la paie, la compta, la prise
d'ordres sur portable pour les représentants et le logiciel caisse pour nos
boutiques (back et front office). Les boutiques étaient déjà installées, la
prise d'ordres également mais avec beaucoup de soucis et de besoins non
satisfaits. Tu l'a deviné, ces logiciels proviennent de CEGID. Ma première
mission fut de mettre en place la paie et cela n'a pas été simple car elle ne
répond pas vraiement à nos besoins. Nous avons intéressement et
participation, Cegid ne pouvait pas mettre en place alors que le produit nous
avait été vendu avec ces modules ! Résultat développement d'une base Access
pour compléter. La compta, même si ce n'est pas parfais, elle fonctionne.
Notre PDG a alors découvert que je pouvais développer et cela lui a donné des
idées !
Lorsqu'il a été question de remplacer la gestion production, il n'a pas
hésité une seconde, il m'a demandé de la développer au plus vite. Nous avons
donc aujourd'hui une GP qui part du dossier de style de nos stylistes pour
aller jusqu'aux nomenclatures, aux commandes fournitures, aux expéditions
chez les façonniers et a leur suivi, en passant par le calcul des prix de
revient ... bref, ce que nous n'arrivions pas à trouver sur le marché.
Surtout ce qui intéresse notre PDG, c'est que nous sommes libre de faire des
évolutions quand nous le souhaitons. Nous avons demandé certaines évolutions
à Cegid concernant la prise d'ordres et la paie, deux ans après nous
attendons encore, ce qui fache notre PDG !
Au 15 juillet, je mets en place notre prise d'ordres "made in Pause Café"
c'est à dire développement interne pour remplacer le progiciel de Cégid qui
ne nous convient pas.
Pour te donner un seul exemple d'une demande faite à Cegid depuis plus de 2
ans et non satisfaite : lorsque nous récupérons les commandes provenant des
portables des représentants, nous voudrions pouvoir sortir un état de date à
date. Impossible, on obtient seulement un état à la saison ou il faut
sélectionner les commandes une par une. Toi qui connaît comme moi le
développement de ce type de fonction, tu ne vas pas me dire que c'est
impossible ou que c'est un travail important que de mettre une sélection de
date dans un état et de remonter que les commandes prises dans cette
fourchette de dates !
Pour la gestion commerciale, notre PDG n'a pas hésité et la encore, il ne
veut pas subir Cegid ou une autre société, il préfère notre indépendance.
Donc développement. La contre partie du développement est que je suis très
chargée comme tu l'imagines, surtout que le quotidien est a gérer également.
Cependant je comprends la position de notre PDG et j'avoue que j'ai bien du
mal a lui avancer des arguments positifs qui pourrait le faire changer d'avis
puisqu'à chaque fois qu'il veut quelque chose sur les progiciels Cegid c'est
souvent compliqué, voir impossible de lui donner. D'ailleurs il me le
rappelle souvent.
Au finale, nous devrions garder en progiciel : la paie (avec un complément
de développement sur une base Access), la compta et notre réseau de boutiques
où la encore nous ne sommes pas vraiment satisfait !
En développement, nous aurons : la gestion de production, la prise d'ordres
et la gestion commerciale (inclus la facturation, les expéditions ...)
En conclusion, je souhaite progresser en optimisation de mes bases afin de
continuer nos projets et comme je l'ai déjà écris, il y a urgence. Nous nous
développons (cela n'est pas un secret) très vite à l'export et notre système
actuel, sur AS400, ne sait pas ce que c'est l'export !!!
Je n'exclus pas de passer à SQL server mais pour cela, il me faudra de la
formation, je ne veux pas m'improviser. Le problème est qu'à Troyes, je ne
trouve personne pour me former, on me conseille bien sûr d'aller à Paris mais
pour le moment, je n'ai pas le temps matériel !
Je te pose la question que j'ai posé à Pierre : connais-tu un prestataire
qui pourrait m'assister dans l'optimisation de mes bases ? Cela me ferra le
plus grand bien de travailler avec une personne largement plus compétente que
moi.
Merci pour tes liens, bonne journée.
Je fais comment pour envoyer une barre de nougati par internet !!??
A +
Comme je comprends bien tout ça.
1) Un éditeur de logiciel ne modifiera jamais son logiciel en fonction
d'une demande d'un client.
C'est plutôt une démarche globale et si jamais une mise à jour (payante
bien sur) vous rends l'utilisation plus confortable. Tant mieux !
2)Le métier textile est très délicat et très particulier , je ne sais
pas s'il existe un logiciel qui rentre dans les clous pour tout le
monde. La gestion notamment du négoce, façonnier etc est propre à chacun
quasiment.
3) Pour infos, nous préférons se baser sur une solution de gestion
commerciale éprouvée mais avec la base ouverte (SAGE Lignee100 version
SQL SERVER pour ne pas la citer) afin de ne pas gérer tous les points
délicats:
multi devises, multi depots, multi reglements, gestion composantes,
nomenclatures, statistiques...etc, etc !!!
Grâce à l'ODBC, on peut mettre à jour les éléments sans trop se planter.
4) Pour une formation ou un support, c'est vrai que tu parais seule au
monde sur ce projet, alors le spécifique c'est bien mais il faut quand
même prendre ces précautions...
Il me semble étonnant de ne pas trouver de prestataire à Troyes.
5)Revenons à Ms access sinon on va se faire virer !
Pour moi, il faut clairement passer à SQL SERVER vu l'évolution du
projet, plutôt que de tout refaire à la fin de la prise de commande et
de la facturation.
Ou alors commencer la facturation en SQL SERVER et une fois Ok, passer
la GPAO en SQL SERVER.
6) Je suis sur Angers et Troyes est trop loin de notre Domaine
d'intervention
7) Demande une augmentation ma pauvre ;)
Bonjour Jerome,
Oui, j'ai installé sur tous les postes les services pack en particulier le 3.
Je vais effectivement faire une base d'archivage, nous démarrons notre 4ème
saisons avec cette base. Lorsque nous en serons à la 5ème, j'archiverais la
1ère.
J'aimerais laisser 4 saisons en ligne, si cela est possible.
Nous travaillons en produit/couleur/taille.
Effectivement l'idée de départ était de tout informatiser par progiciel.
D'ailleurs j'ai été embauchée pour cela et pas pour développer. Lorsque je
suis arrivée, notre PDG avait déjà acheté la paie, la compta, la prise
d'ordres sur portable pour les représentants et le logiciel caisse pour nos
boutiques (back et front office). Les boutiques étaient déjà installées, la
prise d'ordres également mais avec beaucoup de soucis et de besoins non
satisfaits. Tu l'a deviné, ces logiciels proviennent de CEGID. Ma première
mission fut de mettre en place la paie et cela n'a pas été simple car elle ne
répond pas vraiement à nos besoins. Nous avons intéressement et
participation, Cegid ne pouvait pas mettre en place alors que le produit nous
avait été vendu avec ces modules ! Résultat développement d'une base Access
pour compléter. La compta, même si ce n'est pas parfais, elle fonctionne.
Notre PDG a alors découvert que je pouvais développer et cela lui a donné des
idées !
Lorsqu'il a été question de remplacer la gestion production, il n'a pas
hésité une seconde, il m'a demandé de la développer au plus vite. Nous avons
donc aujourd'hui une GP qui part du dossier de style de nos stylistes pour
aller jusqu'aux nomenclatures, aux commandes fournitures, aux expéditions
chez les façonniers et a leur suivi, en passant par le calcul des prix de
revient ... bref, ce que nous n'arrivions pas à trouver sur le marché.
Surtout ce qui intéresse notre PDG, c'est que nous sommes libre de faire des
évolutions quand nous le souhaitons. Nous avons demandé certaines évolutions
à Cegid concernant la prise d'ordres et la paie, deux ans après nous
attendons encore, ce qui fache notre PDG !
Au 15 juillet, je mets en place notre prise d'ordres "made in Pause Café"
c'est à dire développement interne pour remplacer le progiciel de Cégid qui
ne nous convient pas.
Pour te donner un seul exemple d'une demande faite à Cegid depuis plus de 2
ans et non satisfaite : lorsque nous récupérons les commandes provenant des
portables des représentants, nous voudrions pouvoir sortir un état de date à
date. Impossible, on obtient seulement un état à la saison ou il faut
sélectionner les commandes une par une. Toi qui connaît comme moi le
développement de ce type de fonction, tu ne vas pas me dire que c'est
impossible ou que c'est un travail important que de mettre une sélection de
date dans un état et de remonter que les commandes prises dans cette
fourchette de dates !
Pour la gestion commerciale, notre PDG n'a pas hésité et la encore, il ne
veut pas subir Cegid ou une autre société, il préfère notre indépendance.
Donc développement. La contre partie du développement est que je suis très
chargée comme tu l'imagines, surtout que le quotidien est a gérer également.
Cependant je comprends la position de notre PDG et j'avoue que j'ai bien du
mal a lui avancer des arguments positifs qui pourrait le faire changer d'avis
puisqu'à chaque fois qu'il veut quelque chose sur les progiciels Cegid c'est
souvent compliqué, voir impossible de lui donner. D'ailleurs il me le
rappelle souvent.
Au finale, nous devrions garder en progiciel : la paie (avec un complément
de développement sur une base Access), la compta et notre réseau de boutiques
où la encore nous ne sommes pas vraiment satisfait !
En développement, nous aurons : la gestion de production, la prise d'ordres
et la gestion commerciale (inclus la facturation, les expéditions ...)
En conclusion, je souhaite progresser en optimisation de mes bases afin de
continuer nos projets et comme je l'ai déjà écris, il y a urgence. Nous nous
développons (cela n'est pas un secret) très vite à l'export et notre système
actuel, sur AS400, ne sait pas ce que c'est l'export !!!
Je n'exclus pas de passer à SQL server mais pour cela, il me faudra de la
formation, je ne veux pas m'improviser. Le problème est qu'à Troyes, je ne
trouve personne pour me former, on me conseille bien sûr d'aller à Paris mais
pour le moment, je n'ai pas le temps matériel !
Je te pose la question que j'ai posé à Pierre : connais-tu un prestataire
qui pourrait m'assister dans l'optimisation de mes bases ? Cela me ferra le
plus grand bien de travailler avec une personne largement plus compétente que
moi.
Merci pour tes liens, bonne journée.
Je fais comment pour envoyer une barre de nougati par internet !!??
A +
Comme je comprends bien tout ça.
1) Un éditeur de logiciel ne modifiera jamais son logiciel en fonction
d'une demande d'un client.
C'est plutôt une démarche globale et si jamais une mise à jour (payante
bien sur) vous rends l'utilisation plus confortable. Tant mieux !
2)Le métier textile est très délicat et très particulier , je ne sais
pas s'il existe un logiciel qui rentre dans les clous pour tout le
monde. La gestion notamment du négoce, façonnier etc est propre à chacun
quasiment.
3) Pour infos, nous préférons se baser sur une solution de gestion
commerciale éprouvée mais avec la base ouverte (SAGE Lignee100 version
SQL SERVER pour ne pas la citer) afin de ne pas gérer tous les points
délicats:
multi devises, multi depots, multi reglements, gestion composantes,
nomenclatures, statistiques...etc, etc !!!
Grâce à l'ODBC, on peut mettre à jour les éléments sans trop se planter.
4) Pour une formation ou un support, c'est vrai que tu parais seule au
monde sur ce projet, alors le spécifique c'est bien mais il faut quand
même prendre ces précautions...
Il me semble étonnant de ne pas trouver de prestataire à Troyes.
5)Revenons à Ms access sinon on va se faire virer !
Pour moi, il faut clairement passer à SQL SERVER vu l'évolution du
projet, plutôt que de tout refaire à la fin de la prise de commande et
de la facturation.
Ou alors commencer la facturation en SQL SERVER et une fois Ok, passer
la GPAO en SQL SERVER.
6) Je suis sur Angers et Troyes est trop loin de notre Domaine
d'intervention
7) Demande une augmentation ma pauvre ;)Bonjour Jerome,
Oui, j'ai installé sur tous les postes les services pack en particulier le 3.
Je vais effectivement faire une base d'archivage, nous démarrons notre 4ème
saisons avec cette base. Lorsque nous en serons à la 5ème, j'archiverais la
1ère.
J'aimerais laisser 4 saisons en ligne, si cela est possible.
Nous travaillons en produit/couleur/taille.
Effectivement l'idée de départ était de tout informatiser par progiciel.
D'ailleurs j'ai été embauchée pour cela et pas pour développer. Lorsque je
suis arrivée, notre PDG avait déjà acheté la paie, la compta, la prise
d'ordres sur portable pour les représentants et le logiciel caisse pour nos
boutiques (back et front office). Les boutiques étaient déjà installées, la
prise d'ordres également mais avec beaucoup de soucis et de besoins non
satisfaits. Tu l'a deviné, ces logiciels proviennent de CEGID. Ma première
mission fut de mettre en place la paie et cela n'a pas été simple car elle ne
répond pas vraiement à nos besoins. Nous avons intéressement et
participation, Cegid ne pouvait pas mettre en place alors que le produit nous
avait été vendu avec ces modules ! Résultat développement d'une base Access
pour compléter. La compta, même si ce n'est pas parfais, elle fonctionne.
Notre PDG a alors découvert que je pouvais développer et cela lui a donné des
idées !
Lorsqu'il a été question de remplacer la gestion production, il n'a pas
hésité une seconde, il m'a demandé de la développer au plus vite. Nous avons
donc aujourd'hui une GP qui part du dossier de style de nos stylistes pour
aller jusqu'aux nomenclatures, aux commandes fournitures, aux expéditions
chez les façonniers et a leur suivi, en passant par le calcul des prix de
revient ... bref, ce que nous n'arrivions pas à trouver sur le marché.
Surtout ce qui intéresse notre PDG, c'est que nous sommes libre de faire des
évolutions quand nous le souhaitons. Nous avons demandé certaines évolutions
à Cegid concernant la prise d'ordres et la paie, deux ans après nous
attendons encore, ce qui fache notre PDG !
Au 15 juillet, je mets en place notre prise d'ordres "made in Pause Café"
c'est à dire développement interne pour remplacer le progiciel de Cégid qui
ne nous convient pas.
Pour te donner un seul exemple d'une demande faite à Cegid depuis plus de 2
ans et non satisfaite : lorsque nous récupérons les commandes provenant des
portables des représentants, nous voudrions pouvoir sortir un état de date à
date. Impossible, on obtient seulement un état à la saison ou il faut
sélectionner les commandes une par une. Toi qui connaît comme moi le
développement de ce type de fonction, tu ne vas pas me dire que c'est
impossible ou que c'est un travail important que de mettre une sélection de
date dans un état et de remonter que les commandes prises dans cette
fourchette de dates !
Pour la gestion commerciale, notre PDG n'a pas hésité et la encore, il ne
veut pas subir Cegid ou une autre société, il préfère notre indépendance.
Donc développement. La contre partie du développement est que je suis très
chargée comme tu l'imagines, surtout que le quotidien est a gérer également.
Cependant je comprends la position de notre PDG et j'avoue que j'ai bien du
mal a lui avancer des arguments positifs qui pourrait le faire changer d'avis
puisqu'à chaque fois qu'il veut quelque chose sur les progiciels Cegid c'est
souvent compliqué, voir impossible de lui donner. D'ailleurs il me le
rappelle souvent.
Au finale, nous devrions garder en progiciel : la paie (avec un complément
de développement sur une base Access), la compta et notre réseau de boutiques
où la encore nous ne sommes pas vraiment satisfait !
En développement, nous aurons : la gestion de production, la prise d'ordres
et la gestion commerciale (inclus la facturation, les expéditions ...)
En conclusion, je souhaite progresser en optimisation de mes bases afin de
continuer nos projets et comme je l'ai déjà écris, il y a urgence. Nous nous
développons (cela n'est pas un secret) très vite à l'export et notre système
actuel, sur AS400, ne sait pas ce que c'est l'export !!!
Je n'exclus pas de passer à SQL server mais pour cela, il me faudra de la
formation, je ne veux pas m'improviser. Le problème est qu'à Troyes, je ne
trouve personne pour me former, on me conseille bien sûr d'aller à Paris mais
pour le moment, je n'ai pas le temps matériel !
Je te pose la question que j'ai posé à Pierre : connais-tu un prestataire
qui pourrait m'assister dans l'optimisation de mes bases ? Cela me ferra le
plus grand bien de travailler avec une personne largement plus compétente que
moi.
Merci pour tes liens, bonne journée.
Je fais comment pour envoyer une barre de nougati par internet !!??
A +
Bonsoir Jerome,
Merci des tes conseils.
Cependant je ne pense pas qu'une augmentation résoudra mes problème s.
L'idéal serait d'embaucher une personne plus compétente que moi ou
connaissant SQL Server pour par exemple, reprendre l'existant en projet adp.
Nous avons tenté cette solution en passant une annonce mais là enco re c'est
pas gagné ! En 10 mois, nous avons surtout vu des candidatures de tec hniciens
réseau ou micro et de petites expériences sur Access au cours de le ur stage
de BTS, par exemple. Nous avons pris une personne à l'essai deux mois , qui
d'après son CV, maîtrissait Access, je ne suis vite rendu compte qu 'elle en
savait beaucoup moins que moi !
Mais rassures-tu, je ne vais pas développer la gestion commerciale da ns la
base de données de production. Je vais créer une nouvelle base de d onnées
pour la gestion commerciale et une autre qui permettra l'archivage des
factures et commandes...
La base de production mettra à jour celle du commercial en terme de
collection, d'of...
D'ailleurs cela existe déjà chez nous puisque j'ai une deuxième b ase Access
(plus petite et moins complexe) qui permet d'obtenir une fiche produit très
détaillée avec photo et plaquette photo des coloris (totalement ine xistante
sur AS400), un suivi de fabrication et de réception des produits de r etour
des façonniers, un suivi de stock... pour notre service commercial af in de
répondre le mieux possible aux clients. Cette base est mise à jour chaque
nuit par la base de production qui tranmet également des infos à l' AS400.
Merci encore de tes réponses.
Bonne soirée
A +
Bonsoir Jerome,
Merci des tes conseils.
Cependant je ne pense pas qu'une augmentation résoudra mes problème s.
L'idéal serait d'embaucher une personne plus compétente que moi ou
connaissant SQL Server pour par exemple, reprendre l'existant en projet adp.
Nous avons tenté cette solution en passant une annonce mais là enco re c'est
pas gagné ! En 10 mois, nous avons surtout vu des candidatures de tec hniciens
réseau ou micro et de petites expériences sur Access au cours de le ur stage
de BTS, par exemple. Nous avons pris une personne à l'essai deux mois , qui
d'après son CV, maîtrissait Access, je ne suis vite rendu compte qu 'elle en
savait beaucoup moins que moi !
Mais rassures-tu, je ne vais pas développer la gestion commerciale da ns la
base de données de production. Je vais créer une nouvelle base de d onnées
pour la gestion commerciale et une autre qui permettra l'archivage des
factures et commandes...
La base de production mettra à jour celle du commercial en terme de
collection, d'of...
D'ailleurs cela existe déjà chez nous puisque j'ai une deuxième b ase Access
(plus petite et moins complexe) qui permet d'obtenir une fiche produit très
détaillée avec photo et plaquette photo des coloris (totalement ine xistante
sur AS400), un suivi de fabrication et de réception des produits de r etour
des façonniers, un suivi de stock... pour notre service commercial af in de
répondre le mieux possible aux clients. Cette base est mise à jour chaque
nuit par la base de production qui tranmet également des infos à l' AS400.
Merci encore de tes réponses.
Bonne soirée
A +
Bonsoir Jerome,
Merci des tes conseils.
Cependant je ne pense pas qu'une augmentation résoudra mes problème s.
L'idéal serait d'embaucher une personne plus compétente que moi ou
connaissant SQL Server pour par exemple, reprendre l'existant en projet adp.
Nous avons tenté cette solution en passant une annonce mais là enco re c'est
pas gagné ! En 10 mois, nous avons surtout vu des candidatures de tec hniciens
réseau ou micro et de petites expériences sur Access au cours de le ur stage
de BTS, par exemple. Nous avons pris une personne à l'essai deux mois , qui
d'après son CV, maîtrissait Access, je ne suis vite rendu compte qu 'elle en
savait beaucoup moins que moi !
Mais rassures-tu, je ne vais pas développer la gestion commerciale da ns la
base de données de production. Je vais créer une nouvelle base de d onnées
pour la gestion commerciale et une autre qui permettra l'archivage des
factures et commandes...
La base de production mettra à jour celle du commercial en terme de
collection, d'of...
D'ailleurs cela existe déjà chez nous puisque j'ai une deuxième b ase Access
(plus petite et moins complexe) qui permet d'obtenir une fiche produit très
détaillée avec photo et plaquette photo des coloris (totalement ine xistante
sur AS400), un suivi de fabrication et de réception des produits de r etour
des façonniers, un suivi de stock... pour notre service commercial af in de
répondre le mieux possible aux clients. Cette base est mise à jour chaque
nuit par la base de production qui tranmet également des infos à l' AS400.
Merci encore de tes réponses.
Bonne soirée
A +
Ok ça marche !
Et une société de services pour vous mettre sur les rails et ensuite tu
seras autonome.
Tiens moi au courant!
PS:
Nous on a du boulot jusque que fin septembre...
Après c'est joli Troyes? ;-)Bonsoir Jerome,
Merci des tes conseils.
Cependant je ne pense pas qu'une augmentation résoudra mes problèmes.
L'idéal serait d'embaucher une personne plus compétente que moi ou
connaissant SQL Server pour par exemple, reprendre l'existant en projet adp.
Nous avons tenté cette solution en passant une annonce mais là encore c'est
pas gagné ! En 10 mois, nous avons surtout vu des candidatures de techniciens
réseau ou micro et de petites expériences sur Access au cours de leur stage
de BTS, par exemple. Nous avons pris une personne à l'essai deux mois, qui
d'après son CV, maîtrissait Access, je ne suis vite rendu compte qu'elle en
savait beaucoup moins que moi !
Mais rassures-tu, je ne vais pas développer la gestion commerciale dans la
base de données de production. Je vais créer une nouvelle base de données
pour la gestion commerciale et une autre qui permettra l'archivage des
factures et commandes...
La base de production mettra à jour celle du commercial en terme de
collection, d'of...
D'ailleurs cela existe déjà chez nous puisque j'ai une deuxième base Access
(plus petite et moins complexe) qui permet d'obtenir une fiche produit très
détaillée avec photo et plaquette photo des coloris (totalement inexistante
sur AS400), un suivi de fabrication et de réception des produits de retour
des façonniers, un suivi de stock... pour notre service commercial afin de
répondre le mieux possible aux clients. Cette base est mise à jour chaque
nuit par la base de production qui tranmet également des infos à l'AS400.
Merci encore de tes réponses.
Bonne soirée
A +
Ok ça marche !
Et une société de services pour vous mettre sur les rails et ensuite tu
seras autonome.
Tiens moi au courant!
PS:
Nous on a du boulot jusque que fin septembre...
Après c'est joli Troyes? ;-)
Bonsoir Jerome,
Merci des tes conseils.
Cependant je ne pense pas qu'une augmentation résoudra mes problèmes.
L'idéal serait d'embaucher une personne plus compétente que moi ou
connaissant SQL Server pour par exemple, reprendre l'existant en projet adp.
Nous avons tenté cette solution en passant une annonce mais là encore c'est
pas gagné ! En 10 mois, nous avons surtout vu des candidatures de techniciens
réseau ou micro et de petites expériences sur Access au cours de leur stage
de BTS, par exemple. Nous avons pris une personne à l'essai deux mois, qui
d'après son CV, maîtrissait Access, je ne suis vite rendu compte qu'elle en
savait beaucoup moins que moi !
Mais rassures-tu, je ne vais pas développer la gestion commerciale dans la
base de données de production. Je vais créer une nouvelle base de données
pour la gestion commerciale et une autre qui permettra l'archivage des
factures et commandes...
La base de production mettra à jour celle du commercial en terme de
collection, d'of...
D'ailleurs cela existe déjà chez nous puisque j'ai une deuxième base Access
(plus petite et moins complexe) qui permet d'obtenir une fiche produit très
détaillée avec photo et plaquette photo des coloris (totalement inexistante
sur AS400), un suivi de fabrication et de réception des produits de retour
des façonniers, un suivi de stock... pour notre service commercial afin de
répondre le mieux possible aux clients. Cette base est mise à jour chaque
nuit par la base de production qui tranmet également des infos à l'AS400.
Merci encore de tes réponses.
Bonne soirée
A +
Ok ça marche !
Et une société de services pour vous mettre sur les rails et ensuite tu
seras autonome.
Tiens moi au courant!
PS:
Nous on a du boulot jusque que fin septembre...
Après c'est joli Troyes? ;-)Bonsoir Jerome,
Merci des tes conseils.
Cependant je ne pense pas qu'une augmentation résoudra mes problèmes.
L'idéal serait d'embaucher une personne plus compétente que moi ou
connaissant SQL Server pour par exemple, reprendre l'existant en projet adp.
Nous avons tenté cette solution en passant une annonce mais là encore c'est
pas gagné ! En 10 mois, nous avons surtout vu des candidatures de techniciens
réseau ou micro et de petites expériences sur Access au cours de leur stage
de BTS, par exemple. Nous avons pris une personne à l'essai deux mois, qui
d'après son CV, maîtrissait Access, je ne suis vite rendu compte qu'elle en
savait beaucoup moins que moi !
Mais rassures-tu, je ne vais pas développer la gestion commerciale dans la
base de données de production. Je vais créer une nouvelle base de données
pour la gestion commerciale et une autre qui permettra l'archivage des
factures et commandes...
La base de production mettra à jour celle du commercial en terme de
collection, d'of...
D'ailleurs cela existe déjà chez nous puisque j'ai une deuxième base Access
(plus petite et moins complexe) qui permet d'obtenir une fiche produit très
détaillée avec photo et plaquette photo des coloris (totalement inexistante
sur AS400), un suivi de fabrication et de réception des produits de retour
des façonniers, un suivi de stock... pour notre service commercial afin de
répondre le mieux possible aux clients. Cette base est mise à jour chaque
nuit par la base de production qui tranmet également des infos à l'AS400.
Merci encore de tes réponses.
Bonne soirée
A +