Welcome Guest! Log in
×

Notice

The forum is in read only mode.
Due to some maintenance operations, stambia.org will be switched to read-only mode during the 13th November. It will be possible to read and download, but impossible to post on the forums or create new accounts. For any question please contact the support team.

Topic-icon Question Problème de template pour certains update

More
08 Oct 2018 15:18 #1 by Benjamin M.
Benjamin M. created the topic: Problème de template pour certains update
Bonjour,

J'ai remarqué il y a quelque temps un fonctionnement qui ne me semble pas être bon lorsque l'on fait un update ou du moins pas logique par rapport au fonctionnement attendu d'un update.

J'ai 2 tables, une table source UPDATE_KO_SRC et une table de destination UPDATE_KO_DEST (ne pas tenir compte des colonnes ID qui ne servent pas pour l'exemple) :
IF OBJECT_ID('dbo.UPDATE_KO_DEST') IS NOT NULL
    DROP TABLE dbo.UPDATE_KO_DEST

CREATE TABLE UPDATE_KO_DEST
(
    ID INT IDENTITY(1, 1)
    , KEY_1 INT
    , KEY_2 INT
    , KEY_3 INT
    , LIB		 VARCHAR(50)
    , DATE_EXP DATE
)


IF OBJECT_ID('dbo.UPDATE_KO_SRC') IS NOT NULL
    DROP TABLE dbo.UPDATE_KO_SRC

CREATE TABLE dbo.UPDATE_KO_SRC
(
    KEY_1 INT
    , KEY_2 INT
    , KEY_3 INT
    , LIB		VARCHAR(50)
    , DATE_EXP DATE
)

A l'aide d'un mapping, je souhaite mettre à jour les lignes de la table de destination en ne me basant que sur 2 champs de la clef d'unicité (je fais un max pour pouvoir faire évoluer la valeur à mettre à jour, c'est un exemple) :
You do not have permissions to access this page.


INSERT INTO dbo.UPDATE_KO_DEST(KEY_1, KEY_2, KEY_3) VALUES(1, 1, 1)
INSERT INTO dbo.UPDATE_KO_DEST(KEY_1, KEY_2, KEY_3) VALUES(1, 1, 2)
INSERT INTO dbo.UPDATE_KO_DEST(KEY_1, KEY_2, KEY_3) VALUES(2, 1, 1)
INSERT INTO dbo.UPDATE_KO_DEST(KEY_1, KEY_2, KEY_3) VALUES(2, 2, 1)

INSERT INTO dbo.UPDATE_KO_SRC(KEY_1, KEY_2, KEY_3, LIB, DATE_EXP) VALUES(1, 1, 1, 'Lib111', GETDATE())
INSERT INTO dbo.UPDATE_KO_SRC(KEY_1, KEY_2, KEY_3, LIB, DATE_EXP) VALUES(2, 1, 1, 'Lib211', GETDATE() -1)
INSERT INTO dbo.UPDATE_KO_SRC(KEY_1, KEY_2, KEY_3, LIB, DATE_EXP) VALUES(3, 1, 1, 'Lib311', GETDATE() + 3)

SELECT * FROM dbo.UPDATE_KO_SRC
SELECT * FROM dbo.UPDATE_KO_DEST

On obtient donc :
You do not have permissions to access this page.


Si on exécute le mapping, puis à nouveau :
SELECT * FROM dbo.UPDATE_KO_SRC
SELECT * FROM dbo.UPDATE_KO_DEST

On obtient un résultat logique :
You do not have permissions to access this page.



Maintenant, si j'ajoute une nouvelle ligne dans ma table de destination, ligne ayant déjà des données sur le couple (KEY_1, KEY_2) dans la table :
INSERT INTO dbo.UPDATE_KO_DEST(KEY_1, KEY_2, KEY_3) VALUES(1, 1, 3)
SELECT * FROM dbo.UPDATE_KO_DEST

You do not have permissions to access this page.


Si on exécute à nouveau le mapping et la requête :
SELECT * FROM dbo.UPDATE_KO_DEST

On obtient :
You do not have permissions to access this page.


Ce qui implique que la nouvelle ligne n'a pas été mise à jour --> Non respect de la demande d'update.
More
08 Oct 2018 15:18 - 08 Oct 2018 15:19 #2 by Benjamin M.
Benjamin M. replied the topic: Problème de template pour certains update
Ce problème semble venir du fait que dans le template, on cherche ce qui doit être mis à jour :
2018-10-0814_44_27-Stambia-platform__resource_SAP_I_MF_indy.build_03.Process__TEST_UPDATE_KO_UPDA_2018-10-08.png


