Au taff on m as demande de faire un programme qui gereras touts les employes de la compagnie ( ), j ai donc utilise Access pour faire la base de donne j ai cree les tables les requetes, regle les regles d integrites j ai fait d interfaces utilisateurs avec les formulaires .........
le prob c que je voa pas comment faire un logiciel client qui se connecteras a la base de donne situe sur un serveur avec Access
Pour mois ca devrait marche ainsi : je mets la BD sur le serveur et on y accede avec le logiciel client sur un poste du reseau
 
questions:
-ecqu'on peut faire un client avec Access, autre qu une macro (genre excel qui peut gere la base qu en ouvrant Access lui meme) ???
-je pourrai developpe en vb le client, ecque ce serait mieux ???
 
J'espere que tout le monde a compris et pourra me donner un conseil

clairement mieux si tu le fais en VB, pas demacro ni d'excel vb gere tres bien les connections aune base distante.
 
il faudra probabmemùent creer un objet connection ( euh un truc du type: connec as dbconnection, enfin je connais aps la syntaxe vb , mais un truc comme ca,
et dans connec tu devras mettre le nom de la base sur le reseau ainsi que le pass et d autres parametres.
 
mais pas de macro.
refait tout sur VB5 ou 6.
enfin ce n'est que mon avuise t je le repete le dim connec as dbconnection, ca doit aps etre ca en vb, en java c est un obket dbconnection je crois voila pourquoi j'ai utilisé dbconnection.

et ainsi tu seras connecter a la base distane il te suffira donc de creer d'autres objet style query ou statement pour le java pour faire des requetes dessus.
et parcourir les resultats obtenus.

Ton client est monoposte ? Plusieurs personnes devront mettre a jour la DB (en meme temps) ?  
 
Attention je pense que tu devras utiliser ODBC donc tu devras avoir un prog intermediaire pour faire l'interface entre la BD et les ordres provenant de poste autre que celui ou il y a la base... Donc la architecture 3/3 ( Client/Server ).  
 
Enfin deja, je voudrais bien avoir quelques precisions par rapport a mes questions, ca pourrait aider pour une solution

non client serveur c est pas du 3 tiers .
enfin je crois pas qu on nomme ca comme ca.
 
mais fantom tu parles d'un prog intermediare ? tu veux dire un client our la connection a la base ?
bein ouais faudra l installer sur le poste ayant le logiciel.
faut le client odbc.

oui mais ta base access avec ODBC n'est pas accessible via une URL .. c pas comme de l'Oracle. La est tout le bins ...

Oblige de passer par une archi client/serveur .... (donc Client/Server/DB = 3/3 )

FaNToM a écrit a écrit : Oblige de passer par une archi client/serveur .... (donc Client/Server/DB = 3/3 )

vive oracle alors .
 
sinon moi je vois une appli sur le client et une base sur le serveur pour moi c est 2/3 .
 
un poste client plus serveur d appli plus serveur de donnees ( ici la bd) ca fait 3/3 .

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

en gros une base access peut pas faire serveur .liquid fait tout sur oracle c est pas plus compliquer mais lamise en place a l air mon chiante .

oui mais la il est obliger de passer par un serveur si il utilise (et il devra, je vois pas d'autre moyen) ODBC. Donc la aucune archi 2/3 possible si c'est du multiposte ou meme si c'est en distant que doit s'effectuer les operations.

La base access tu peux l'attaquer en VB ou en VC++.
Par contre en multi utilisateur, access c'est très limite, y a pas vraiment de serveur, en gros t'accèdes directement au fichier .mdb via le moteur jet de MS.
 
Par contre tu peux installer ta base sur un vrai SGBD tout en gardant une interface access (par le biais des tables attachées) sur chaque poste client.

fantom > on peut aps installer l odbc sur le poste client ? ou demander a VB de le gerer ?
 
verdoux > tables liées ?

Oui mais l'inconvienant d'Oracle est la license (baser sur le NB de cnx simultanee) treeeees chere. Et puis si c'est simplement pour une petite appli comme ca no way.  
 
L'avantage de la base access est que l'on peut faire rapidement des exportations et importation dans Excel ou autre truc M$ donc pas besoin de redevelopper la roue, compatibilite produit rulezzz.

Tu peux mettre mysql ou postgresql derrière access (avec des tables liées)

Ce que dit Verdoux a propos d'un env multi utilisateur est vrai.
Access n'est pas fait pour. Disons meme qu'il ne gere pas les multi connexions.
 
Mais c'est la qu'intervient le serveur (avec une gestion de queue de requete derriere pour ce povre Access )

comme verdoux a dit: tu mets ta base access sur un repertoire partagé, tu definis un System DSN pointant vers ce chemin dans la config. ODBC de chaque client et voila... par contre c'est le client qui menera la danse et donc le dernier qui "ecrira" qui sera effectivement "sauvegardé"

comment ca accesse gere aps ca ?
enfin a atravers un reseau onpeut tres bieninterroger access ?
et effectuer des requetes suivant le mode demande ?
enfin je me suviens pas trop mais on peut àuvrir access sous 2 modes, un pseudo mode temps reel qui permet d avoir les modifications dela bases en live et un autre mode snapshop qui pemet de voirla base a un moment donné ?

JWhy > TRop risquer vu le type de fichier ( gestion des employees ). Et puis vraiment c'est une solution gros porc.

sinon je connais pas trop alors .

Non moi je voulais mettre access sur chaque poste, en local, mais avec des tables liées vers un vrai SGBD.
La base access en local sert juste d'interface pour le développement du client.

Fantom> bah oui mais a la base faire ca avec access ...  
verdoux> ah ok... donc tu fais un client en Access directement alors ?!? y'a plus besoin de vb ou autres , non ?
verdoux bis> pardon j'ai rien dit... faut que j'apprenne a lire les posts

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

Clarkent > ce que je veux dire c'est qu'il ne gere pas les multiple ouverture de fichiers avec oprations de MAJ ou d'insertions dessus. le resultat doit donner a peu pres ce que dit JWhy

ok je vois bien.
 
je suisok avec ca.

JWhy > oui je suis bien d'accord mais faut voir ca dans une contrainte entreprise alors Mais on peut tres bien faire quelque chose d'extremement propre avec l'archi que j'ai proposer au depart.

fantom> attends, je relis alors... pasque j'avais pas vu ca comme qqchose de propre...

ok... donc il te faut developper une couche qui va s'occuper de la connexion a access + la gestion de la concurrence + tout ce que j'oublie  
c'est pas un peu prise de tete ? (oui, je sais... les contraintes de l'entreprise )

JWhy > pour le cas multi-poste, nan. Le cas monoposte, oui. Mais pour developper ca, je dirais que 2 a 3 jours (grand max vu qu'il a les requetes deja prete) pour faire le serveur + tests fonctionnels ...

Oui Fantom, tu le fais comment ton espèce de moniteur transactionnel ?
Tu vas prendre une licence tuxedo pour te connecter à access ?

ouahhhhhhhhhhhhhhhh, jamais fait autant de post sur programmation  

 
voila, en fait le prog est pour une seule personne, le chef du service info qui veut organniser les roulements de c employees
donc un seul client par contre la base je preferai qu elle soit sur un serveur (pour mes etudes en fait) plutot que sur un poste (sinon j aurai deja finit)
je pensai effectivmenent utilise ODBC (qu on a survole en cours)

Verdoux > je parse par WebLogic 6.0 avec un EJB Stateless pour garder les transaction passer par session ....  sans dec si tu fais ca en java (je vois ca coter Java, VB et autre connais po) tu fais ta queue d'evenements ou tu y depose tout evenement entreant et ou tu ira piocher chacun de ces evenement pour faire les operations sur la base. Bien sur une queue FIFO ... Apres atoi de voir comment tu veux gerer ta queue d'evenement.

Si il y a un seul client, t'as juste qu'à mettre le .mdb dans un répertoire partagé, avec un mot de passe.

clair.... si c'est pour un seul gars... au pire tu fais la base dans un fichier texte

Verdoux  > You win ... solution la plus simple dans ce cas la

tu parle bien de le mettre sur le serveur ???
en fait le serveur est un AS/400 et il fo un compte utilisateur pour se connecte au reseau

Hou la la !
 
Il est tout à fait possible de dévelloper une appli Access pour plusieurs personnes !
http://www.microsoft.com/france/ac [...] asp#170980
 
Il faut installer le runtime access sur les postes client et lui donner le chemin du fichier MDB !
 
Le runtime permet aux utilisateurs d'utiliser les formulaires et les rapports sans pouvoir les modifiers. (Sauf pour ceux qu'ont acces ! Là il faut mettre en place des droits!)
Il est disponible avec le kit de développement. Tout dépend de la version d'access !
http://www.microsoft.com/france/officedev/default.asp

[edtdd]--Message édité par Mara's dad--[/edtdd]

je fout le .mdb sur le serveur
je fait une appli cliente en vb (pas d access donc ???)
c bon ???

a quoi ca sert de faire unrep partager ? ca revient quasi au meem que de le mettre sur le client non ?

euh oublis les applis access .

 
Sauf que tu partage pas les données !
Sauf si elles sont en tables attachés, mais y'a beaucoup de restrictions très chiantes !

Mara's Dad> Disons que si le nombre de personnes est >= 2, il peut y avoir quelques pb
(enfin access est connu comme étant très rapidement limité en mode multi-utilisateur)