copie de certaines tables ds une base de données

Bonjour,
je suis en train de developper une application client/serveur avec une base de données sql express
La plupart du temps, le client sera connecté au serveur mais j'aimerais qu'il puisse egalement fonctionner en mode autonome de temps en temps.
si par exemple la connexion reseau est rompu,etc...
pour permeettre ce mode de fonctionnement autonome je n'ai besoin que de quelques tables indispensables au fonctionnement de la machine (pour les opérations les plus "pressées")

La se pose la question de que dois je faire ?

1-dois je créer une base de données semblable avec les memes noms de tables etc...
ou bien créer d'autre tables ds la base de données existante
(dans la suite je pense vouloir pouvoir repliquer egalement ma base de données d'un poste à l'autre en cas de "cramage" de serveur.)

je pensais donc créer une meme base de données (dont je mettrais la structure a jour de l ameme maniere mais avec un autre nom de base...

et dans mon programme , utiliser une chaine de connexion differente pour me connecter sois au serveur , soit a ma table...

quand je me connecte au serveur :
1-le programme va chercher les modifs de structure (selon un numero de version de bd par exemple) et les mettre a jour
2-ensuite il va recuperer (s'il yen a des données qui ont été écrites ( je connais les tables)
puis les supprimer ou les marquer une fois la transfert effectué
3- ensuite vient la partie "compliquée", la mise a jour des données dont j'ai besoin pour fonctionner en mode autonome :
-le plus simple mais "bourrin", je supprime toutes les données ds le bon odre(ca c un peu compliqué a partir des contraintes d'intégrité)
je recopie ttes les données des tables du serveur (ds le sens contraire a la suppression pour les contraintes d'intégrité)
-ou bien je choisi une solution plus intelligente , genre avec un journal des mises a jours mais qui risque d'etre assez difficile aussi a mettre en place...(et je vois pas trop coment)
ou on va modifier les lignes a modifier ds chaque table, inserer les nvelles lignes, supprimer celles qui ont été supprimées,etc...
-ou bien ue autre solution a laquelle j'ai pas pensé

Je cherche bien sur la solution la plus simple a mettre en place et la plus rapide d'execution...

si quelqu'un a deja eu ce genre de probleme a resoudre ou s'il existe des sujets la dessu je suis preneur

merci

Salut,
je vais essayer de te donner quelques orientations possibles, en espérant que certaines te serviront!

Fonctionner en mode "autonome" dans une architecture client/serveur, c'est un truc à se casser le nez.. si le réseau est coupé et que 2 utilisateurs travaillent en même temps en mode perso (donc chacun sur une base locale par exemple), l'un peut envoyer un update sur un enregistrement, alors que l'autre de son côté aura supprimé ledit enregistrement. Quand tu vas tout remettre ensemble dans ta base, ça va être le bordel! Ceci étant dit, imaginons un tel fonctionnement et voyons ce qu'on peut en faire.

Une solution qui me paraît assez simple (en tout cas dans le concept!), c'est l'idée du journal. Ce journal peut être un objet en mémoire que tu sauvegarderas sur disque en cas de besoin (perte de la connection), ou directement un fichier (que tu effaceras à la fermeture de l'appli si y'a pas eu de pb pendant le travail), le mieux étant XML pour structurer tes données et les exploiter facilement.

Fonctionnement:
Ton appli se connecte au serveur. Tu mets à jour ta base locale (si quelques tables suffisent, ne prends que celles-là!). Par exemple, tu récupères un dataset qui contient des dataTable, chacune contenant le résultat d'un 'select * from une_table' de ta base principale. Pour être sûr de ne pas figer ton appli (selon le volume de données à récupérer), tu peux faire ça dans un thread séparé qui tournera en arrière-plan.
Toutes les requêtes que tu envoies (BDD principale),

Salut,
je vais essayer de te donner quelques orientations possibles, en espérant que certaines te serviront!

Fonctionner en mode "autonome" dans une architecture client/serveur, c'est un truc à se casser le nez.. si le réseau est coupé et que 2 utilisateurs travaillent en même temps en mode perso (donc chacun sur une base locale par exemple), l'un peut envoyer un update sur un enregistrement, alors que l'autre de son côté aura supprimé ledit enregistrement. Quand tu vas tout remettre ensemble dans ta base, ça va être le bordel! Ceci étant dit, imaginons un tel fonctionnement et voyons ce qu'on peut en faire.

Une solution qui me paraît assez simple (en tout cas dans le concept!), c'est l'idée du journal. Ce journal peut être un objet en mémoire que tu sauvegarderas sur disque en cas de besoin (perte de la connection), ou directement un fichier (que tu effaceras à la fermeture de l'appli si y'a pas eu de pb pendant le travail), le mieux étant XML pour structurer tes données et les exploiter facilement.

Fonctionnement:
Ton appli se connecte au serveur. Tu mets à jour ta base locale (si quelques tables suffisent, ne prends que celles-là!). Par exemple, tu récupères un dataset qui contient des dataTable, chacune contenant le résultat d'un 'select * from une_table' de ta base principale. Pour être sûr de ne pas figer ton appli (selon le volume de données à récupérer), tu peux fai

Salut,
je vais essayer de te donner quelques orientations possibles, en espérant que certaines te serviront!

Fonctionner en mode "autonome" dans une architecture client/serveur, c'est un truc à se casser le nez.. si le réseau est coupé et que 2 utilisateurs travaillent en même temps en mode perso (donc chacun sur une base locale par exemple), l'un peut envoyer un update sur un enregistrement, alors que l'autre de son côté aura supprimé ledit enregistrement. Quand tu vas tout remettre ensemble dans ta base, ça va être le bordel! Ceci étant dit, imaginons un tel fonctionnement et voyons ce qu'on peut en faire.

Une solution qui me paraît assez simple (en tout cas dans le concept!), c'est l'idée du journal. Ce journal peut être un objet en mémoire que tu sauvegarderas sur disque en cas de besoin (perte de la connection), ou directement un fichier (que tu effaceras à la fermeture de l'appli si y'a pas eu de pb pendant le travail), le mieux étant XML pour structurer tes données et les exploiter facilement.

Fonctionnement:
Ton appli se connecte au serveur. Tu mets à jour ta base locale (si quelques tables suffisent, ne prends que celles-là!). Par exemple, tu récupères un dataset qui contient des dataTable, chacune contenant le résultat d'un 'select * from une_table' de ta base principale. Pour être sûr de ne pas figer ton appli (selon le volume de données à récupérer), tu peux faire ça dans un thread séparé qui tournera en arrière-plan.
Toutes les requêtes que tu envoies (BDD principale),

Wouah, y'a eu comme un souci!!

bon, voilà la fin du message (si tout va bien!!)
Toutes les requêtes que tu envoies (BDD principale), tu les copies dans un script SQL (pas la peine de les exécuter sur ta base locale si t'en as pas besoin, ça rallongerait le traitement inutilement!).
Tu perds ta connection... tu te connectes à ta base auxiliaire, tu exécutes ton script pour la mettre à jour.
A partir de là, toute les opérations sur la BDD effectuées dans ton appli (sur la base locale) doivent être consignées dans ton journal. Exemple:


Evidemment, tu peux aussi bien les mettre directement dans un script SQL, que tu n'auras qu'à exécuter dans ta BDD, mais le XML te permet de tout stucturer comme tu veux, d'appeler des procedures stockées, de passer des paramètres, d'ajouter l'heure d'envoi de la requête etc...

Quand tu auras récupéré ta connection, tu recharges ton fichier pour appliquer les modifs dans ta base.

Pour ce qui est du problème dont j'ai parlé au début (update sur un enreg déjà supprimé par quelqu'un d'autre), tu peux créer des triggers sur les tables en question (BDD principale), de manière à ce que chaque enregistrement supprimé soit d'abord copié dans une table Historique (ou Récup ou ce que tu veux), pour qu'en cas de problème l'administrateur de la base puisse vérifier et récupérer les données si besoin...

Voilà, j'espère avoir pu t'aider un peu..

Si l'envie te prend de travailler, assied-toi et attend qu'elle te passe! (vieux -et faux!- dicton corse)

Merci pour ces reponses, et des dangers que cela représente...
je ferais attention a ce le mode de fonctionnement autonome ne produise pas de probleme
en fait ce sera un poste de caisse par exemple : il ne vendra dc que des articles
cela ne devrait pas créer de conflit avec autre chose ...
pour l'instant je ne ferais pas de update ou quoi que ce soit
j'ajouterais juste des lignes de ventes ... ds un fichier en local...
c tout
j'ai donc besoin de la liste des produits, deux trois trucs comme ca mais je fais pas de modif
par contre j'ai pas capté l'histoire du journal...
ta réponse souleve maintenant 2 questions :

En mode autonome
1 - Au lieu d'ecrire les données ds ma bdd locale , j'ecris ds un xml ?
la bd ne me sert que de lecture ?

En mode client/serveur
(le 1 correspond a ce que je pensais faire (sans journal...)
1 - je rapatrie les lignes que j'ai créées vers le serveur, puis je le supprime ou les marques comme transférées

2 - la recuperation des tables dont j'ai besoin : ( je voudrais savoir la procedure a suivre...)
- je fais un dataset avec ttes les tables dont g besoin
- je definis la connexion a la base du serveur
- je charge les n tables avec n fill correspondants
- je change la connexion vers la connexion de ma bd locale
- je fais n update vers ma base locale

?? ds un certain ordre pour respecter les contraintes d'integrité je suppose ?

alors ca yest j'ai un souci...
j'ai chargé ttes mes tables ds un dataset avec des fill...
maintenant je sais pas comment changer la connexion pour faire les update vers l'autre bd ???

En fait, tout est possible, c'est une question de choix!
mode autonome:
quitte à avoir une BDD en local, autant travailler dessus, mais il faut copier les actions dans un xml... ça fait un peu lourd. En plus, la question peut se poser de savoir quel est l'intérêt du client/serveur si tu dois installer un serveur de base de données sur le client!! A moins de choisir un système sans serveur de BDD, style Access (au hasard), où il suffit d'avoir un fichier .mdb et un moteur Jet. Maintenant, c'est vrai qu'avoir une BDD en local si c'est juste pour de la lecture, je vois pas trop l'intérêt. Il y a quelques années, j'ai travaillé en Delphi7 sur un projet dans lequel j'utilisais un fichier XML comme base de données; ça nécessitait une couche de mappage (via un fichier de transformation pour décrire la relation noeud xml <=> champ de table) qui me permettait d'attaquer directement mon fichier XML et de travailler dessus exactement comme si c'était une base. Je ne m'y suis jamais intéressé en c#, mais il doit exister un procédé équivalent. C'est à mon avis la meilleure solution; tu te "connectes" à ta "base XML", tu récupères une collection de données, puis tu te débranches du xml et tu te rebranches sur ton serveur pour tout remonter!

Si l'envie te prend de travailler, assied-toi et attend qu'elle te passe! (vieux -et faux!- dicton corse)

le truc est que j'ai besoin de ce mode autonome car s'il ya plantage du serveur ou probleme de connexion reseau , on ne peut pas dire ben on arrete d'enregistrer des ventes...

ben mon idée de départ etait d'utiliser le meme formulaire et les memes methodes pour enregistrer mes ventes...
comme ca j'ai pas a tout recoder , juste modifier la chaine de connexion à la BD
pourquoi copier les actions ds un xml ?
ne peut on pas changer la chaine de connexion d'un dataset ?
sinon je charge table par table "manuellement" et j'insere ensuite mes données de la ameme maniere par des requetes delete* from table et insert s'il n'existe pas d'autre moyen...
avec des transactions pour etre sur que tout est bien passé

Si c'est juste pour faire ça, il y a beaucoup plus simple:
Au démarrage de l'appli, tu charges tes produits dans une collection d'objets du style List<Produit>, avec un objet du style:


Puis, pour chaque vente, si tu as perdu ta connection, tu ajoutes ta ligne de vente dans un script SQL que tu pourras exécuter plus tard dans ta BDD.

Si l'envie te prend de travailler, assied-toi et attend qu'elle te passe! (vieux -et faux!- dicton corse)