Interface entre deux BDD

Bonjour à tous,

Je vous expose mon problème. J'ai 2 BDD (une sous Access et l'autre sous MySQL). Dans ces tables je gère des mouvements de stocks et je souhaite créer une interface entre ces deux BDD. Pour cela j'utilise un programme en C, cependant je suis confronté à un petit problème. Voici mes deux BDD :

Access :
- Mouvement(N°, Etat, Rapprochement, Ref_Produit, Quantite, Type_Mouvement)
Rapprochement vaut 'N' si le tuple n'a pas encore été enregistré dans l'autre base de données, il vaut 'R' sinon.
- Interface(id_mvt)
id_mvt est l'id du dernier mouvement rapproché qui a été enregistré sur la BDD MySQL.

MySQL :
- Mouvement(id_mvt, Type_mvt, Ref_Produit)
L'id_mvt est auto incrémenté.

J'avais prévu que le script fonctionne de cette façon :
1/ On récupère les mouvements côté MySQL dont l'id est supérieur au plus grand id_mvt de la table Interface.
2/ On récupère les mouvements côté Access (Etat = 'Livré' et Rapprochement = 'N') qu'on enregistre dans la table Mouvement côté MySQL.
3/ On récupère l'id_mvt maximum de la table Mouvement côté MySQL pour l'enregistrer dans la table Interface.

C'est entre l'étape 1 et 2 que mon problème se pose. En effet, si un mouvement de stock est ajouté entre ma requête de récupération (1) et ma requête d'insertion (2), alors le tuple de ce mouvement ne sera jamais traité. La probabilité est assez faible mais existante, et comme le script sera exécuté très régulièrement, cela multiplie les risques que certains mouvements ne soient pas pris en compte.

De plus j'ai une contrainte : je ne peux pas modifier ou ajouter de table du côté MySQL. Sinon il m'aurait suffit de rajouter un champ Rapprochement du côté MySQL pour savoir si le tuple avait déjà été traité ou non.

Connaissez-vous une solution ou un moyen de contourner problème ?
Merci par avance ! :D

J'ai peut-être une idée, mais ça va alourdir l'ensemble :
- stocker la dernière donnée récupérée par (1) dans une table access avec un timestamp - mais les timestamp access ne sont pas super fiables sous la seconde
- stocker la dernière donnée récupérée par (2) dans une autre table access avec un timestamp, ie relancer la requête (1) après la (2)
- tester si ces 2 valeurs sont égales, et rattraper les mouvements perdus

C'est pas simple, comme problème.
D'autre part, je ne pense pas qu'ajouter un champ 'Rapprochement' dans la table mysql serait possible, car autant un access peut lire dans un mysql, je ne vois pas comment le contraire est possible.

Bon courage

Bonjour guidav,

Je ne lis pas directement d'une BDD dans l'autre, je me connecte grâce à une libraire ODBC aux deux BDD dans mon script en C.

Du coup, un champ Rapprochement me permettrait de spécifier les champs que le script a récupéré. Ainsi toutes mes requêtes de récupération auraient une clause WHERE Rapprochement = 'N'. Il s'agit d'un script exécuté toutes les 15 minutes, donc même si un mouvement de stock est effectué pendant l'exécution du script, il serait récupéré 15 minutes plus tard.

J'ai tenté d'imaginer plusieurs solutions, comme récupérer dans un premier temps les données d'Access, les écrire dans la BDD MySQL et récupérer le MAX(id_mvt) de MySQL, mais le problème est le même si un mouvement de stock est ajouté juste avant de faire la requête de récupération du MAX(id_mvt).

En tous cas merci pour ta proposition, mais j'ai peur que le problème revienne au même si un mouvement de stock est ajouté juste avant l'écriture des mouvements de stocks dans la BDD MySQL, quel que soit le nombre de vérification que l'on fasse.

N'y-a-t'il pas des systèmes de files d'attente de requêtes qui permette de bloquer momentanément l'exécution de requêtes sur des BDD pendant l'exécution d'un script?

