Convertir un champs alpha vers un champ réel

Hi,

J’ai un champ alpha qui ne contient que des nombres avec ou sans
virgule.

Exemple : “13,5” ou “45”

On veut passer ce champ alpha en réel : pas de problème.

Le problème est de convertir la donnée dans le champ : après que le champ a été converti en réel, la donnée perd sa partie décimale.

La contrainte : le champ devra être converti en une fois lors de l’ouverture du serveur.

Suis-je clair ?

bonjour,

tu pourrais faire :

  • soit un champ alpha supplémentaire au lieu de le convertir. Pas de programmation, l’application d’une simple formule suffit. (ou de 2 formules pour la conversion si le champ est une clé primaire)
  • soit un export dans un fichier texte de ce champ avec sa clé primaire (en JSON ou texte simple) pour les ré-importer après modification du type de ton champ. Avec ORDA un juste peu de programmation.

mais il y a peut-être qq chose dans ta contrainte que j’ai mal compris ?

Merci pour ces réflexions

: Luc STELL
  • soit un champ alpha supplémentaire au lieu de le convertir. Pas de
    programmation, l’application d’une simple formule suffit. (ou de 2
    formules pour la conversion si le champ est une clé primaire)
    C’est ce que j’aimerais éviter car mes tables sont déjà bien chargée :pray: (mais je crains que ce soit la bonne solution)
: Luc STELL
  • soit un export dans un fichier texte de ce champ avec sa clé
    primaire (en JSON ou texte simple) pour les ré-importer après
    modification du type de ton champ. Avec ORDA un juste peu de
    programmation.
    Compliqué. Ça veut dire que la mise à jour se fait en 2 passes

Jean 2:11

Plus sérieusement n’est ce pas du au stockage de 13,5 et pas de 13.5 ?

EXPORT
<code 4D>
//Export Method

C_object($o_sel;$o_objExport)
$o_sel:=ds[“MATABLE”].all()
// New object pour exporter 2 champs dans 2 collections d’un objet
$o_objExport:=New object(“cID”;"";“cName”;"")
// clé primaire vers collection
$o_objExport.cID:=$o_sel[“Id”]
// champ transform to collection
$o_objExport.cName:=$o_sel[“Name”] // nom de champ à changer
// on sauvegarde dans un fichier texte
TEXT TO DOCUMENT(Get 4D folder(Database folder)+“fieldtoconvert.txt”;JSON Stringify($o_objExport))

</code 4D>

IMPORT
<code 4D>
//Import Method
C_OBJECT($o_record;$o_objImport)
$o_objImport:=New object()
//on recupere le contenu du fichier exporté
$o_objImport:=JSON Parse(Document to text(Get 4D folder(Database folder)+“fieldtoconvert.txt”))

C_LONGINT($i)
//On reimporte les données
For ($i;0;$o_objImport.cID.length-1)
$o_record:=ds[“MATABLE”].get($o_objImport.cID[$i])
$o_record.Name:=num($o_objImport.cName[$i];",") // on precise le separateur = virgule
$o_record.save()
End for

</code 4D>

: Paul KUHN

Plus sérieusement n’est ce pas du au stockage de 13,5 et pas de 13.5 ?
bien sûr! En alpha il est écrit “13,5”

: Luc STELL

EXPORT

Merci :wink:

Mon attente est de pouvoir recycler ce champ en 1 seul appel au lancement de la base sachant que si je passe tout de suite en réel, je perds les décimales et si je corrige la virgule en point, le champ est encore en alpha et je devrai faire une deuxième passe après conversion du champ en réel.

Ok, alors tu mets les 2 méthodes en 1 seule et tu ajoutes au milieu quelque chose du genre (syntaxe à verifier) pour modifier le type du champ en REEL :
<code 4D>

Begin SQL
ALTER TABLE “MATABLE” ALTER COLUMN “Name” TYPE REAL;
End SQL

</code 4D>

: Luc STELL

