Discussion :

[Invité]

Bonjour à tous,

Je dois développer une application sous Excel, ce fichier (avec du VBA et des UserForm) sera sur un serveur, différentes personnes devrons l'ouvrir, pour consultation et saisie.

Je souhaiterais que vous me fassiez par des soucis que vous avez put rencontrer. Et des options qu'il fallait définir pour que cela fonctionne correctement.

N'hésitez pas aussi à faire des critiques sur l'utilisation d'Excel en partagé sur un serveur.
Je développe surtout sous Access, excel en local OK, mais sur serveur j'ai de grand doutes.

Merci à tous pour votre collaboration

STAREC

[random]

je crois qu'il faut distinguer les données et les traitements

il est possible que compte tenu du problème à traiter excel soit le meilleur
outil de traitement (à vérifier)

mais excel n'est pas un outil de saisie/conservation multi utilisateurs

je ferais une base acess en frontal pour les données et un outil de
traitement restitution sous excel

[Invité]

Merci Random,

Le problème est que je dois développer sous EXCEL, or c'est bien une gestion de base sous Excel et non sous Access (on m'impose excel).

Petits points complémentaires :

1 - Le fichier xls sera sur réseau
2 - Certains postes n'auront pas excell en local, ils utiliserons l'excel du réseau, c'est ce qui me fait peur. Donc je ne peux séparer les données sur un classeur et les forms en local (c'est ce que je fais avec Access).

Merci de continuer à me donner votre Avis.

Je voudrais rajouter une question :

Si j'utilise des variables globales (ex : comme un openargs d'un formulaire Access pour récupérer une valeur à l'entrée, et masquer des champs en fonction de cette valeur), que ce passera-t-il si j'ouvre la form par rapport à cette valeur et que 2 secondes après un autre poste l'ouvre, cette valeur va changer, n'est-ce pas ?, car mes macros sont sur serveur et non sur poste fixe.


STAREC

[Jipété]

Salut !

Certains postes n'auront pas excell en local, ils utiliserons l'excel du réseau, c'est ce qui me fait peur.

Perso, ça me semble loufoque !
Et ça m'étonnerait que ça fonctionne : s'il s'agissait d'un bête .exe stand-alone, à la rigueur, mais Excel doit être "installé" sur un poste pour que le poste puisse l'utiliser, même si le répertoire d'install n'est pas local (jamais tenté ce plan foireux : déjà que des fois Office merde avec une install locale, alors ton plan...)
Bon courage,
--
Jean-Pierre

[Invité]

Merci Jipété

Mais oui c'est possible cela fonctionne ici comme cela pour une partie des poste, ce sont juste des connexions serveurs avec un boitier (un NEOWARE), excel est sur le serveur et cela fonctionne.

Personne n'a d'autres idées, surtout pour mes variables globales.

Merci d'avance

STAREC

[AlainTech]

Les variables, mêmes globales, sont locales à l'instance de l'application.

La seule manière de passer des paramètres aux autres utilisateurs est de les écrire à un endroit où les autres pourront les lire.
Ca peut être dans le classeur (c'est l'idéal), dans un autre classeur (aussi partagé) ou dans un fichier ini.
Pour cette dernière possibilité, il faudra gérer les accès concurrents toi-même alors qu'Excel fait ça très bien.

[Invité]

Salut,

Merci AlainTech, si j'ai bien compris je n'ai pas de soucis à avoir sur les variables globales, elles seront bien liés à chaque utilisateur. Si c'est le cas, cela m'ote une épine du pied.

Starec

[Invité]

Re

J'ai enlevé le résolu pour poursuivre la discussion

Que pensez-vous des choses suivantes :

1 - Mettre les données sur un fichier excel et gérer la partie applicatif par Automtion sur un autre fichier excel
2 - Ce qui inquiète mon responsable par un développement sous Access c'est la corruption des bases, j'ai pensé à un fichier excel pour les données et une base access pour la partie applicatif, avec liaison sur les feuilles excel, ce qui les transformera en table, et donc je pourrais faire des extractions en SQL, etc.

Merci à tous

Starec

[choucks]

Salut Starec,

Je finalise actuellement un projet dont l'objectif est de mettre en place une gestion multi-utilisateur des stocks.

L'outil créé : Il s'agit d'un classeur partagé (qui se trouve sur le serveur) qui récupère dans une base (Navision) les références des articles en rupture ou proche de la rupture de stock. Tous les matins à l'ouverture du-dit classeur par le 1er utilisateur une mise à jour est faite (un projet VBA met à jour la feuille du classeur :suppresion ou ajout de certains références, modification de date et de quantité puis tri est mise en forme des données) .

Les utilisateurs consultent et saisissent des données.

Les limites :

Hormis les limites spécifiées dans l'aide, c'est à dire l'impossibilité de modifier :
les cellules fusionnées,
la mises en forme conditionnelles,
la validation des données,
les graphiques,
les images,
les objets (notamment les objets dessinés),
les liens hypertexte,
les scénarios, les contours, les sous-totaux, lestables de données,
les rapports de tableau croisé dynamique,
la protection des classeurs et des feuilles de calcul, et macros.

Il faut savoir que les commentaires sont mal gérés en mode partagé , qu'il n'est pas possible d'accéder au projet VBA après le partage. Il faut alors annuler le partage mais alors tout l'historique des modifications est perdu. De plus même si l'on tente de contourner cette limite à savoir de modifier les lignes de code d'une procédure via une autre procédure c'est le bug assuré.

J'ai également un souci avec la sécurité, je n'ai pas trouvé le moyen d'installer automatiquement le certificat numérique du projet VBA sur chaque poste. Je dois donc faire le tour des bureaux pour copier le certificat.

Voilà un rapide résumé des limites du partage

[Invité]

Re

Merci chouks, cela m'aide beaucoup, donc pas trop le pied, mais on m'impose Excel.

Starec