Puis ce qui ne doit pas être mis à jour car on a une ligne avec les mêmes données :
2018-10-0814_44_43-Stambia-platform__resource_SAP_I_MF_indy.build_03.Process__TEST_UPDATE_KO_UPDA_2018-10-08.png


Avant de faire l'update réellement :
2018-10-0814_44_57-Stambia-platform__resource_SAP_I_MF_indy.build_03.Process__TEST_UPDATE_KO_UPDA_2018-10-08.png


On voit bien ici que Stambia détecte qu'il faut mettre à jour 2 lignes avant de finalement dire qu'il ne faut pas les mettre à jour car une ligne avec ces valeurs existe déjà. C'est le cas en effet mais pourtant il faut tout de même mettre à jour les lignes sinon, la donnée n'est pas bonne sur la nouvelle ligne. Il semble que vous partiez du principe que la clef est forcément une clef d'unicité ce qui n'est pas vrai. Lorsqu'on fait un update, on peut tout à fait se baser sur une clef non unique.


Pour info, si j'ajoute une ligne avec une date plus récente dans la table source et que je relance le mapping :
INSERT INTO dbo.UPDATE_KO_SRC(KEY_1, KEY_2, KEY_3, LIB, DATE_EXP) VALUES(1, 1, 2, 'Lib1', GETDATE() + 1)

La ligne non mise à jour précédemment et cette fois bien mise à jour (pas de ligne avec la même donnée). Il ne m'est pas possible de mettre une nouvelle capture ...


Pour solutionner le problème, peut-être qu'il faudrait :
Soit pouvoir forcer les mises à jour même en cas de donnée identique (même si j'ai bien conscience que cela implique des LOG en plus ...)
Soit vérifier le nombre de ligne avec valeur identique VS nombre de ligne à mettre à jour (1ere étape) le tout par valeur de la clef --> on sait si au moins une ligne est à mettre à jour ou pas.

Est-ce que ce fonctionnement vous semble normal ? Est-ce qu'il est possible de faire évoluer cela ? Pour moi, c'est un fonctionnement anormal puisqu'au final, on obtient pas le résultat normalement attendu mais j'ai aussi pu rater une option ou autre chose.


Cordialement,
Benjamin
Attachments:
Last Edit: 08 Oct 2018 15:19 by Benjamin M..
More
08 Oct 2018 15:22 #3 by Benjamin M.
Benjamin M. replied the topic: Problème de template pour certains update
Je remets le premier post, il y a un souci avec les captures d'écran :


Bonjour,

J'ai remarqué il y a quelque temps un fonctionnement qui ne me semble pas être bon lorsque l'on fait un update ou du moins pas logique par rapport au fonctionnement attendu d'un update.

J'ai 2 tables, une table source UPDATE_KO_SRC et une table de destination UPDATE_KO_DEST (ne pas tenir compte des colonnes ID qui ne servent pas pour l'exemple) :
IF OBJECT_ID('dbo.UPDATE_KO_DEST') IS NOT NULL
    DROP TABLE dbo.UPDATE_KO_DEST

CREATE TABLE UPDATE_KO_DEST
(
    ID INT IDENTITY(1, 1)
    , KEY_1 INT
    , KEY_2 INT
    , KEY_3 INT
    , LIB		 VARCHAR(50)
    , DATE_EXP DATE
)


IF OBJECT_ID('dbo.UPDATE_KO_SRC') IS NOT NULL
    DROP TABLE dbo.UPDATE_KO_SRC

CREATE TABLE dbo.UPDATE_KO_SRC
(
    KEY_1 INT
    , KEY_2 INT
    , KEY_3 INT
    , LIB		VARCHAR(50)
    , DATE_EXP DATE
)

A l'aide d'un mapping, je souhaite mettre à jour les lignes de la table de destination en ne me basant que sur 2 champs de la clef d'unicité (je fais un max pour pouvoir faire évoluer la valeur à mettre à jour, c'est un exemple) :
2018-10-0814_20_53-Stambia-_SAP_I_MF_03.Process__TEST_UPDATE_KO_UPDATE_KO.map-StambiaDesigner_2018-10-08.png 


INSERT INTO dbo.UPDATE_KO_DEST(KEY_1, KEY_2, KEY_3) VALUES(1, 1, 1)
INSERT INTO dbo.UPDATE_KO_DEST(KEY_1, KEY_2, KEY_3) VALUES(1, 1, 2)
INSERT INTO dbo.UPDATE_KO_DEST(KEY_1, KEY_2, KEY_3) VALUES(2, 1, 1)
INSERT INTO dbo.UPDATE_KO_DEST(KEY_1, KEY_2, KEY_3) VALUES(2, 2, 1)

