Discussion :

[Quintoux]

Suite à ce sujet :

http://www.developpez.net/forums/d88...v-replication/

Bonjour, je reviens lancer cette discussion car j'ai une question similaire au problème lancé au départ.

Utilisant Windev 15, nous avons une application qui fait de la synchronisation entre des bases Hyperfile (1 maitre et plusieurs esclaves).

L'objectif est de passer sous POSTGRESQL (non negociable, cela a été validé avant mon arrivée dans ce boulot) et donc je me pose les questions pour savoir comment gérer la réplication des données sous postgresql (en accès natif en 64 bits ou 32 bits au cas où).

Je suis assez perdu car je suis nouveau sur le projet et la synchronisation des données est ma mission principale dans ce premiers temps.

Je vais également rencontrer un autre probleme car au delà de cette application qui permet de synchroniser une base maitre avec N esclaves, ... une autre application devra utiliser notre composant de réplication des données pour mettre à jour 2 sites qui seront maitres tous les 2 (car un serveur en France et un autre à l’étranger et les 2 doivent être à jour le lendemain des données de la veille de l'autre site) ... nous aurons des regels en place pour éviter l’écrasement des données.

Est-ce que quelqu'un peut m'aider sur le probleme de réplication des données par Windev sous POSTGRESQL.

Merci d'avance

[Nhaps]

Bonjour,

Si j'ai bien comprit tu souhaites abandonner ta base HF et passer en PostGreSQL ? Mais tu veux bien entendu conserver les donnees, en les important de ta base HF vers PG.

Est ce bien cela ?

Nhaps

[Quintoux]

oui c'est çà, on va passer nos applications sous postgresql.

et je me pose enormement de questions sur la réplication des données via WINDEV et postgresql

Si quelqu'un pouvait m'aiguiller ou m'aider, ca serait TRES sympa

N'hésitez pas à me poser toutes les questions pour savoir ce dont j'ai besoin exactement

[Nhaps]

Bonjour,

Déjà il faut que la structure de tes tables soit identique à celle de HF.

Pour cela plusieurs solution :

Soit sous PG tu peux importer les données HF, et PG crée automatiquement les tables( sans relations, sans sequences, sans index ) mais au moins tu as des tables avec des données avec un bon typage. A toi ensuite de remettre en relation les tables.

Soit tu fait à la main tes tables. Avec les erreurs de typage qui peuvent se produire, il te faudra faire des tests.

La première solution est la meilleur des deux et la plus rapide, est elle possible ? Je sais que pour Oracle vers SQL Server. J'ai fait comme cela.

Une fois ta base faite, il n'y aura pas forcement de problème dans ton programme windev. Plusieurs points à faire attention :

- Tes requetes ( nom de table, fonction propre à HF à retranscrire en PG )
- Tes liaisons sur tes fenetres ( Hajoute() etc ... )
- Ta connexion ( bien sur )
- Et les noms de table dans ton code aussi

Peut etre que mon post sur ce sujet pourra t’intéresser.

Nhaps

[Quintoux]

Merci pour ta réponse ...

En fait, pour le passage de Hyperfile POSTGRESQL, je ne me pose pas trop de questions, un outil a été fait en interne pour faire l'insertion des données de table à table .

Mon probleme est pour ensuite re-developper le composant WINDEV de synchronisation qui permet de répliquer les données d'une base nomade à la base centrale (et inversement) sur une application en 32 bits (et même en 64 bits et c'est là que pose le probleme car apparemment, il n'y a pas sous windev l’accès natif à POSTGRESQL compatible avec du 64 bits).

Aujourd'hui, notre composant existant qui permet de répliquer les données fonctionne assez bien .... mais comme l'application est en 64 bits, cela fonctionne par Hyperfile SQL ... mais lorsqu'on va passer sous POSTGRESQL, ce composant ne fonctionnera plus.

Je suis assez perdu ... pour la réalisation à moins que quelqu'un me dise qu'il gère la réplication de données sous POSTGRESQL et que cela fonctionne en appli. 64 bits (pour l’accès natif).

Merci de votre éventuelle aide

[Atsibat]

Ha !!! c'est exactement ça que je cherche...
Alors pour l'instant courage, je creuse aussi et si je trouve quelque chose d'intéressant je reviens ici en courant...

[Invité]

Bonjour,

Je n'ai peut-être pas compris la question.

Vous voulez transférer une base HyperFile (elle-même répliquée)... en une base PostgreSQL (qui devra être répliquée) ?

Si tel est le cas, pour la réplication synchrone ou non d'une base PostgreSQL sur un autre serveur PostgreSQL, il existe des solutions "internes" à l'environnement PostGreSQL [en tous cas pour les versions 9]. Il faudrait dans ce cas-là contacter le Forum PostgreSQL de developpez.net qui m'a très efficacement aidé lors du passage de nos serveurs mySQL en PostgreSQL (9.1 sur Squeeze amd64).

Cordialement. Gilles

[Quintoux]

Oui c est ça
La base va être sur postgresql v 8.3 (je crois, la version n est pas sûre)
Je cherche un moyen de répliquer les infos qui seront faites sur les postes nomades vers un poste central et inversement pour que la base centrale soit le plus souvent en phase avec les postes nomades quand ils synchroniseront

N ayant pas trouve d'outil sur postgresql car je ne connais pas bien cette base et ces outils.... Nous avons opté pour un système d info stocke dans 1 table remplie par trigger à chaque modif, insert et delete ... On stockerait l ordre s'il a répercute sur les bases nomades et sur le central quand cela viendrait du nomade

Ensuite tous les soirs une tâche nocturne enverrait à chaque nomade un fichier contenant ces mises a jour à répliquer pour tous
Bien sur la base aurait d abord intégré les mises à jour des nomades qui auront envoyé leur synchro

Je détaillerai un peu plus ma méthode prévue demain ou mardi mais si un outil tout près existe via postgresql ou via un composant windev existant.... Merci de me donner des infos

À +

[Atsibat]

Bonjour,

quand je lance l'application Stack Builder fournie avec PostgreSQL elle me propose une solution de réplication qui s'appelle Slony-I for PostgreSQL
(je suis en version 9.1 pour Postgre)
A voir peut être de ce côté là.

[Quintoux]

En fait, mùon objectif est d'avoir une tache planifiée tous les soirs sur le serveur central qui recupere les fichiers des abonnés puis les integre à la base centrale et enfin, il y a pour chaque abonné un export des données qu'il ne connait pas.

AInsi, le lendemain, quand les nomades se connectent et synchronisent, leur base se met à jour en intégrant les infos envoyées par le central la nuit.

Donc il me faut pouvoir tout faire à l'aide d'un composant de windev (ou postgresql) mais je patauge beaucoup.

[Invité]

Bonjour,

j'ai relu avec attention cette discussion qui m'intéresse beaucoup (car je recherche le maximum d'informations sur Windev avant de décider ou non de sa réutilisation) et j'ai lu votre demande sur le site de PostgreSQL.

Mon probleme est pour ensuite re-developper le composant WINDEV de synchronisation qui permet de répliquer les données d'une base nomade à la base centrale (et inversement) sur une application en 32 bits (et même en 64 bits et c'est là que pose le probleme car apparemment, il n'y a pas sous windev l’accès natif à POSTGRESQL compatible avec du 64 bits).

C'est l'accès natif lui-même qui ne fonctionne pas en 64 bits ? J'ai relu avec attention la documentation de PC-SOFT, je n'ai pas réussi à trouver cette information. Dommage, si tel est le cas, elle devrait figurer !
Parce que du côté de PostgreSQL, le 32 et le 64 bits sont gérés aussi bien en Linux qu'en Windows donc on dispose des bibliothèques nécessaires.

Aujourd'hui, notre composant existant qui permet de répliquer les données fonctionne assez bien .... mais comme l'application est en 64 bits, cela fonctionne par Hyperfile SQL ... mais lorsqu'on va passer sous POSTGRESQL, ce composant ne fonctionnera plus.

Qu'est-ce qui empêcherait de porter votre composant 64 en 32 bits ? Si j'ai bien compris, comme vous êtes sous Windows, un programme Windev "compilé" en 32 bits devrait fonctionner en 64... (à moins, qu'il fasse explicitement appel aux API et autres bibliothèques externes spécifiquement 64 bits). Donc, lors de la création de l'exécutable, une "recompilation" 64->32 bits (ou l'inverse) avec Windev est instantanée et sans grande complication et même, si j'ai bien lu, sans modification. Et évidemment un poste Client PostgreSQL Win 32 bits accède avec ses bibliothèques PostgreSQL 32 aux bases d'un serveur PostgreSQL Linux amd64.

Hélas, je ne vais pas pouvoir tester l'accès à PostgreSQL en accès natif 64 bits. Je ne dispose plus de la version Windev 16 complète mise à ma disposition le WE dernier mais uniquement de la 17 Express. Et les versions Express ne gèrent pas les connecteurs natifs. Quelqu'un a-t-il testé ?

L'objectif est de passer sous POSTGRESQL (non negociable, cela a été validé avant mon arrivée dans ce boulot)

Cela me parait un peu curieux comme démarche en cette période d'économies :

1. Vous disposez d'un composant HyperFile opérationnel et sans tenir compte des limites imposées (que vous énumérez ci-dessus) par votre plateforme de développement, il a été décidé de changer de SGDBR
2. Je suppose que le serveur PostgreSQL n'est pas (hébergé) mutualisé
   
   • C'est rare
   • Vous n'auriez probablement pas accès à la réplication dans cette configuration
   
   Ce qui signifie que vous avez probablement accès au serveur et que donc il vous est possible d'installer un serveur HyperFile gratuit "sur" le serveur PostgreSQL

En ce qui concerne la discussion sur le forum de PostgreSQL, il ne faut pas oublier que PostgreSQL est Client Serveur. Ce n'est pas un HyperFile Classic (HF7). Sur chacun de vos appareils nomades, il va falloir installer un serveur PostgreSQL. Cela peut s'installer silencieusement et quasiment automatiquement sous Win 32 mais je pense que la démarche est exactement la même pour un 64 bits.

Donc à partir de ce moment, vous pouvez disposer d'une base hébergée distante et de bases nomades autonomes. Il vous faut donc une "synchro" dans les 2 sens. Les bases nomades chargent ponctuellement la base centrale et la base centrale réactualise à cette occasion les bases nomades. Le seul problème est qu'il ne faut pas que la base centrale réactualise une base nomade X pendant qu'une base nomade Y actualise la base centrale. Si tel est le cas, on crée un file d'attente. De toute façon, compte tenu de la méthode retenue, il est illusoire de prétendre synchroniser "tout en même temp". Il y aura "parfois" de petits décalages. Par contre, il faut évidemment veiller à l'intégrité de la totalité de la masse des données centralisées et déportées.

J'ai essayé avec Windev 16 et les connecteurs natifs PostgreSQL 9.1.5 (32): on peut threader l'opération. Comme vous faites déjà les synchros en Windev avec HyperFile, je suppose que les méthodes que vous employez sont réplicables (si je peux dire) en PostgreSQL... et si vous utilisez le SQLConnecte, hormis la remarque qui suit, le code doit être pratiquement ré-employable.

Remarque -> en PostgreSQL, on n'utilise pas les majuscules : ni sur le nom des tables, ni sur le nom des champs... Sinon, il faut 'quoter' ces derniers dans les requêtes... En HF, par défaut les majuscules sont au moins placées au début des noms.

Cordialement. Gilles

[Quintoux]

Merci pour ta réponse, je vais re-préciser 2 ou 3 points pour être plus précis sans le cheminement de mes actions :

1) J'arrive sur un nouveau poste (depuis 1 mois et demi)
2) L'objectif de passer d'hyperfile vers postgresql est surtout pour un gain de temps car le système hyperfile est beaucoup moins rapide que postgresql dans les temps d’exécution et le volume de lignes dans les tables devient trop conséquent pour hyperfile donc on a des temps de réponse beaucoup trop lent pour continuer ainsi.
3) Le système de réplication universelle proposé par windev pour postgresql ne peut pas nous satisfaire en version exécutable 64 bits car l’accès natif de windev pour postgresql n'existe pas apparemment en 64 bits.
(PS : On est passé en 64 bits car en 32 bits, pour un client, il y avait un CRASH qui intervenait de par le volume d'information et donc on ne pouvait plus utiliser la synchro en 32 bits chez lui ... apparemment, le problème ne s'est plu présenté depuis le passage en 64 bits.
PS : pour cette info., je la tiens de mon collègue donc si c'est une erreur et si le système existe bien en 64 bits, n'hésitez pas à me le signaler.

PS : Pour info, avec WINDEV 15, il a été obligé de créer des segments pour la réplication des infos des tables car windev gère une longueur de tables (noms des tables MAXIMUM de 1024 caractères) ... ainsi, en voulant répliquer l'ensemble de la base, il n'y avait que les tables comprises dans les 1024 premiers caractères qui étaient prises (assez étonnant mais c’est un GROS BUG de WINDEV 15 apparemment)

N'hésitez pas à communiquer sur n'importe quel système de réplication des données ou sur certains points que j'ai donné et qui serait erroné.

Merci d'avance

[Invité]

Bonsoir,

Je pourrai réutiliser le Windev16 complet dans la semaine.

A partir du poste de développement 32 bits que j'ai utilisé le WE dernier, je créerai un exécutable 64 bits de mon test de la semaine dernière d'accès natif sur notre serveur hébergé PostgreSQL... en y joignant les bibliothèques client PostgreSQL 9.1 Win 64 bits que j'utilise habituellement avec "mon" Lazarus.

Si cela ne fonctionne pas, j'essaierai d'installer le Windev 16 sur un poste 64 bits pour créer un exécutable 64 bits. J'ai appris à me méfier de la cross-compilation... Et en Windev, je n'ai pas d'estimation ni d'expérience sur ce que vous appelez la "création d'exécutable".

Je ne pourrai pas vous communiquer directement les résultats des tests par l'intermédiaire de cette discussion.
J'ai demandé la désactivation de mon compte Developpez.net suite à la suppression dans mes messages de liens vers d'autres forums, suppressions que j'estime trop fréquentes et dommageables pour les contenus de mes messages, notamment dans cette discussion [un lien déréférencé vers un forum où je faisais un CR de l'installation silencieuse de PostgreSQL 9.1 sur des postes clients Windows]. La raison invoquée serait un moins bon référencement du site Developpez.net à cause de la présence de ces liens. Je ne discute pas. Je n'ai pas les éléments me permettant d'évaluer cette assertion mais j'en tire les conséquences.

Cependant, j'espère pouvoir vous les transmettre par l'intermédiaire d'un des responsables d'une des "sections" de ce site.

Bon courage... et si vous le pouvez, persistez avec PostgreSQL : je ne le connais pas depuis très longtemps mais c'est vraiment ce que j'ai rencontré de mieux depuis que je travaille avec des SGDBR. Quant à sa communauté, elle est digne de celle des "Pascaliens"... ce qui n'est pas peu dire !

Cordialement. Gilles

[Quintoux]

Merci pour ta réponse.

je voulais savoir si tu avais pu tester l'acces natif de WINDEV vers POSTGRESQL en version 64 bits .... si quelqu'un sait que c'est COMPATIBLE ou INCOMPATIBLE, merci de me le signaler.

[Invité]

Bonjour,

C'est vraisemblablement impossible avec ta version W15.
Extrait d'un post du forum pcsoft.fr

Il s'agit d'une impossibilité d'utiliser l'accès natif MySQL de PCSoft sur des serveurs en WEBDEV 16 64 bits, nous avons eu cette information que très récemment, et PCSoft n'a pas prévu à ce jour de sortir une version pour le mode 64 bits.
http://forum.pcsoft.fr/thread.awp?groupid=pcsoft.fr.webdev&v=2&postid=237605

Par extrapolation (puisque le post concerne MYSQL et WEBDEV 16), compte tenu des problèmes rencontrés, on peut raisonnablement émettre un doute.

Maintenant sur la version 18, c'est peut-être opérationnel. Tu devrais contacter directement PCSoft.
A+