Exploitez au maximum les services d'arsys.fr

La méthode conseillée pour publier des bases de données sur Internet est d'utiliser un serveur de bases de données, car c'est un système beaucoup plus robuste et scalable que des fichiers individuels comme les bases de données Access, les fichiers de texte brut, etc.
Vous disposez de bases de données SQL Server, sous Windows, à partir de notre Pack Entreprise, et sur notre produit SQL Server sur lequel vous pourrez également accéder depuis un hébergement externe. Si vos besoins d'espace ou de rendement de SQL Server sont très élevés, il est également possible de commander un Serveur Dédié SQL Server.
Pour pouvoir gérer directement vos bases de données MS SQL Server et l'espace disque correspondant, vous disposez de:
Les accès sont limités aux tâches de maintenance et/ou synchronisation des données. L'utilisation de programmes exécutables qui accèdent au serveur de données, comme une partie de son fonctionnement habituel, n'est pas autorisée. On admet que le serveur de données est utilisé, principalement, par les applications web de votre domaine (scripts CGI, ASP…).
Un serveur de bases de données est un programme qui stocke des données structurées sous forme de tables relationnelles. Il communique avec un port TCP/IP à travers lequel il accepte des connexions avec des clients authentifiés, admet des requêtes en langage SQL, et le client reçoit en retour les données issues du traitement des requêtes SQL.
Dans cette section, nous tacherons de vous montrer les différences entre un serveur de bases de données et système de bases de données plus simple comme par exemple Access, FoxPro, dBase....
Le serveur de bases de données que nous utilisons chez arsys.fr est Microsoft SQL Server. Parmi ses avantages nous soulignons:
On parle souvent de bases de données Access pour faire référence aux fichiers *.mdb. Ceci n'est pas correct. Access ne crée pas et ne gère pas directement les fichiers mdb, ceci est fait par le moteur Jet de Microsoft.
En fait, il est possible de créer sous Windows un fichier mdb, et même de le remplir de tables et de données, sans avoir Access. Il suffit pour cela d'employer ODBC ou ADO avec des programmes en Visual Basic ou même des scripts en Perl.
Bien sûr c'est le plus complet, mais un programmeur pourrait créer son propre "Access sur mesure" avec Visual Basic ou un autre langage de programmation. La logique du traitement de ces fichiers (interprétation des requêtes SQL, création de tables...), se trouve dans les DLL qui forment le moteur Jet.
Par conséquent, si on veut faire des comparaisons entre SQL Server et les fichiers mdb, il faudra comparer SQL Server et le moteur Jet de Microsoft.
Les similitudes sont:
En ce qui concerne les différences, elles sont plus complexes:
Cette différence est très importante pour la publication de bases de données sur Internet, et au fond c'est un point clé qui fait que nous choisissions SQL Server au lieu de Jet.
Imaginons qu'on utilise des fichiers mdb et il y a un problème avec les données. Comme Jet s'exécute dans l'espace mémoire du serveur web, il est possible qu'il soit affecté et que les pages web du site ne s'affichent plus, ce qui serait catastrophique. Ceci ne pourrait jamais arriver avec SQL Server.
Dans ce domaine, c'est comme un serveur web ou un serveur de courrier. La différence est le numéro du port et, évidemment, le protocole utilisé pour communiquer avec le client. Un navigateur est un client pour un serveur web, mais il ne connaît pas le protocole qui permet de communiquer avec un serveur de bases de données. Par exemple, Access 2000 ou Access XP sont des clients pour SQL Server.
Bien qu'il soit possible de créer des applications qui travaillent en réseau avec des fichiers .mdb (avec Visual Basic ou Access), l'usage du réseau se limite au fait que le fichier mdb se trouve sur un ordinateur différent de l'application. Cependant, tout le processus se réalise sur une seule machine. Le réseau joue simplement le rôle de disque dur.
La programmation client-serveur s'utilise lorsqu'on veut mettre en place des applications qui utilisent des réseaux et qui font communiquer plusieurs ordinateurs entre eux. Il s'agit essentiellement d'un programme qui se décompose en deux parties:
Les deux parties de l'application communiquent entre elles au moyen d'un protocole de réseau TCP/IP. Ce qui justifie ce fonctionnement est la réduction du trafic réseau, surtout pour éviter les ralentissements et économiser la bande passante.
SQL Server admet des procédures stockées (stored procedures) réalisées en langage SQL.
Pour Jet l'accès simultané aux données est plus une exception, que quelque chose d'habituel. Il dispose d'un système de blocage (les fichiers ldb), mais il n'a pas été fait pour que de nombreux clients essaient d'accéder simultanément aux données.
C'est un serveur qui peut gérer simultanément autant de clients que le permet la puissance du matériel de la machine où il est installé.
Par exemple, on pourrait faire une actualisation qui synchronise les tables locales avec celles du serveur, en rajoutant des données s'il y a lieu. La caractéristique Client-serveur décrite auparavant se manifeste ici de cette manière : il est possible d'accéder à la base de données du serveur moyennant un client connecté à Internet.
A partir des versions 7.0 de SQL Server et 2000 d'Office, gérer une base de données en SQL Server est aussi simple qu'en gérer une avec Access. Tout ce qu'on a appris avec Access est valable pour les bases de données SQL Serveur : visites, rapports, formulaires....
Access 2000 incorpore une caractéristique appelée projets (fichiers .adp).
Une autre manière de gérer votre base de données SQL Server est d'installer vous même SQL Server sur votre ordinateur ou réseau local.
Access 2000 comprend un Assistant pour convertir à SQL Server. Il se trouve dans Outils / Utilitaires de la base de données.
L'assistant sollicite les données suivantes:
Choisissez l'utilisation d'une base de données existante. Vous n'avez pas les permissions de créer des bases de données sur notre serveur, vous ne pouvez créer que la vôtre. L'assistant affiche la fenêtre "Selectionner l'origine des données". Si vous aviez déjà crée un DSN pour accéder à SQL Server utilisez-le, sinon vous pouvez le créer maintenant (en cliquant sur le bouton Nouveau...). Si vous devez créer l'origine des données (le DSN), utilisez les données suivantes:
Il est recommandé d'être connecté à Internet lorsqu'on crée le DSN pour pouvoir tester l'origine de données.
Vous pouvez choisir simplement d'exporter les données vers SQL Server, associer ces tables à une application existante, ou créer un nouveau fichier projet (application Client-serveur stockée dans un fichier .adp).
Les projets .adp d'Access ne permettent pas de modifier les tables SQL s'il ne leur est pas défini une clé primaire. Ceci est à prendre en compte lors de la modification de données.
ADO (ActiveX Data Objetcs) permet d'accéder de la même manière à des bases de données indépendamment de son origine. Si vous utilisez actuellement ADO pour accéder aux bases de données mdb, vous devrez changer très peu le code pour pouvoir utiliser SQL Server. En fait, la seule différence se trouve dans la chaîne de connexion.
Si vous utilisez les bases de données .mdb, la chaîne de connexion sera du genre:
"DSN=mondsn"
Si vous utilisez SQL Server, vous devez ajouter le login et mot de passe:
"DSN=mondsn;UID=login;PWD=motdepasse"
A part ça, rien ne change.
Le DSN pour accéder à SQL Server s'obtient sur le panneau de contrôle de votre service d'hébergement.
Dans ce dernier cas, il est nécessaire d'écrire un login et mot de passe dans un fichier texte (ASP) : pousser les précautions à l'extrême aussi bien sur le serveur (par exemple interdisez l'accès en lecture sur le répertoire où se trouvent les ASP) que sur les personnes qui ont accès à votre ordinateur de travail habituel ou à vos copies de sécurité locales.
* les prix affichés sont HT.
Appel Gratuit 0800 940 865