Discussion :

[rgarnier]

Bonjour,

Voici mon problème : j'ai une base qui a des intégrités référentielles. Je dois faire des inserts et updates sur ces bases mais le pb est le suivant.

Si je ne renseigne rien dans mon champ avec intégrité, le DAC va mettre '' lors de l'insertion et boum!! ma bdd me renvoie une erreur d'intégrité, ce qui est normal car je n'ai pas d'enreg avec comme clé '' (qui plus est, il est impossible d'en créer une car une contrainte not null est sur le champ référent).

Quelqu'un a-t-il déjà eu ce cas ???

J'ai essayé un truc, c'est d'envoyer une fonction dans mon BeforeXmlGram qui va modifier le :CHAMP par NULL. Ca marche, mais evidemment comme la requête est gardée en mémoire, lors de mon prochain appel à cette requête, le NULL va rester... y a-t-il un moyen de recharger la requête du fichier xml ???

pour info, voici ma petite fonction :
procedure VerifChamp(const Context : IXMLContext; var XmlGram : IXmlGram ; MyRequete,sChamp: string);
var
MyXMLInstruction : IXMLInstruction;
MyDBExtract : TDBBatch;
begin
MyXMLInstruction := XMLGram.GetXMLInstruction('MyRequete');
MyDBExtract := TDBBatch(MyXMLInstruction.Get_ObjectReference);
if Context.Values[MyChamp]= '' then
begin
MyDBExtract.Statement := StringReplace(MyDBExtract.Statement,':'+MyChamp,'NULL',[rfReplaceAll]);
end;

Merci d'avance

[TOM-Z]

Je ne comprends pas bien ton pb, mais tu as dû le règler de puis le 29/01.

Il est toujours préférable de vérifier l'intégrité des données côté serveur, cad après envoi de la Form et dans dans un beforexmlgram. En cas de non intégrité tu renvoies sur la form mal renseignée avec un msg d'erreur...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
function InsertOPERATION_BeforeXMLService(XMLService)
{
 
  if (Context.GetValue("ID_IMPUTATION")== '0') 
    throw (Error("Vous devez choisir une imputation"));
  if (Context.GetValue("ID_NATURE_MISSION")== '0') 
    throw (Error("Vous devez choisir un type de mission"));
  if (Context.GetValue("PROTOCOLE_OP")== '') 
    throw (Error("Vous devez choisir un type de protocole"));
  if (Context.GetValue("ID_AVANCE")== '0') 
    throw (Error("Vous devez choisir un état d'avancement"));
  if (Context.GetValue("MONTANT_OP")== '0') 
    throw (Error("Le Montant ne peut être"));
  if (Context.GetValue("MONTANT_DEVIS")== '0') 
    throw (Error("Le Montant du devis ne peut être nul"));
 
}

[rgarnier]

En fait, j'ai depuis contourné le pb, mais il reste cependant d'actualité.

Le pb est que le DAC ne gère pas les NULL, cad que si la valeur du context ID_LIEN (qui est soumise à intégrité dans une autre table) est égale à '', c'est correct dans ma table car ce champ n'est pas obligatoire.

ce que je voudrais, c'est que lors de mon insert, je puisse mettre NULL au lieu de '' car '' n'existe pas dans ma table de référence.

P.S. : EN fait j'utilise maintenant le {$Valeur} dans mes requêtes qui me permettent dans le beforexmlgram de l'initialiser soit à :ID_LIEN, soit à NULL et ça marche bien. (mais c'est pas automatique ...

[Sylvain James]

En fait, j'ai depuis contourné le pb, mais il reste cependant d'actualité.

ce que je voudrais, c'est que lors de mon insert, je puisse mettre NULL au lieu de '' car '' n'existe pas dans ma table de référence.

P.S. : EN fait j'utilise maintenant le {$Valeur} dans mes requêtes qui me permettent dans le beforexmlgram de l'initialiser soit à :ID_LIEN, soit à NULL et ça marche bien. (mais c'est pas automatique ...

Presque 4 ans après...

Et tu affectes quoi comme valeur dans SetValue pour que ce soit NULL ?

Je me trouve dans le même cas.
La soluce de trafiquer les NULL me dérange un peu.
L'autre soluce c'est d'ajouter un enregistrement vide dans la table de référence et dont l' ID = 0. La seule contrainte, c'est lorsqu'on présente dans une grille par exemple, la liste de ces données de référence, il faut ajouter une restriction SQL : Where ID > 0
Dans le cas d'une balise HTML Select, si on veut permettre un choix null à l'utilisateur, on lui propose tous les enregistrements, dont le vide.

Sylvain

[rgarnier]

oulà, je me demandais bien pourquoi ce post était de retour ....

En fait, j'ai la chance d'avoir des normes de nommage de champs de ma BD qui font que je sais identifier en fonction de son nom, un champ avec intégrité référentielle. Du coup, je modifie le dacado.pas:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
 
procedure TDacAdoQuery.InternalSetParamAsString
var
  ...
begin
  ...
  if (Value = '') and (Copy(Parameter.Name,1,1) = 'K')then
  begin
    Parameter.Value := null;
  end;
...
end;

Ok, c'est pas très propre, mais robuste
(en fonction de la bd, tu pourrais aller regarder dans les tables systèmes la liste des champs avec intégrité, c'est peut-être une piste)

Ta solution d'ajouter un enreg 0 est à mon avis mon bonne, car d'un côté tu annonce que ta BD respecte les (bonnes) règles d'une BD relationnelle, et puis tu bidouille un enregistrement qui n'en n'est pas un.
Si un architecte voit ça, j'imagine qu'il va faire des bonds à se cogner la tête au plafond.

Tiens-moi au courant de tes investigations, je suis preneur de tout avis sur la question (très sensible chez pas mal de nos clients)

[Sylvain James]

oulà, je me demandais bien pourquoi ce post était de retour ....
Si un architecte voit ça, j'imagine qu'il va faire des bonds à se cogner la tête au plafond.

hé hé c'est pas faux :-)
On est devant une réalité embarassante. D'un côté Delos qui préconise l'abandon des NULL et d'un autre côté un héritage de technologies et de techniques qui impliquent la prise en compte des null.
Le fait est qu'en SQL, 0 est différent de NULL et est susceptible d'avoir une signification sémantique complètement différente.

Ma soluce est loin d'être idéale puisqu'elle implique des adaptations - voire une certaine complexification - au niveau de la gestion des données et de la présentation.
Ta solution est restrictive puisqu'elle implique d'avoir un modèle de données respectant une norme de nommage. Malgré tout c'est une bonne idée.

Alors je me dis qu'on pourrait adapter ta solution de la sorte :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
procedure TDacAdoQuery.InternalSetParamAsString
var
  ...
begin
  ...
  if (Value = '') and (XMLApplication.InitParams.Values['XMLC_AllowNULLValue'] = '1') then
  begin
// tester aussi si le type du champ n'est pas string par ex.
    Parameter.Value := null;
  end;
...
end;

Ca permettrait de travailler avec des "NULL" quand les champs sont vides pour peu qu'on l'ait indiqué dans les InitParams. Il reste quelques inconvénients cependant.

Par exemple comment déterminer qu'une chaine est NULL ou vide ? Il faudrait que cette règle ne s'applique que sur certains types de champs, ou bien tu as raison, uniquement sur ceux qui font l'objet d'un intégrité référentielle.

Et ne s'éloigne-t-on pas de la philosophie d'XMLRAD qui consiste à encadrer le développeur au maximum ? En permettant les écarts (si on accepte que c'en est un), ne brise-t-on pas ce bénéfice de l'encadrement...

à discuter, mais il faut bien admettre que l'absence de NULL introduit aussi des difficultés.

PS : J'avais envie de battre un record : l'attente maxi avant de répondre à une question

[Jeweller]

Si il y en a que ca interesse, voici comment je contourne ce pb:

Les requetes sont ecrites alors comme ca (un parametre NU_PRIACH est déclaré de type FLOAT):

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
UPDATE TABLE
SET
NU_PRIACH = {$NU_PRIACH_PAR},
....
WHERE CLE = :CLE

Et du code par code, on peut faire un truc comme ca:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
 
  if Context.GetValue('NU_PRIACH') <> '' then
  begin
    s :=  Job.GetStrFloat(Context.GetValue('NU_PRIACH')); //gestion des formats
    if s = ''
    then //raise d'une erreur de saisie
    else Context.SetValue('NU_PRIACH',s);
    Context.SetValue('NU_PRIACH_PAR',':NU_PRIACH');
  end else
  begin
    Context.SetValue('NU_PRIACH_PAR','NULL');
    Context.SetValue('NU_PRIACH','0'); // pour tests ultérieurs
  end;

L'avantage, cest qu'on touche pas au framework, mais le gros inconvinient c'est qu'il faut coder à chaque fois (même si c'est factorisable), mais pour les champs float, dates ou meme string, on maitrise vraiment ce qui est inséré ou mis à jour!
Bonne vacances (j'ai pas résisté!) ;-)
Michael