Voilà, j'ai un petit soucis - 2 fois rien, mais bon, ça fait chier quand même.
 
Dans le groupe mondial où je bosse, nous sommes jusqu'à la fin de l'année sous License Lotus Smartsuite.
Dans l'usine où je bosse, on utilise Lotus Approach depuis 5 ans environ. On a créé des dizaine de programmes avec des données sur fichiers dbf. Des applications utilisées en réseau - multi-utilisateurs...
Certains fichiers *.Apr (application approach) étaient liés entre eux (par appel), et pouvaient contenir jusqu'à une dizaine de fichier dbf liés par clé...
 
Donc, fin 2001 arrive, on arrête Lotus et là oh-joie-oh-miracle-youpi-yoplà-on-est-tous-contents , on passe chez microsoft office , et donc l'équivalent est Access (youpi-yoplà-on-est-tous-contents).
 
Bon, pour ceux qui connaissent approach, il est simple, et on fait des trucs rapido, et en plus, c'est un vrai moteur SGBD, avec programmes d'un côté et data de l'autre.
 
Bref :
 
1) On sait qu'il n'est pas possible de convertir les applics Approach en Access, on ne peut récupérer que les datas. Bon on s'y fera ... et on refera nos apps, mais ça va prendre du temps...
 
2) ce p***** de soft d'Access n'est pas fichu de gérer de apps en réseau !!!!:gun: , hors la plus part des apps conçues sous Approach étaient justement sur le réseau et accessibles à plusieurs utilisateurs en même temps. c'est même ce qui fait leur intérêt !
Deplus, pour faire quelquechose de simple sous Access, bonjour !
 
Que faire ???  
 
 
Néanmoins il semblerait - et c'est là que j'ai besoin de votre avis - que la maison mère consentirait à payer un serveur SQL (PC-Serveur + MS SQL Server)!
 
SQL server : est-ce que c'est bien ? peut-on avec ce type de serveur (moteur SGBD) concevoir et maintenir facilement des bases de données (jusqu'a qlq 10aines de milliers d'enregistrements) ?
Peut on accéder aux bases via l'interface d'Access ?
 
Y a t'il une alternative à SQL Server, un autre produit qui "tienne la route" ?
 
merci.
A+

Access peut être utilisé en réseau et gérer plusieurs connexions simultanées. Toutefois je ne me risquerais pas à développer mon interface avec Access directement, car dès que tu ouvre Access tu as pu constater que tu obtiens un lock exclusif sur la DB (berk !).
 
En fait le provider OLEDB d'access gère jusqu'à 255 connexions simultanées (celui de SQL server en gere bcp plus et dispose entre autre choses utiles d'une gestion des droits d'utilisateurs). Après tu as le choix pour développer ton interface avec d'autre logiciels :
 
1) Visual C++ (ou tout autre langage C/C++), nécessite de très bonne base de programmation, mais a un avantage : la rapidité d'exécution (tu compile le programme)
 
2) Visual Basic (ou Delphi chez la concurence), est bcp plus simple et à mon vis plus efficace pour créer des programmes destinés aux DB, il est aussi tout à fait capable d'utiliser un provider OLEDB et donc de se connecter à une base de données qui réside sur un partage réseau.
 
3) ASP (Active Server Pages) ou ASP .net, tu créé des pages Web dynamiques qui seront executées sur le serveur Web, ces pages se chargent d'effectuer la connexion à la DB d'aller chercher le data et de présenter l'information à l'utilisateur. Tu as nettement plus de restrictions sur l'interface (c'est uniquement un browser faut pas l'oublier !), mais tu as deux grands avantages : la maintenance du programme est centralisée sur le serveur et tu n'as besoin que d'un browser pour l'utiliser. Il est possible d'étendre les fonctionnalités de l'interface du client avec par exemple des controles ActiveX, mais la c'est une autre histoire.
 
Voila donc à ta palce, je choisirai soit la solution VB / Delphi (la plus facile à mon avis), soit la solution ASP (la plus cool pour maintenir les softs)

[edtdd]--Message édité par Requin--[/edtdd]

Thx a lot pour le conseil ! =)

Oui, access peut être utilisé en reseau..
 
Mais attention à ce qu'ils n'y ait pas trop d'utilisateurs simultanés, car ta base va avoir tendance à grossir super vite et surtout s'endommager très rapidement....
J'ai le problème actuellement, 30 users en même temps sur un pauvre .mdb...et j'en ai marre de me taper des reparations et compilation de base..

 
Avec un peu de code en Windows Scripting Host tu pourrais automatiser le processus pour par exemple qu'à minuit chaque jour la DB soit vérifiée et comprimée (lock exclusif obligatoire)... je n'ai plus l'article de la knowledge base qui traite du sujet sous la main donc je te laisse le chercher.

[edtdd]--Message édité par Requin--[/edtdd]