Tu peux utiliser la notion de LOCK.

Tu lock la table qui ne doit pas être modifiée le temps de ton opération et tu enlève le lock ensuite.

Je ne connais pas bien ACCESS donc je ne sais pas en pratique comment le faire dans ton cas, mais ça doit exister.

Je vais essayer de me tourner vers le lock, et la BDD Access n'est pas un problème, c'est au niveau de la table MySQL que mon problème se présentait. En effet le LOCK semble pouvoir être une bonne alternative.

J'ai juste 2 petites questions au sujet du LOCK.

Si une requête est effectuée pendant qu'une table est verrouillée, est-ce que cette requête s'effectue lorsque la table est déverrouillée ?

Si je LOCK une table dans mon script, est-ce que je peux quand même écrire dedans depuis mon script tout en bloquant les requêtes "externes"?

Merci beaucoup pour cette piste :D

Citation:

---

Envoyé par Yami no tenshi

Si une requête est effectuée pendant qu'une table est verrouillée, est-ce que cette requête s'effectue lorsque la table est déverrouillée ?

---

Oui la requete est mise en attente.

Citation:

---

Envoyé par Yami no tenshi

Si je LOCK une table dans mon script, est-ce que je peux quand même écrire dedans depuis mon script tout en bloquant les requêtes "externes"?

---

Il y a différents types de LOCK. Mais je ne suis pas un expert dans le domaine. Donc je prefere ne pas répondre que te dire une bétise sur ce point.

Je n'ai plus qu'à faire des tests pour vérifier ma deuxième question, merci beaucoup pour tes réponses qui me sont très utiles !

Bien vu le coup du lock. Sinon, définir une fonction utilisateur et faire passer le tout dans une transaction ? A condition de pouvoir mettre la fonction en C sur le serveur sql, mais je ne sais pas si c'est possible et si tu y as un accès suffisant (probablement pas, si tu ne peux pas créer de table).
Je pense que le lock est la meilleure solution, en effet.

Le seul moyen efficace est de faire une requête interserveur avec un COMMIT à deux phases. Problème MySQL ne sait pas faire !
Ce n'est pas la seule limite de MySQL... A lire :
Avec votre lock, vous allez pourrir dramatiquement les performances de vos deux SGBDR et comme ACESS est lent et MySQL aussi, vous aurez au final une application inexploitable !

A +

Bonjour SQLPro.
Merci pour ce coneil. Cependant, mon script ne sera exécuté que toutes les 15 minutes, est-ce que cela va influer aussi fortement que vous ne le dites sur les performances des SGBDR?

Merci :)

Tout dépend du nombre d'utilisateurs.... Mais pour ce genre de choses il serait souhaitable de travailler de manière asynchrone.
Par exemple renseigner quelque chose dans la base via un trigger de manière synchrone et avoir une tache planifié qui va faire la migration régulièrement.

A +

Est ce que tu peux nous dire pour quelle raison tu veux faire ce bricole ?

J'ai l'impression qu'il doit synchroniser 2 bases, sachant qu'il est possible d'écrire dans les 2 en même temps.
Autant dire que c'est rarement simple à mettre en œuvre.

Oui voilà, j'ai des tables à synchroniser (dans 2 BDD différentes, Access et MySQL) pour toujours avoir les mêmes stocks des deux côtés et il m'est impossible de modifier la structure d'une des deux bases de données (MySQL).

J'ai réussi à mettre en place ce système en programmant un petit script qui a recoure au LOCK. Ce script s'exécute en à peine 1 seconde toutes les 15 minutes.

Donc je ne sais pas si cela modifie énormément les performances de mes BDD, d'autant plus que le nombre d'utilisateur devrait être relativement raisonnable.

Est ce que tes lock sont posés les commandes LOCK ou gérés via les transactions ?

Via la commande LOCK

Si ta version de MySQL supporte les transactions, je te conseillerais d'utiliser les transactions avec un bon niveau d'isolation.