Bonjour,

Dans une maison médicale, toutes les machines (Desktop) sont sous Windows7 et ont accès aux sources (fiches médicales) des patients sur une...d'entre elles.
D'abord c'était un via un 'share', maintenant, le fournisseur a jugé qu'il y avait trop de fiches et que donc pour des performances meilleurs, il a basculé le tout sur un MS SQL, toujours sur une des machines clients.
Beurk.


Les 2 serveurs (Mail, DHCP, Asterisk, Samba, PDC, Firewall,...) internes sont sous Linux (of course) mais le fournisseur ne supporte pas MySQL ou tout autre chose compatible avec le manchot.

Bref.
- Je voudrais bien centraliser les sources sur une machine plus robuste et ne plus demander à un Desktop de jouer les serveurs (et son disque d'usiner sans cesse)
- Je voudrais bien avoir un backup de ces données très précieuses: lorsque c'était un bête "share", mon serveur linux était crontabé la nuit pour pomper tout en mount CIFS et cela roxait pas mal), aujourd'hui, si le desktop lache, on perd tout.

Soit j'ajoute une machine un peu correcte dans la danse sous Win 7/2008 Server, soit je fait une virtuelle sur un serveur.

Mais restera le problème du backup.
Ou alors on prend tout d'un coup avec un ghost

La solution virtuelle a ceci de séduisant c'est qu'on peut la snapshoter la nuit et faire des backups sur une autre machine et la recopier/relancer à souhait en cas de pépin...

Et vous, vous feriez comment ?

Une VM windows dont le démarrage est automatisé sur ton linux, et un share sur le windows accessible depuis ton host linux pour le backup.

Ceci pourrait t'être utile :
http://code.google.com/p/phpvirtualbox/

Ahhh mais cela sent très bon du zizi tout cela!
J'avais testé VMware serveur 2 avec son interface web il y a 2-3 ans, c'était complètement installable (version gratuite aussi, je sais...)

Ceci me semble pas mal du tout, vais un peu creuser.

Si les applications client passent par ODBC pour attaquer une DB MSSQL, il est possible en installant le plugin kivabien d'attaquer une DB Mysql

Bon, il faut se taper, l'export/import de la DB de/vers MSSQL/Mysql

Si c'est du code .net, il y a peu de chance de passer par de l'odbc... vu qu'il existe un connecteur natif.

Par contre, sqlserver a des fonctions de backup assez poussées. Il suffit donc de demander gentiment à sqlserver de faire un backup de la db en local tous les soirs dans un répertoire partagée ^^ Après, c'est tout pareil qu'avant.

dan> tu penses bien que si c'était sous ma responsabilité (les sources, pas le parc IT), j'aurais déjà bien joué de la moulinette et baqué le MS SQL !

altar> très bonne piste aussi ça! je vais regarder, mais c'est à mettre en oeuvre de toutes façons avec la centralisation du serveur DB, pas question de laisser cela sur un simple Desktop.

ové> ce phpvbox est une tuerie. En 10 min je pouvais avoir un remote manager de vbox! Le truc c'est que vboxweb doit tourner, et que Debian n'a pas fourni le init script kivabien. Vais un peu devoir bricoler pour un démarrage auto au (re)boot.
Après, faudra voir les perfs de tout le bazar.

Si j'ai bien compris, tu n'as accès aux "fiches" que d'une seule machine?
Pourtant le but de MS SQL (ou tout autre base de donnée) c'est d'avoir plusieurs accès non?

Si tu sais en quoi/comment est coder le programme, il y a p-e moyen via un fichier de configuration de passer par une autre base.

Et puis, pourquoi tu ne demandes pas au fournisseur du programme en question?

Oui donc visiblement je ne me suis pas bien exprimé: la DB MS SQL est bien visible et accessible par tous les utilisateurs. Le service quotidien est impeccable, si ce n'est que c'est lent (et pour cause). Ce qui m'inquiète principalement, c'est que cette DB tourne sur un Desktop (et non sur un serveur) et qu'il n'y a aucune procédure de backup de celle-ci

Le soft en question est assez robuste et "fermé", la configuration n'inclu pas d'autre partage des sources que via un share (comme avant, pratique pour les Backups) ou MS SQL.

Le fournisseur consulté me confirme tout cela et brandi la possibilité de de synchroniser les sources en local sur la machine de chaque médecin. Par définition, c'est fort maigre de se reposer sur des backups réalisé par des utilisateurs.

Vu que le "responsable" de la db c'est le fournisseur, il devrait te fournir une procédure de backup, ou au minimum, un truc a exécuter pour créer un dump de la db en question.

Coté soft, le fournisseur l'a donc si il "s'efface" ils savent te le remettre sans soucis (enfin en théorie)

mmmh maintenant je me rends compte que cette phrase n'est pas si anodine...
En fait, cela n'a rien à voir avec phpVbox....