Copie de certaines tables ds une base de données

cudenetf Messages postés 448 Date d'inscription mardi 20 septembre 2005 Statut Membre Dernière intervention 26 juillet 2012 - 17 déc. 2009 à 10:51
Vacca Messages postés 1 Date d'inscription mercredi 3 mars 2010 Statut Membre Dernière intervention 3 mars 2010 - 3 mars 2010 à 09:09
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

19 réponses

JeremyLecouvert Messages postés 139 Date d'inscription mardi 27 novembre 2007 Statut Membre Dernière intervention 10 mai 2010 2
17 déc. 2009 à 14:30
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),
0
JeremyLecouvert Messages postés 139 Date d'inscription mardi 27 novembre 2007 Statut Membre Dernière intervention 10 mai 2010 2
17 déc. 2009 à 14:30
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
0
JeremyLecouvert Messages postés 139 Date d'inscription mardi 27 novembre 2007 Statut Membre Dernière intervention 10 mai 2010 2
17 déc. 2009 à 14:30
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),
0
JeremyLecouvert Messages postés 139 Date d'inscription mardi 27 novembre 2007 Statut Membre Dernière intervention 10 mai 2010 2
17 déc. 2009 à 14:35
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:
<operation>
  <heure>17/12/2009 14:10:00</heure>
  <type>Requete</type>
  <contenu>update Utilisateur set prenom = 'Machin' where Id=0001</contenu>
</operation>


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)
0

Vous n’avez pas trouvé la réponse que vous recherchez ?

Posez votre question
cudenetf Messages postés 448 Date d'inscription mardi 20 septembre 2005 Statut Membre Dernière intervention 26 juillet 2012 2
17 déc. 2009 à 14:54
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 ?
0
cudenetf Messages postés 448 Date d'inscription mardi 20 septembre 2005 Statut Membre Dernière intervention 26 juillet 2012 2
17 déc. 2009 à 16:01
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 ???
0
JeremyLecouvert Messages postés 139 Date d'inscription mardi 27 novembre 2007 Statut Membre Dernière intervention 10 mai 2010 2
17 déc. 2009 à 17:07
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)
0
cudenetf Messages postés 448 Date d'inscription mardi 20 septembre 2005 Statut Membre Dernière intervention 26 juillet 2012 2
17 déc. 2009 à 17:18
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é
0
JeremyLecouvert Messages postés 139 Date d'inscription mardi 27 novembre 2007 Statut Membre Dernière intervention 10 mai 2010 2
17 déc. 2009 à 17:20
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


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, avec un objet du style:
Class Produit
{
  public int Id;
  public string Nom;
  public double Prix;
  
  public Produit(int anId, string aName, double aPrice)
  {
    Id = anId;
    Nom = aName;
    Prix = aPrice;
  }
}


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)
0
cudenetf Messages postés 448 Date d'inscription mardi 20 septembre 2005 Statut Membre Dernière intervention 26 juillet 2012 2
17 déc. 2009 à 17:23
et si quand je demarre mon poste de caisse le serveur est eteint...
il me faut bienpouvoi r recuperer les données enregistrés sur du "dur"...
0
JeremyLecouvert Messages postés 139 Date d'inscription mardi 27 novembre 2007 Statut Membre Dernière intervention 10 mai 2010 2
17 déc. 2009 à 17:36
Je suppose que ta liste de produits ne change pas tous les jours... Donc tu peux la sauvegarder sur disque en local, sous forme de fichier texte ou autre.
connection OK -> je charge mes produits depuis la base, et j'en profite pour les sauvegarder en local;
connection KO -> je charge mes produits depuis mon fichier local, et je stocke mes lignes de vente dans un script pour les remonter plus tard.