INSERT INTO dbo.UPDATE_KO_SRC(KEY_1, KEY_2, KEY_3, LIB, DATE_EXP) VALUES(1, 1, 1, 'Lib111', GETDATE())
INSERT INTO dbo.UPDATE_KO_SRC(KEY_1, KEY_2, KEY_3, LIB, DATE_EXP) VALUES(2, 1, 1, 'Lib211', GETDATE() -1)
INSERT INTO dbo.UPDATE_KO_SRC(KEY_1, KEY_2, KEY_3, LIB, DATE_EXP) VALUES(3, 1, 1, 'Lib311', GETDATE() + 3)

SELECT * FROM dbo.UPDATE_KO_SRC
SELECT * FROM dbo.UPDATE_KO_DEST

On obtient donc :
2018-10-0814_26_51-SQLQuery9.sql-SQLGRPDTWTST.SNPSASSTAUBLIPRI_e0bmil74_-MicrosoftSQLSe_2018-10-08.png


Si on exécute le mapping, puis à nouveau :
SELECT * FROM dbo.UPDATE_KO_SRC
SELECT * FROM dbo.UPDATE_KO_DEST

On obtient un résultat logique :
2018-10-0814_31_33-SQLQuery9.sql-SQLGRPDTWTST.SNPSASSTAUBLIPRI_e0bmil74_-MicrosoftSQLSe_2018-10-08.png



Maintenant, si j'ajoute une nouvelle ligne dans ma table de destination, ligne ayant déjà des données sur le couple (KEY_1, KEY_2) dans la table :
INSERT INTO dbo.UPDATE_KO_DEST(KEY_1, KEY_2, KEY_3) VALUES(1, 1, 3)
SELECT * FROM dbo.UPDATE_KO_DEST

2018-10-0814_35_12-SQLQuery9.sql-SQLGRPDTWTST.SNPSASSTAUBLIPRI_e0bmil74_-MicrosoftSQLSe_2018-10-08.png


Si on exécute à nouveau le mapping et la requête :
SELECT * FROM dbo.UPDATE_KO_DEST

On obtient :
2018-10-0814_41_48-SQLQuery9.sql-SQLGRPDTWTST.SNPSASSTAUBLIPRI_e0bmil74_-MicrosoftSQLSe_2018-10-08.png
Se.png[/attachment]

Ce qui implique que la nouvelle ligne n'a pas été mise à jour --> Non respect de la demande d'update.
Attachments:
More
09 Oct 2018 09:49 #4 by Thomas BLETON
Thomas BLETON replied the topic: Problème de template pour certains update
Bonjour Benjamin et merci pour les informations détaillées :)

Je pense qu'en effet ce comportement n'est pas normal, on va regarder ça de près et on fera un retour ici même.
A suivre...
More
11 Oct 2018 10:07 #5 by Benjamin M.
Benjamin M. replied the topic: Problème de template pour certains update
Bonjour,

2 petites remarques plus ou moins en relation avec le sujet. Je peux ouvrir un ticket ou un nouveau sujet pour la seconde partie si besoin.

1/
Pour le sujet présenté ci-dessus, dans le cas où dans un mapping, sur une même table de destination, on a un INSERT et UPDATE, il est nécessaire d'avoir au minimum une clef d'unicité puisque sans cela, on ne fait pas d'INSERT. Dans le cas d'un UPDATE la clef n'a pas forcément à être unique. Donc à voir s'il est possible d'avoir une clef pour l'INSERT et une pour l'UPDATE. Sachant que si l'utilisateur ne saisit pas de clef pour l'UPDATE, on conserve celle de l'INSERT ce qui nous donne l'équivalent d'un MERGE et dans le cas où il saisit une clef, on permet l'insertion et une mise à jour globale sur la seconde clef (pas sûr d'être très clair).



2/
Un collègue avait été confronté, il y a quelque temps, à un problème lorsque dans un mapping dans lequel on fait un update, il y a un champ SQL Server au format TEXT ou NTEXT. En effet, ce type de donnée ne peut pas être comparé via l'opérateur "=" :
SELECT 1
WHERE CAST('A' AS NTEXT) = CAST('A' AS NTEXT)

On obtient le message d'erreur suivant :
Msg 402, Level 16, State 1, Line 11
The data types ntext and ntext are incompatible in the equal to operator.

Il avait alors fallu désactiver la comparaison champ source vs champ destination car sans cela, le mapping plantait. Il serait bon de permettre de désactiver cette étape de comparaison (entre autre pour ce cas de figure). Cette modification "corrige" aussi le problème évoqué précédemment ou plutôt contourne ce problème.



Cordialement,
Benjamin