Ok, alors tu mets les 2 méthodes en 1 seule et tu ajoutes au milieu
quelque chose du genre (syntaxe à verifier) pour modifier le type du
champ en REEL :

Voila!

sous réserve que ça marche, ça me plait bien ça !

ca va marcher (syntaxe SQL à vérifier), il te faut juste dupliquer la base et faire un test sur un jeu de données.
Attention toutefois avec ORDA à la casse des caractères dans le nom des tables et des champs (par ex “ID” != “Id”) Idem pour SQL je crois et mots réservés (ex: “default” ne peut pas être utilisé comme nom de champ)

Le problème sera aussi de savoir quelle est la “qualité” des données, surtout si elles ont été saisies par des “humains” (espaces, caracteres parasites invisibles, points au lieu de virgules,…). Certains utilisateurs sont très “inventifs”.
Tu as peut-être intérêt à filtrer les caractères lors de l’import (l’avantage de le faire à l’import seulement, c’est qu’en exportant, cela te fera une mini sauvegarde dans un fichier texte séparé)

Mouais, sous tellement de réserves qu’à mon avis c’est sans issue. Déjà, ALTER COLUMN n’existe pas dans le https://doc.4d.com/4Dv16/4D/16/ALTER-TABLE.300-3201314.fr.htmllexique> 4D SQL. Il reste ZIGOUILLER COLUMN et PROCREER COLUMN (oui, oui, je suis un peu énervé avec les verbes dans 4D, surtout avec le franglais), ce qui reviendra à peu près au même que retyper le champ “à la classique” - à ceci près qu’il y a intérêt à ne pas avoir d’autres champs supprimés dans la table.

Matthieu 7:13

https://www.youtube.com/watch?v=liI-yS_4H-AAmen>

oui, implémentation SQL pas complete :roll:
maintenant DROP COLUMN puis ADD COLUMN “devrait” peut-être fonctionner (je reste prudent du coup)
Bon ça fait effectivement beaucoup pour si peu à faire en quelques clics depuis l’interface graphique :mrgreen:

: Luc STELL

(je reste prudent du coup)
[]33405980;“Your comment here…”[/]

Le code ci-dessous fonctionne (testé) mais ça supprime le champ pour le recréer (avec un nouveau Nr de champ interne 4D). Il y aura donc les méthodes et formulaires qui utilisaient l’ancien champ qu’il faudra modifier. Pas le plus simple non plus…

<code 4D>

Begin SQL
ALTER TABLE MATABLE DROP Monchamp;
ALTER TABLE MATABLE ADD Monchamp REAL;
End SQL

</code 4D>

Il y a plusieurs bases à modifier ?
S’il n’y en a qu’une, c’est plus simple à la main.

J’ai fait un essai en remplaçant la virgule par le point, puis en changeant le type et ça fonctionne.
Mais pas réussi avec le jargon SQL…

: Luc STELL

maintenant DROP COLUMN puis ADD COLUMN “devrait” peut-être fonctionner
Pas plus maintenant https://forums.4d.com/Post/FR/18876608/1/18876762#18876609qu’avant> :wink: À mon humble avis, SQL, ça va pour ajouter à une structure (vide ou existante), mais c’est miné pour modifier. Et encore, je regarderais à 3 fois ce qui se passe quand j’ajoute alors que des champs ou des tables ont été supprimés dans la structure.

Pour le problème initial, je ferais simplement :

  • ajout nouveau champ réel
  • moulinette de conversion qui renseigne ce nouveau champ avec l’alpha
  • virer l’alpha de l’interface
  • à l’ouverture d’un data “ancienne version”, déclenchement de la moulinette
    La “deuxième passe”, du coup, j’y pense plus.
    Faudrait que ça me pose des problèmes de place ou de performances titanesques pour que je fasse autrement.
: Arnaud DE MONTARD

Pour le problème initial, je ferais simplement :

Yes!!! On est pareil toi et moi, yeah!