Gestion d'une base access distante

Bonjour,

Je vous présente rapidement mon problème : il faut que je puisse écrire des données dans une base de données access situé sur un serveur internet distant à partir d'une application en C++.
Cette application utilise déjà des base de données access en local via un lien ODBC.
C'est pourquoi je m'oriente vers une utilisation de ODBC pour contrôler la base distante d'où ma première question : Est-ce possible ??

Si oui, comment vous y prendriez-vous ?

Si non, que me conseilleriez vous de faire ?

Toute aide est la bienvenu, merci d'avance ;)

Salut,

L'utilisation d'une base access sur un serveur me laisse quelque peu... perplexe, de par les restrictions que ce genre de base de données représente (en terme de nombre d'accès concurrents, entre autres)

Je sais bien qu'il existe des hébergeurs qui proposent ce genre de possibilité, mais, à mon sens, un vrai SGBDR (acces n'étant qu'une BDR) me semble largement plus intéressant

Mais l'information importante tiens en deux mot:serveur web...

Access n'étant pas un serveur de base de données, le seul accès que tu peux envisager pour y accéder est de passer par... le serveur web "himself", avec son protocole http, sur le port 80 (ou 8080 si derrière un proxy) par défaut.

Cela plaide également en faveur de l'utilisation d'un SGBDR qui, bien souvent, reste à l'écoute d'un port particulier ce qui permet de s'adresser directement au serveur de base de données, sans devoir passer par le serveur web ;)

Mais bon, si tu n'as vraiment pas le choix...

L'idée sera de travailler dans une architecture en trois points qui utilisera:

• le serveur web
• la base acces
• l'application cliente

L'application cliente s'adressera (suivant le protocole http) au serveur web, qui déterminera les requêtes à adresser à la base de donnée acces et qui renverra (toujours suivant le protocole http) la réponse à l'application cliente.

L'idée n'est absolument pas impossible à réaliser...

L'avantage sera que tu n'aura finalement même plus à t'inquiéter de la liaison avec la base de données au niveau de l'application parce que, "tout" ce qu'elle devra faire, c'est se contenter d'interpréter correctement ce que le serveur web lui renverra et de transmettre en retour ses requêtes dans une forme que le serveur web sera en mesure de comprendre ;)

De son coté, le seveur web devra se charger de transmettre la requête correcte à la base de données et de créer, par exemple, un fichier au format xml qu'il se chargera de transférer vers l'application cliente

Par contre, si, comme je le subodore, le serveur web tourne sous windows, tu risques de devoir utiliser si pas ASP, au moins .NET pour la partie qui s'effectue de son coté :P

Les bibliothèques boost::serialize pour la récupération des flux xml et asio pour la gestion des flux réseau me semblent particulièrement intéressantes à utiliser...

Voici les réflexions qui me viennent à l'esprit au premier abord...

"Hope it helps"

Merci koala01 pour ta réponse,
si j'ai bien compris il faudrait que je crée également une petite application sur le serveur ? Mais malheureusement (et j'avais oublié de le préciser :roll:) je n'ai pas le droit d'y installer une application...

Dans ce cas quelle sont mes solution ?

Faut-il abandonner Access ?

Merci de votre aide

Oui, il faut abandonner access... La BDD access n'est à l'écoute d'aucun port qui pourrait te permettre de dialoguer avec elle via le réseau

C'est vrai que plus j'avance dans mes recherches plus sa me semble compliquer avec access :?
Donc si j'abandonne Access quelle SGBD me préconiserais-tu dans mon cas? Sachant qu'il faudrait après que je puisse développer une petite interface pour exploiter ses données et que il n'y aura surement jamais plus de 2 ou 3 utilisateur connecté en même temps.

Merci encore pour ton aide ;)

Citation:

---

Envoyé par projetge2i

C'est vrai que plus j'avance dans mes recherches plus sa me semble compliquer avec access :?
Donc si j'abandonne Access quelle SGBD me préconiserais-tu dans mon cas? Sachant qu'il faudrait après que je puisse développer une petite interface pour exploiter ses données et que il n'y aura surement jamais plus de 2 ou 3 utilisateur connecté en même temps.

Merci encore pour ton aide ;)

---

Oufff... Il est temps de se rappeler que les conseilleurs ne sont pas les payeurs :P:D

Je vais donc me contenter de citer quelques points qui t'aidront, je l'èspère, à faire ton choix ;)

Je dirais que tout dépend de si tu passe par un service d'hébergement spécialisé ou de si tu crée ton propre serveur... Et surtout du système d'exploitation utilisé pour ce faire.

Sous windows, il est possible d'installer SQL Server, MySQL et oracle
Sous unixoide, il est possible d'installer MySQL, Oracle et PosGreSQL.

Si tu as recours à un service d'hébergement sous Windows, tu aura facilement accès à du SQL Server et à du MySQL (*rarement* à de l'oracle).

Si tu as recours à un service d'hébergement sous linux, ce sera pluôt MySQL ou PosGreSQL.

SQL Server et Oracle ont des licences commerciales assez onéreuses, et sont de véritables "usines à gaz": très efficaces, mais lourdes à gérer au quotidien;)

MySQL est distribué sous double licence, commerciale et GNU/GPL: Si ton application est commerciale, tu devra payer la licence commerciale pour son utilisation (qui, me semble-t-il, est moins importante que les licences SQL Server et Oracle).

PosGreSQL est sous licence open source (Open BSD, me semble-t-il), et son utilisation est donc gratuite.

Un avis généralement assez présent de par le net est que, si tu peux choisir entre MySQL et PosGreSQL, tu as avantage à prendre le deuxième (PosGre).

Evidemment, il n'est pas exclu que j'aie oublié un ou l'autre SGBDR ou un point de vue objectif...

"Hope it helps"

Bonjour,
Je me permet de rajouter qu'il existe une section Base de données avec ses forum, ses FAQ et ses tutoriels. Tu pourras aussi y trouver de l'aide pour ton choix en fonction de ton besoin.

Je rajouterai juste que PostgreSQL fonctionne désormais nativement sous windows, et que donc, il n'y a plus aucune raison de s'en priver :).

Encore une fois merci pour tes lumières,

étant donné que la base de donnée qui sera présente sur le serveur ne contiendra que très peu de table et qu'on restera sur des requêtes basique je pense que je vais m'orienter vers MySQL. D'autant plus que l'hébergeur de mon serveur le gère sans problème.

En attendant bon weekend et bonne pâques !