Renommer un champ 4D par programmation?

Bonjour,

Je ne vois pas dans le SQL ou les commandes 4D quelque chose qui permet de changer le nom d’un champ, seulement des commandes pour supprimer et recréer (ce qui me posera problème).

Ca existe ?

Equivalent en Mysql :

ALTER TABLE MaTable CHANGE Champ_Ancien_Nom Chap_Nouveau_nom varchar(16)
// à la fin la définition en mysql varchar(16) est un exemple

Merci d’avance,

Bonjour Michel,

je ne pense pas que cela soit possible en SQL car les définitions des tables et champs font parties des tables systèmes qui sont en lecture seule.

Patrick

j’en détails là mais je me demandais si je ratais une astuce…

Je trouve dommage que 4D nous autorise à le faire si simplement à la main et pas par programmation…

Merci à toi !

Ne cherche pas, ça n’existe pas en 4D.

J’aime vos messages clairs et concis…

plus que je n’aime cette réalité !

Merci de vos éclairages, rideau.

: Patrick EMANUEL

je ne pense pas que cela soit possible en SQL car les définitions des
tables et champs font parties des tables systèmes qui sont en lecture
seule.
De mémoire, le problème n’est pas là, c’est surtout qu’on ne sait pas selon quelle règle les numéros de tables/champs rendus “libres” par les suppressions seront ré attribués. Il me semble même avoir observé que ça pouvait changer d’une version à l’autre.

Pour illustrer (italique = champ supprimé) :

champ1
champ2
champ3
champ4
champ5

le SQL supprime champ4 :
champ1
champ2
champ3
champ4
champ5

puis le SQL créé un nouveau champ : rien ne permet de prédire si 4D va créer un nouveau champ ou utiliser un des champs supprimés (3, 4 ou 5), en dehors de l’observation de tests dont on n’est même pas sûr qu’ils soient valables, puisque non documenté (= pas prévu/supporté/permis). Ce qui peut être assez ennuyeux quand on lira les données du champs, qui, entre temps, n’auront pas bougé d’un poil dans le data.

moi je parlais juste de pouvoir faire par programmation ce qu’on fait à la main sans problème ni conséquence.
on va dans l’explorateur en structure sur le champ MonChamp et on le renomme en MonChamp_Suffixe.

Je pensais qu’on avait la commande permettant de le faire car ça n’aurait pas de conséquence sur un champ existant (avec la même vérification d’unicité que 4D fait quand on change manuellement), je ne vois pas la raison de ne pas le permettre mais je me doute qu’il y en a une…

: Arnaud DE MONTARD

puis le SQL créé un nouveau champ : rien ne permet de prédire si 4D
va créer un nouveau champ ou utiliser un des champs supprimés (3, 4
ou 5), en dehors de l’observation de tests dont on n’est même pas sûr
qu’ils soient valables, puisque non documenté (= pas
prévu/supporté/permis). Ce qui peut être assez ennuyeux quand on lira
les données du champs, qui, entre temps, n’auront pas bougé d’un poil
dans le data.

Je suis on ne peut plus d’accord avec toi.
Aujourd’hui, on ne peut pas être sur de quoi que ce soit et je suis quasiment sur que c’est pur cette raison que nous avons des commandes telles que :
is field number valid
is table number valid

La seule chose dont je suis sur sur les numéros de table et de champs, c’est que l’on est sur de rien.

Patrick

: Michel TROYA

moi je parlais juste de pouvoir faire par programmation ce qu’on fait
à la main sans problème ni conséquence.
on va dans l’explorateur en structure sur le champ MonChamp et on le
renomme en MonChamp_Suffixe.
Madame Orda peut te châtier d’importance pour avoir osé proférer cela dans le coin de la v17
:scream::rofl:

: Patrick EMANUEL

La seule chose dont je suis sur sur les numéros de table et de
champs, c’est que l’on est sur de rien.
Ouah, t’exagères, avec la structure en usage classique et documenté (*), si, on sait.

(*) illustration de l’usage dit classique et documenté

: Arnaud DE MONTARD

Ouah, t’exagères, avec la structure en usage classique et documenté
(*), si, on sait.
Ca m’arrive aussi un peu, je l’avoue :wink: