Dans le cadre d'un développement en VB avec une utilisation d'un serveur et plusieurs clients, quel différence y a t il entre une base Access et une base SQL Server ?
Niveau performance, sécurité, espace mémoire, ... ?
 
Car pour certains développement où les 2 sont possibles, je me pose la question, comment faire le bon choix ?

c'est marrant, tu ne te poses pas de questions sur les licences logicielles ? car l'un comme l'autre, c'est payant et les différences sont flagrantes (les écarts de prix également)

Tout est différent. Access c'est bien pour une petite appli embarquée. T'as ton fichier (ou 2, front et back), et pouf ça marche. Ou alors si faut vite-fait faire un truc accessible sur plusieurs postes (genre 2 ou 3 en même temps). Bien-sûr petite appli, pas trop de données.
 
SQL Server, c'est le reste : les grosses architectures, le volume de données importants, des centaines d'utilisateurs en même temps, etc.

sgbd serveur versus sgbd fichier, tout dépends de ton utilisation....

sinon essaie SQL Express pour te faire une idée

 
Oui bien sur mais je cherchais d'abord des infos plutot sur les performances.
Par contre, je t'arrete quand tu dis que l'un comme l'autre est payant : avec Access, pas besoin de licence dans certaines conditions et grace au runtimes Access 2k3. (infos Microsoft France)
Pour SQL server, est-ce qu'il n'y a que la licence serveur ou est-ce qu'il y a également une licence client pour chaque utilisateur ?

Justement, le runtime Access 2003 est payant

 
Justement, je voulais surtout savoir jusqu'où on pouvait aller avec Access et à partir de quand est-ce qu'il faut absolument utiliser SQL Server ?
Par exemple 10 utilisateurs ?

10 ça commence à faire lourd

 
non, si le client à acheté un pack avec Access, il a le droit d'utiliser les Runtimes
et si le client n'a pas ce pack mais que le fournisseur du logiciel spécifique à certains logiciels, il a le droit de délivrer l'utilisation des runtimes au client.
ces infos ont été verifiées auprès de Microsoft France justement

Ah ben ça m'étonne, j'avais aussi vérifié Et c'est pas du tout ça que j'avais pu lire

 
on a eu confirmation au telephone par quelqu'un qui connaissait spécifiquemnt le pb ...

Voilà, si t'as Access, tu peux évidemment lancer des trucs Access. Par contre si tu l'as pas :

 
oui donc si toi en tant que prestataire, tu achète Access Developer Extensions, tu peux donc le distribuer à tes clients sans pb non ?

Voilà, c'est exactement ça, on est d'accord

 
ça va alors
 
pendant que j'y suis vu que tu as l'air de bien connaitre, je voudrais savoir si tu peux me donner ton avis sur le pb suivant :
 
Je suis en train de développer une application en VB6 pour un client.
Cette application à la base à été faite pour une utilisation mono-utilisateur en local donc j'ai utilisé une base Access.
Maintenant l'utilisation doit être différente :  
Il y a 5 sites distants (4 reliés par une liaison Oleane 1 Mb et 1 coupé totalement du net). Le logiciel doit etre utilisés sur les 5 sites en meme temps et les différentes versions de base de données doivent être mises à jour les unes par rapport aux autres pour qu'une modification faite sur le site X soit exploitable sur le site Y). Tous les sites n'ont pas de serveurs.
Une utilisation TSE est interdite et les échanges entre le site coupé de l'internet et les autres sites doivent se faire par une clé USB (ou disque externe). Il peut y avoir des taches définies pour faire des échanges la nuit.
La base ne devrait pas etre enorme en taille mais il y a des images associées et il peut facilement y avoir 500 Mo à exploiter au total.
 
Quelle est à ton avis la meilleure solution pour synchroniser les bases et les images entre elles ?

Ah ben tu tombes pile sur le cas où j'y connais que dalle Niveau Access, je n'ai que fait des applis mono-postes, ou des multi-postes en réseau local...
 
Sinon pour un truc distant comme ça, je pense qu'un vrai SQL server serait mieux, centralisé pour tous les sites. Sinon avec la réplication il est possible de synchroniser les bases, non ? Chaque enregistrement ayant un GUID, il est du coup possible de garantir l'unicité d'un enregistrement, et on peut du coup tout synchroniser

 
Et bien je pensais à SQL Server justement, c'est pour ça que je commence à m'interesser à lui mais pb : on a pas le droit d'utiliser la liaison internet dans la journée pour cette utilisation (car il y a déjà bcp d'échanges avec un autre logiciel et donc elle est déjà assez juste). De plus, le pb du site distant qui n'est pas relié à l'internet ne pourrait pas etre relié à SQL server, surtout qu'il n'y a qu'un reseau poste à poste sur ce site donc pas de possibilité de serveur.
Je chercherais surtout une solution à l'image de Rsync pour les fichiers, pour effacer les enregistrements en trop, rajouter ceux qu'il faut et trier les images associées en meme temps.

