Bonjour,
(cb6)
Existe-t-il un moyen de créer un disque virtuel sans recourir à une application extérieure ?
Merci pour vos retours.
Version imprimable
Bonjour,
(cb6)
Existe-t-il un moyen de créer un disque virtuel sans recourir à une application extérieure ?
Merci pour vos retours.
Qu'entends-tu par "disque virtuel" ?
Bonjour Bacelar,
merci de t'intéresser à mon problème.
Il s'agit de créer un disque, comme on peut le faire via la Gestion de l'ordinateur/Gestion des disques/Créer un disque dur virtuel.
Le but étant d'y copier des fichiers qui seront systématiquement détruits à la fermeture du PC.
J'ai du mal à voir le rapport entre
etCitation:
Il s'agit de créer un disque, comme on peut le faire via la Gestion de l'ordinateur/Gestion des disques/Créer un disque dur virtuel.
Le premier, c'est de faire un dialogue avec le Kernel pour qu'il fasse son travail de création d'un Disk "à sa sauce".Citation:
Le but étant d'y copier des fichiers qui seront systématiquement détruits à la fermeture du PC.
Le second, c'est implémenter un système de sécurité, si je ne me trompe pas.
J'ai du mal à comprendre comment votre démarche s'intégrer dans des mécanismes standards de sécurité, mais bon.
Pour implémenter un "virtual disk" où vous pourrez faire tout ce que vous voulez : https://www.codeproject.com/Articles...sk-for-Windows
Ce procédé me semble bien lourd à mettre en place.
Par ailleurs, il nécessite l'installation de Windows Driver Developer Kit.
Or, j'ai précisé que je ne pouvais par recourir à des applications externes.
N'y aurait-il pas une option plus light ?
Merci.
Un disque virtuel c'est loin d'être un objet simple.
Peut-être que si tu disais vraiment ce que tu comptes faire on pourrait te dire que non un disque virtuel n'est pas la solution et t'indiquer un autre truc.
Parce que bon si c'est juste pour supprimer les fichiers à l'extinction du pc... un simple script de suppression lancé à l'extinction et au démarrage et t'as gagné. :calim2:
Mon application est distribuée sur des postes utilisateurs en réseau (pas de disque C).
L'application et sa base de données sont donc logées sur l'un de ces serveurs.
Je souhaite qu'à son lancement, l'application et la base frontale soient copiées sur ce "disque virtuel" afin d'éviter un encombrement du serveur (qui est déjà lent) en raison d'un grand nombre d'utilisateurs connectés.
Peut-être me direz-vous qu'un "clone" du serveur ne résoudra en rien mon problème mais c'est la solution à laquelle j'avais pensé.
Quel est l'intérêt du serveur ? Est-ce que les utilisateurs communiquent avec sa base de données ?
Si oui tu es forcément obligé d'avoir une connexion au serveur de toute façon. SI le serveur est lent, il est temps de l'upgrade ou au moins de le clean.
Si c'est juste pour télécharger l'application, pourquoi ne s'agit-il pas d'un installer à récupérer ? Avec mise à jour de l'application au lancement.
A quoi ressemble l'application ? Pourquoi ne pas faire un client léger via un browser web ?
Pourquoi ne pas mettre toutes les données en RAM ?
Je ne suis pas l'administrateur du système.
Oui, les utilisateurs communiquent avec la base de données frontale et la mise à jour de la dorsale se fait in fine par lots.
Je souhaite donc que les modifications apportées par les utilisateurs s'opèrent sur la frontale résidant sur un espace à part et que la dorsale sur le serveur ne soit mise à jour qu'au sortir de l'application.
Nombreuses connexions à la frontale par l'utilisateur et une seule au serveur lors de la fermeture.
Attention, si tu changes le chemin de la frontale, tu peux briser le lien entre la frontale et la dorsale.
On a trop peu d'éléments.
C'est quoi comme type de base ?
Le lien entre frontale et dorsale est renoué à chaque lancement.
Il s'agit d"une base ACCESS (je sais c'est un peu limite mais le système ne me permet pas d'utiliser plus performant).
Comme l'a indiqué @Bousk, un disque virtuel, c'est pas un joujou qu'on fait sur un coin de table.Citation:
Ce procédé me semble bien lourd à mettre en place.
Et je ne vois toujours pas l'utilité de ce machin super-complexe dans votre problématique.
Je pense que vous faites complètement fausse route avec ce "disque virtuel".
Vous n'avez donc absolument pas compris ce qu'est un SDK, comme de Windows DDK.Citation:
Par ailleurs, il nécessite l'installation de Windows Driver Developer Kit.
Or, j'ai précisé que je ne pouvais par recourir à des applications externes.
C'est un ensemble d'outils, de code, de fichier d'en-tête, de librairies, pour faire des applications, ou des drivers dans le cas du Windows DDK.
Ces des briques de bases pour votre chaine de compilation.
Oui, correctement analyser votre problème initial et ensuite concevoir une architecture pour la solution qui ne ressemble pas à une usine à gaz.Citation:
N'y aurait-il pas une option plus light ?
C'est à dire ?Citation:
Mon application est distribuée sur des postes utilisateurs en réseau (pas de disque C).
Des Network computer, donc sans même un "vrai" disque dur ???
C'est donc une vieille architecture Client/Server pas super "scalable" ???Citation:
L'application et sa base de données sont donc logées sur l'un de ces serveurs.
Et pourquoi toute cette ribambelle de base de données à synchroniser plutôt qu'un simple client/server avec connexion par polling pour avoir une meilleur "scalabilité" ?Citation:
Je souhaite qu'à son lancement, l'application et la base frontale soient copiées sur ce "disque virtuel" afin d'éviter un encombrement du serveur (qui est déjà lent) en raison d'un grand nombre d'utilisateurs connectés
A moi de ne rien comprendre à votre problème initial, oui, je pense que cela ne résoudra rien à votre problème mais ajouterait un énorme niveau de complexité et une chute du niveau d'utilisabilité de votre application.Citation:
Peut-être me direz-vous qu'un "clone" du serveur ne résoudra en rien mon problème mais c'est la solution à laquelle j'avais pensé.
La "solution" que vous proposez ressemble, dans votre discours, à une approche base centrale/base déportée sauf que ce n'est absolument comme cela que s'implémente.
Il faut passer par de l'outillage spécifique à ce type de solution.
Il existe bien des solutions plus légères que ce type d'approche, à réserver à des cas particuliers, comme des connexions réseaux non-permanentes.
Et ?Citation:
Je ne suis pas l'administrateur du système.
La solution que vous devrez choisir devra de toute façon avoir l'aval de vos administrateurs système/réseaux/sécurité.
C'est un mode d'utilisation extrêmement dégradé, est-ce déjà le cas actuellement ou est-ce un effet de votre "solution" ?Citation:
Oui, les utilisateurs communiquent avec la base de données frontale et la mise à jour de la dorsale se fait in fine par lots.
Je souhaite donc que les modifications apportées par les utilisateurs s'opèrent sur la frontale résidant sur un espace à part et que la dorsale sur le serveur ne soit mise à jour qu'au sortir de l'application.
Quitte à avoir déjà ce type de workflow asynchrone, autant passer par des outils dédiés plus fiables comme les files de messages MSMQ, ou autres.
C'est quoi cette architecture de shadocks ???Citation:
Nombreuses connexions à la frontale par l'utilisateur et une seule au serveur lors de la fermeture.
Normalement, il n'y a qu'une connexion entre le serveur frontal et l'utilisateur tout au long d'une interaction client/serveur.
S'il y a plusieurs connections transitoires entre l'utilisateur et le serveur, il n'y aurait pas de problème de monté en charge et donc le problème n'aurait pas lieu d'être.
EDIT :
Bon, bin, la solution est évidente, on dégage ACCESS !!!Citation:
Il s'agit d"une base ACCESS (je sais c'est un peu limite mais le système ne me permet pas d'utiliser plus performant).
Bacelor, je trouve votre ton narquois et passablement agressif.
Merci néanmoins d'avoir passé du temps à tourner vos phrases.
Pouvez-vous répondre à mes questions "narquoises", SVP. ;)
En l'état je vois 3 solutions
- laisser tomber ce nouveau client
- laisser tomber Access
- se moquer du potentiel problème lié à Access