Auteur Sujet: Rajouter un "pipeline"  (Lu 12813 fois)

plus minus reset

0 Membres et 1 Invité sur ce sujet

Hors ligne DDdeBerdeux

Rajouter un "pipeline"
« Réponse #19 de la page précédente: 21 Juillet 2005 à 16:28:19 »
Citation de: "Batard Olivier"
je suis toujours plus ou moins méfiant envers les liens ODBC qui restent à mes yeux un goulet d'étranglement au passage des données. Il va falloir que je me remette à Paradox, donc


C'est sûrement moins direct par ODBC, mais à-moins que ta base ancestrologie se mesure en Go ( ce que je ne te souhaite pas :wink: ), imperceptible.

Quand à Paradox, je regrette qu'il soit si peu ou mal maintenu depuis qu'il a été repris pas Corel. Depuis la SP2 de XP (çà fait bien un an), il y a un pb de visibilité des tables SQL ou ODBC, gênant lors de la conception (pas à l'utilisation) qu'une astuce permet de plus ou moins contourner, mais pour lequel je n'ai toujours pas trouvé de correctif.

A+

André
Une application pleinement satisfaisante est toujours complétée par une mise à jour buggée. (Loi des Mises à Jour)
 

Hors ligne AquaBlue

Rajouter un "pipeline"
« Réponse #20 le: 21 Juillet 2005 à 19:02:53 »
Pour la lecture des BLOB texte je parlais bien évidement de l'utilisation des pilotes à partir d'ACCESS. Que ça marche avec Paradox me parait logique puisque les produits sont tous les deux d'origine Borland.

Je vais tester tes pilotes sachant que mes essais datent un peu et que j'avais essayé les pilotes pour Interbase mais je crains que le résultat soit le même.



Je viens d'essayer les pilotes IBPhoenix et même punition les BLOB sont "linkés" comme OLE Object et on ne peut rien faire avec !
 

Hors ligne DDdeBerdeux

Rajouter un "pipeline"
« Réponse #21 le: 21 Juillet 2005 à 23:13:40 »
Citation de: "AquaBlue"
Pour la lecture des BLOB texte je parlais bien évidement de l'utilisation des pilotes à partir d'ACCESS. Que ça marche avec Paradox me parait logique puisque les produits sont tous les deux d'origine Borland.



Non non, l'essai dont je parlais précédemment a été fait depuis OpenOffice, en utilisant le pilote ODBC dont j'ai donné les références,  donc pas de Borland dans le coup. Il s'agit bien d'un pilote d'origine IBPhoenix version 1.02.00.69

Depuis Paradox j'utilise le pilote Interbase fourni avec la BDE complète (celle fourni avec les SQLlinks), qui n'utilise pas ODBC dans ce cas. Bien que l'accés soit également possible par la BDE et un pilote ODBC.

Je peux également confirmer que depuis access 2003 (Fichier/Données externes/Lier les tables/Type de fichier = ODBC Databases/Source de données ancestrologie installée), on peut accéder  aux tables de la base Firebird. Les champs Blob "image", apparaissent effectivement comme des "OLE Objects", mais les champs BLOB "texte" sont lus même s'ils font plusieurs lignes.

Juste un petit conseil pour ceux qui seraient tentés par l'expérience, le pilote ODBC permet de limiter l'accès en lecture seule. C'est préférable si on ne veut pas prendre de risque avec sa base. On ne sait jamais avec Access...

A+

André

PS, j'essaie d'insérer l'image écran, champ Comment de table individu:

Une application pleinement satisfaisante est toujours complétée par une mise à jour buggée. (Loi des Mises à Jour)
 

Hors ligne AquaBlue

Rajouter un "pipeline"
« Réponse #22 le: 21 Juillet 2005 à 23:38:55 »
Essaye donc d'ouvrir la table ADRESSES_IND et de lire les champs ADR_ADRESS ou ADR_TEL qui sont bien des BLOB texte !

Relit le message de Francis qui dit :

"Je souhaite modifier le rapport "Fiche individuelle" en rajoutant un sous rapport "domiciles successifs". "



Re-édition

Je viens d'aller voir dans la base et c'est toi qui a raison.

Aussi invraissemblable que ça puisse l'être les deux champs BLOB adresse et téléphone sont en type 2.

YAKA les passer en texte ce qui ne devrait pas beaucoup géner l'appli.  :!:
 

Hors ligne DDdeBerdeux

Rajouter un "pipeline"
« Réponse #23 le: 22 Juillet 2005 à 00:43:45 »
Tu as raison, les 2 champs dont tu parles sont reconnus comme des objets binaires, mais c'est parce qu'ils sont déclarés dans la base comme des objets binaires et non comme des textes.

Extrait du CREATE TABLE ADRESSES_IND

"ADR_ADRESSE"    BLOB SUB_TYPE BLR SEGMENT SIZE 1

alors que les notes de la table INDIVIDU

 "COMMENT"    BLOB SUB_TYPE TEXT SEGMENT SIZE 80 CHARACTER SET ISO8859_1

Et je serai curieux d'en connaître la raison, car à ma connaissance, dans ces champs il n'y a que de l'ascii. (si un développeur rôde dans le coin...)

Si un jour j'en ai la patience j'essaierai de modifier la base pour voir.

En attendant si celà ne règle pas le pb  de départ, çà peut aider pour d'autres.

A+

André

PS je viens de découvrir ta ré-édition. Ce qui me gêne dans le changement de type, c'est que c'est pas évident sur une base pleine si on ne veut pas perdre de données. Sauvegarder en gedcom ne permettant pas de transférer les multimédias, comment faire pour les récupérer?

Ensuite, il est possible que dans le logiciel il y ait un transtypage programmé. Comment réagira-t-il si on change le type? D'autant plus qu'il n'y a pas que ces 2 champs qui utilisent ce type BLR pour des notes en texte.

Mais il est vrai que çà me démange de " faire le ménage" dans la BDD. Un exemple? à quoi sert dans la table INDIVIDU le trigger AFTER UPDATE contenant: NEW.DATE_MODIF = 'NOW';?
Une application pleinement satisfaisante est toujours complétée par une mise à jour buggée. (Loi des Mises à Jour)
 

Hors ligne DDdeBerdeux

Rajouter un "pipeline"
« Réponse #24 le: 22 Juillet 2005 à 11:07:09 »
Ce matin je viens d'exécuter la requête suivante:



ALTER TABLE ADRESSES_IND

ADD "ADR_ADRESSET"    BLOB SUB_TYPE TEXT SEGMENT SIZE 80 CHARACTER SET ISO8859_1,

ADD "ADR_TELT"    BLOB SUB_TYPE TEXT SEGMENT SIZE 80 CHARACTER SET ISO8859_1,

ADD "ADR_MEMOT"    BLOB SUB_TYPE TEXT SEGMENT SIZE 80 CHARACTER SET ISO8859_1;



UPDATE ADRESSES_IND

SET ADR_ADRESSET = ADR_ADRESSE,

 ADR_TELT = ADR_TEL,

 ADR_MEMOT = ADR_MEMO;



ALTER TABLE ADRESSES_IND

DROP ADR_ADRESSE,

DROP ADR_TEL,

DROP ADR_MEMO;



ALTER TABLE ADRESSES_IND

ALTER COLUMN ADR_ADRESSET TO ADR_ADRESSE,

ALTER COLUMN ADR_ADRESSE POSITION 5,

ALTER COLUMN ADR_TELT TO ADR_TEL,

ALTER COLUMN ADR_TEL POSITION 11,

ALTER COLUMN ADR_MEMOT TO ADR_MEMO;



Attention, je ne l'ai pas faîte depuis le BOA qui ne semble pas accepter des requêtes successives (il suffirait peut-être de les faire tour à tour), mais depuis IBOconsole, après sauvegarde de ma base évidemment.

Ces requêtes permettent de changer le type des champ BLOB BLR en BLOB TEXT de la table ADRESSES_IND, sans perdre les données existantes.

Comme tu le soupçonnais Aquablue, çà ne semble faire ni chaud ni froid à Ancestrologie. Mais si quelques uns pouvaient valider...

Et si les développeurs pouvaient nous dire pourquoi ils ont choisis ce type...

La méthode a pour intérêt de rendre ces champs lisibles depuis d'autres logiciels et extractibles par requête (je viens de voir que seul le BOA arrive à rendre ces champs lisibles, et encore en remplaçant les sauts de ligne par des caractères étendus, pas le requêteur ni autres outils de requête).

A+

André
Une application pleinement satisfaisante est toujours complétée par une mise à jour buggée. (Loi des Mises à Jour)
 

Hors ligne AquaBlue

Rajouter un "pipeline"
« Réponse #25 le: 22 Juillet 2005 à 11:20:29 »
Ça va plus vite de le faire en direct à partir d'IBExpert (la version lite est libre et gratuite).



J'ai aussi fait la transformation et tout semble baigner  :!:



Il faudrait donc modifier :

Table ADRESSES_IND champs ADR_ADRESSE et ADR_TEL

Table MULTIMEDIA_RECORD champ CHANGE_NOTE

Table NOTE_RECORD champs NOTES, USER_REF et CHANGE_NOTE

Table SOURCES_RECORD champs AUTH, TITL, PUBL, TEXTE, USER_REF et CHANGE_NOTE

Table T_ASSOCIATIONS champs ASSOC_NOTES et ASSOC_SOURCES
 

Hors ligne DDdeBerdeux

Rajouter un "pipeline"
« Réponse #26 le: 22 Juillet 2005 à 14:34:36 »
Je pense qu'il te manque:

ADR_MEMO dans ADRESSES_IND

M_MEMO dans MEMO_INFOS

et USER_REF dans MULTIMEDIA_RECORD



Je ne sais pas comment fait IBExpert pour faire la modification de type en direct, parce que lorsque je veux le faire en direct depuis IBOconsole ou par la requête suivante quelque soit le requêteur:

ALTER TABLE MEMO_INFOS

ALTER COLUMN M_MEMO TYPE BLOB SUB_TYPE TEXT SEGMENT SIZE 80 CHARACTER SET ISO8859_1

j'obtiens toujours le message d'erreur "Changing datatype is not supported for BLOB or ARRAY columns", qui semble bien d'origine Firebird.

Si on veut que la manip soit faisable par tout le monde, il serait préférable qu'elle soit sous la forme d'une chaîne SQL à exécuter.

A+

André

PS: J'ai fait la modif à l'aide d'un script chaînant 24 requêtes à voir ici si certains veulent essayer. Mais attention, je ne l'ai essayé que depuis IBOConsole (avec Firebird 1.5 version serveur), et en cas de plantage pendant l'exécution, il faut repartir d'une copie de la base sauvegardée. Le fonctionnement d'Ancestrologie ne semble pas du tout perturbé. Et les champs de commentaires peuvent être exportés.
Une application pleinement satisfaisante est toujours complétée par une mise à jour buggée. (Loi des Mises à Jour)
 

Hors ligne feiv5354

  • AncestroJunior
  • ****
  • Messages: 176
    • http://perso.orange.fr/feiv
  • Système: WP
Adieu pipe-lines
« Réponse #27 le: 25 Juillet 2005 à 14:23:07 »
Grâce à vos indications (aqua et DD) et malgré mon inexpérience, ça à l'air de plutot bien se présenter pour l'utilisation d'Access.

Reste à me mettre sérieusement au boulot.

Comme le dit un éminent membre de ce forum, plus ça va, plus je me régale.
Ce chien de Robert ! C'est aujourd'hui que j'eusse aimé qu'il mourût !
 

Hors ligne Horemans

  • AncestroSenior
  • *****
  • Messages: 1 775
    • http://perso.wanadoo.fr/philippe.horemans
Adieu pipe-lines
« Réponse #28 le: 25 Juillet 2005 à 14:36:00 »
Citation de: "feiv5354"
éminent


C'est trop
Plus çà va, plus je me régale...  Et avec  Quisontils, la gestion des actes, c'est facile !   Philippe