Comme dit, avec la replication, normalement t'arrive à synchroniser deux bases, j'avais vaguement lu des trucs à ce sujet... Faudrait que MagicBuzz vienne par là, il connaît bien tout ça

 
oki, je vais regarder de ce coté là alors. Je vais poster un nouveau message pour ce pb spécifique. merci à toi.

euh, j'arrive après la bataille, mais...
 
=> si tu mets un fichier MDB avec ton programme, y'a pas besoin de licence Access du tout. MDAC a tout ce qu'il faut pour y accéder. Deplus, les drivers ODBC permettent la création d'une base Access vide. Donc clairement, non, on peut très bien déployer une application qui utilise une base Access sans devoir déployer Access ni payer la moindre licence.
 
=> SQL Server Express est gratuit. Ses limitations sont suffisament larges pour permettre l'utilisation en production (autorisée par Microsoft) pour une petite structure : en effet, la principale limitation, c'est le nombre d'accès concurents;
 
=> Pour une vraie version de SQL Server, il n'y a pas à ma connaissance de limitation du nombre de clients. Autant pour les outils clients, il est possible qu'il y ait une limitation (mais j'en doute, puisqu'il sont fournis gratuitement avec SQL Server Express), autant pour accéder à la base, de toute façon on n'a pas besoin de composants clients (contrairement à Oracle par exemple).
 
Par contre, Access, ça coute dans les 1000 €.
SQL Server Entreprise Edition c'est plutôt dans les 15000 €
Donc forcément c'est pas le même budget.
 
En tout cas, entre Access et SQL Server Express, à partir du moment où :
- soit les données sont importantes
- soit les requêtes sont complexes
- soit le nombre de clients dépasse 3
 
Alors il n'y a pas photo, SQL Server Express sera infiniment plus puissant.

vous pouvez me faire un petit topo ?
j'ai pas tout lu pis y'a trop long à lire
 
à la base, je maîtrise pas du tout la réplication, j'ai toujours travaillé avec des serveurs stand-alone (la réplication, je vois pas trop dans quelles circonstances ça peut être utile... mise à part peut-être la nécessité d'avoir un uptime de 100% et encore)

Ah merde, toi non-plus tu connais pas trop la réplication

bah ça sert surtout pas à grand chose au commun des mortels
 
y'a vraiment que sur les très gros systèmes que ça a un intérêt, et de ce cas, on préfère souvent le culstering à laréplication

 
en fait mon pb, c'est que je dois pouvoir n'avoir qu'une seule version de base de données avec des sites distants qui n'ont aucune laision internet entre eux et dans lesquels chacun doit pouvoir faire évoluer la base de son coté et qu'une fois par jour toutes les différentes versions de base soient fusionnées de façon à récolter le travail de chacun tous les jours.
c'est des circonstances assez spéciales, certes ...

je rajouterai aussi que dans le cas ou l'on utilise aucune des fonctionnalités d'access, formulaires, etats, etc... pourquoi le trainer derriere soi? SQL Server Express est plus adapté si tu ne veux utiliser que la partie sgbd.
 
access est interessant pour moi si tu fais tout le developpement dessus.

 
car certains postes sont indépendant du réseau et non reliable à un serveur et c'est assez lourd d'installer SQL serveur si c'est pour fonctionner en local

Malgré ce qu'on pourrait penser, access reste tres performant, parfois meme plus que SQL Server dans certains cas tres spécifiques .
 
Seulement des que il y plus d'1 utilisateurs sur cette BD les performances secroulent et deviennent vraiment mediocres. De plus dés qu'une mdb fait plus de 2go de taille c fini plus rien nest gere correctement (sous 2003 en tout cas).
 
Bref access cest tres bien si
 