Si l'envie te prend de travailler, assied-toi et attend qu'elle te passe! (vieux -et faux!- dicton corse)
0
cudenetf Messages postés 448 Date d'inscription mardi 20 septembre 2005 Statut Membre Dernière intervention 26 juillet 2012 2
17 déc. 2009 à 17:48
Ben ya quand meme une vingtaine de tables...
en gros faudrait que je refasse un programme qui lise des fichiers... au lieu des bases de données???
0
JeremyLecouvert Messages postés 139 Date d'inscription mardi 27 novembre 2007 Statut Membre Dernière intervention 10 mai 2010 2
18 déc. 2009 à 09:54
Non, de 2 choses l'une:
- Soit tu as une floppée de tables sur lesquelles tu dois travailler, avec des accès concurrentiels, des update ou delete, des procédures stockées ou autres, bref un système assez complexe, et là si tu veux pouvoir travailler en mode déconnecté il faut gérer tout ça et les problèmes que ça peut causer => solution complexe (puisque le système l'est!);
- Soit comme tu le dis tu n'as besoin en mode autonome que de quelques tables (genre une table Produits et voilou) et ne faire que des insert et là, tu choisis une solution simple avec une liste de produits sauvegardée simplement sur disque et un script SQL pour stocker tes requêtes insert en attendant de pouvoir les exécuter dans la base!

C'est tout!

Si l'envie te prend de travailler, assied-toi et attend qu'elle te passe! (vieux -et faux!- dicton corse)
0
cudenetf Messages postés 448 Date d'inscription mardi 20 septembre 2005 Statut Membre Dernière intervention 26 juillet 2012 2
18 déc. 2009 à 10:01
ben ya pas mal de tables mais utilisées seulement en lecture...
0
JeremyLecouvert Messages postés 139 Date d'inscription mardi 27 novembre 2007 Statut Membre Dernière intervention 10 mai 2010 2
18 déc. 2009 à 10:30
Peux-tu préciser un peu? C'est combien "pas mal"? Combien de tables sont indispensables pour tourner en autonome? Sur combien de tables fais-tu des insertions?


Si l'envie te prend de travailler, assied-toi et attend qu'elle te passe! (vieux -et faux!- dicton corse)
0
cudenetf Messages postés 448 Date d'inscription mardi 20 septembre 2005 Statut Membre Dernière intervention 26 juillet 2012 2
18 déc. 2009 à 10:33
20 tables en lecture 2 pour les insertions...
0
JeremyLecouvert Messages postés 139 Date d'inscription mardi 27 novembre 2007 Statut Membre Dernière intervention 10 mai 2010 2
18 déc. 2009 à 10:54
Dans ce cas, effectivement, il vaut mieux avoir ne BDD de secours en local...mais bon ça va un peu à l'encontre du principe du client/serveur!!

Il ne faut pas perdre de vue une chose: c'est un procédé qui ne sera utilisé qu'exceptionnellement, en cas de pb avec le serveur. Donc il faudrait pas que le développement de la solution de secours soit plus long et plus chiadé que le mode de fonctionnement normal! (là on en prend le chemin).

Si tu tiens vraiment à faire ça, tu peux aussi considérer le problème dans l'autre sens: tu développe ton appli pour qu'elle tourne en monoposte (avec BDD locale et tout et tout). En parallèle, tu prévois un système de mise à jour journalier qui prendra les données de ta (tes) client(s) et les remontera vers le serveur (et vice-versa!).
La journée, les opérateurs travaillent en local, et le soir à une certaine heure, tu déclenches (en automatique) ton système de backup qui va remonter les données des clients au serveur, puis redescendre la base ainsi complétée vers chaque client pour qu'ils sient à jour le lendemain matin!

C'est juste une idée de plus, à toi de faire le tri après!

Si l'envie te prend de travailler, assied-toi et attend qu'elle te passe! (vieux -et faux!- dicton corse)
0
JeremyLecouvert Messages postés 139 Date d'inscription mardi 27 novembre 2007 Statut Membre Dernière intervention 10 mai 2010 2
18 déc. 2009 à 11:23
Sinon, pour répondre une de tes questions que j'avais laissé de côté:
ne peut on pas changer la chaine de connexion d'un dataset ?

..Ce serait dommage qu'on ne puisse pas!!

Sur la méthode, je ne peux pas vraiment t'aider (du moins pas en c#!). Mais vu de loin, je pense qu'il faut éviter le DataBinding dans ce cas, parce que cela implique que tes composants sont liés directement à leur source de données, donc si tu coupes la connection, tu perds tout. Par contre, rien ne t'empêche d'envoyer une requête select, de stocker son résultat dans un datatable, un datarow[] ou n'importe quelle autre collection de ton choix. Tu auras une collection de données autonome que tu pourras exploiter à ton gré et "brancher" sur une autre base pour envoyer des mises à jour.

Si l'envie te prend de travailler, assied-toi et attend qu'elle te passe! (vieux -et faux!- dicton corse)
0
Vacca Messages postés 1 Date d'inscription mercredi 3 mars 2010 Statut Membre Dernière intervention 3 mars 2010
3 mars 2010 à 09:09
Je sais que ce topic date de plusieurs mois, mais j'espère que quelqu'un pourra m'aider dans la réalisation de mon appli.

Je dois réaliser une appli qui tourne en monoposte comme l'a décrit JeremyLecouvert dans un précédent message, je vous pose le tableau :

Dans l'entreprise, chaque technicien/commercial itinérant possède son propre pc portable et grâce à un autre programme développé par mon binôme (c'est un projet de fin d'études pour un BTS IRIS), il peut faire des mesures sur les produits qu'il doit acheter pour sa boîte.

Dans mon appli, tous les relevés et les achats que cette personne à faite dans la journée sont sauvegardées sur une Base de Données locale.
Lorsque cette personne rentre au siège, il faut que la Base de Données de l'entreprise importe les tables présentes en local sur les pc des techniciens et en récupère les données pour qu'elle puisse se mettre à jour, et comme je suis un vrai novice en matière de BdD, je ne sais pas comment faire ce transfert de table local -> réseau...
Il faut savoir que les tables locales ont la même structure que celles présentes sur la BdD réseau donc tout ce que je dois faire, c'est de faire des INSERT INTO[rest_de_la_requete], mais je ne sais pas comment créer l'interaction local -> réseau, donc si quelqu'un pouvait m'en expliquer le fonctionnement, je lui en serai éternellement reconnaissant.
0
Rejoignez-nous