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é