- tu as des petit volumes de données a gerer
- tu as tres peu d'utilisateurs dessus

 
j'aurais besoin d'une info à ce propos. est-ce que mono utilisateur veut dire obligatoirement 1 seule connexion ouverte dessus ? je m'explique.
dans la solution retenue à mon pb, ça va fonctionné ainsi :
1 serveur sur un site sur lequel sera installé le logiciel développé autour d'une base access. et plusieurs client Terminal Serveur qui vienne ouvrir une session et utiliser ce logiciel en meme temps sur une session différente. car dans un sens il ne va y avoir qu'un seul logiciel qui va dialoguer avec la base mais plusiers "sessions" de ce logiciel en meme temps par contre.

Dans ce fonctionnement, c'est multi-utilisateur.
Il faut donc s'attendre à de mauvaises performances d'Access.
 
En fait, le souci, c'est surtout qu'il faut vérifier les options d'ouvertures de recordset dans l'appli, et banir tous les recordsets dynamiques (valeur par défaut dans VB).
 
Un rs dynamique en effet, c'est bien pratique parcequ'on peut le mettre à jour, mais du coup, avec Access, ça lock la (les) table(s) source(s).
 
Si c'est pour déployer l'appli de cette façon, je recommande très fortement d'utiliser SQL Server Express à la place. D'autant que remplacer Access par SQL Server, ça devrait représenter à tout casser 1 heure de travail.

 
je ne suis pas sur de ce que veut dire recordsets dynamiques mais je pense que je n'en utilise pas. Je fais tout avec des requetes SQL directement.
ce qui veut dire peut etre aussi qu'il suffit de changer les 2 lignes de connexions à la base pour passer à SQL Server Express ?

un recordset dynamique, ça se paramètre dans les options du recordset.
 
un rs dynamique permet de lire dans n'importe quel sens, être notifié des mises à jours de la base "en temps réel" ou même de modfier les données de la bases sans passer par des requêtes.
 
il faut regarder dans les rs.Open() le premier paramètre, c'est la requête, et les suivants indiquent si le rs est dynamique, forwardonly, côté serveur, etc. pour de meilleurs performances avec access, il faut tout mettre en minimum (static, côté serveur et forwardonly)
par défaut, c'est l'inverse (dynamique, côté client et randomaccess)

 
le truc c'est que j'ai pas de rs.Open() ...
je fonctionne comme ça :
 
Public BDD As DAO.Database
Public Req As DAO.Recordset
 
Set BDD = OpenDatabase(BDD_Path, False, False, ";PWD=" & Password_BDD)
 
Set Req = BDD.OpenRecordset("Select * From [table1] where [champ1]=""" & truc & """" )
If Req.RecordCount <> 0 Then
   Do While Not Req.EOF
       Var1 = Req.Fields("champ2" ).Value
       Req.MoveNext
    Loop
End If
 
c'est pas bien comme ça ?

ah ouais, tu bosses comme un goret avec les fonctions proprio d'access...
 
ben regarde si y'a des options à OpenRecordset(). si y'en a pas :
1/ t'es de la baise
2/ c'est pas une heure qu'il faut pour changer de SGBD, mais facilement une journée si le projet n'est pas trop gros

 
dans quel sens est-ce que tu dis ça ? au niveau performances ou au niveau syntaxe ?
dans les options possibles de OpenRecordset, il y a Dynaset,Snapshot et ForwardOnly

forwardonly
 
habituellement, quand on bosse proprement avec une base de données, même dans Access, on n'utilise pas les méthodes de merde fournies par Access, mais on utilise une connection DSN Less via OLEDB.
 
Ca permet de :
1/ Standardiser le code de l'application
2/ Permettre l'utilisation de sources de données alternatives à la base locale (tu peux distribuer une application Access qui n'utilise pas la base de données Access)
 
Du coup ça permet une mainenance et une évolutivité vers VB bien plus souple.

 
mais je suis déjà en VB (il n'y a que la base qui est en Access), qu'est-ce que tu entends par évolutivité vers VB ?

Une petite question bête: pourquoi avoir le choix entre access et sql serveur Pourquoi ne pas avoir le choix entre access et un sgbd
 
Dans ce cas autant s'orienté vers des solutions gratuites permettant éventuellement du clustering, genre mysql

c vrai quoi autant utiliser un sgbd opensource bien pourri ou Oracle qui coute la peau du q et demande davoir fait inge +7 pour l'installer et lutiliser corrrectement...

surtout que SQL Server 2005 Express est gratuit, supporte environ 99% de la syntaxe proprio d'Access, permet infiniment plus de choses que MySQL, et autant qu'Oracle.
c'est un très très mauvais choix. Pas assez cher, ne nécessite pas assez de travail à mettre en place, et permet de faire une application bien trop évoluée.
à banir de toute urgence !