Bonjour à tous,
Je développe un lot SSIS afin de récupérer, entre autres, les données d'une
comptabilité (base Oracle) et celles d'une base de production (base SQL).
Il faut limiter la récupération des éléments dans le temps, ce qui se fait
très simplement pour la base Oracle (qui stocke l'information dans une table
que j'utilise en condition de mes requêtes Oracle). La subtilité, c'est que
les dates sont stockées sous forme de nombres.
J'ai donc créé une variable Date_debut avec un scope au niveau de mon lot.
J'ai ensuite créé une tâche SQL qui exécute le script Oracle suivant :
SELECT TO_DATE(DEB_EXC_N_2,'YYYYMMDD') AS DEB_EXC_N_2 FROM SOC
J'ai paramétré le Result Set à 'Single Row' (General), et ajouté ma variable
User::Date_debut en nommant le résultat DEB_EXC_N_2 (Result set).
Cette tâche ne renvoie aucune erreur.
Le dataflow qui s'exécute immédiatement derrière cette tâche appelle la base
SQL.
Schématiquement, le code utilisé est :
SELECT * FROM TABLE1 T1 INNER JOIN TABLE2 T2
ON T1.Code = T2.Code
WHERE T1.Date_deb > ? OR T2.Date_deb > ?
Dans les paramètres SQL j'ai affecté User::Date_debut à Parameter0 et
Parameter1.
Cette tâche non plus ne renvoie pas d'erreur, comme le reste du lot
d'ailleurs.
Cependant la valeur chargée devrait être le 1er janvier 2005, or je récupère
les données quelle que soit la valeur de leur date.
Apparemment il est possible de définir des variables pour exécuter du code,
ce qui pourrait peut-être permettre de contourner cette difficulté, mais cela
signifie donc une variable par requête, ce que je voudrais éviter.
Est-il possible d'envisager de fonctionner ainsi, ou fais-je fausse route ?
Merci de vos lumières et conseils, et bonne journée à tous.
Bonjour à tous,
Je développe un lot SSIS afin de récupérer, entre autres, les données d'une
comptabilité (base Oracle) et celles d'une base de production (base SQL).
Il faut limiter la récupération des éléments dans le temps, ce qui se fait
très simplement pour la base Oracle (qui stocke l'information dans une table
que j'utilise en condition de mes requêtes Oracle). La subtilité, c'est que
les dates sont stockées sous forme de nombres.
J'ai donc créé une variable Date_debut avec un scope au niveau de mon lot.
J'ai ensuite créé une tâche SQL qui exécute le script Oracle suivant :
SELECT TO_DATE(DEB_EXC_N_2,'YYYYMMDD') AS DEB_EXC_N_2 FROM SOC
J'ai paramétré le Result Set à 'Single Row' (General), et ajouté ma variable
User::Date_debut en nommant le résultat DEB_EXC_N_2 (Result set).
Cette tâche ne renvoie aucune erreur.
Le dataflow qui s'exécute immédiatement derrière cette tâche appelle la base
SQL.
Schématiquement, le code utilisé est :
SELECT * FROM TABLE1 T1 INNER JOIN TABLE2 T2
ON T1.Code = T2.Code
WHERE T1.Date_deb > ? OR T2.Date_deb > ?
Dans les paramètres SQL j'ai affecté User::Date_debut à Parameter0 et
Parameter1.
Cette tâche non plus ne renvoie pas d'erreur, comme le reste du lot
d'ailleurs.
Cependant la valeur chargée devrait être le 1er janvier 2005, or je récupère
les données quelle que soit la valeur de leur date.
Apparemment il est possible de définir des variables pour exécuter du code,
ce qui pourrait peut-être permettre de contourner cette difficulté, mais cela
signifie donc une variable par requête, ce que je voudrais éviter.
Est-il possible d'envisager de fonctionner ainsi, ou fais-je fausse route ?
Merci de vos lumières et conseils, et bonne journée à tous.
Bonjour à tous,
Je développe un lot SSIS afin de récupérer, entre autres, les données d'une
comptabilité (base Oracle) et celles d'une base de production (base SQL).
Il faut limiter la récupération des éléments dans le temps, ce qui se fait
très simplement pour la base Oracle (qui stocke l'information dans une table
que j'utilise en condition de mes requêtes Oracle). La subtilité, c'est que
les dates sont stockées sous forme de nombres.
J'ai donc créé une variable Date_debut avec un scope au niveau de mon lot.
J'ai ensuite créé une tâche SQL qui exécute le script Oracle suivant :
SELECT TO_DATE(DEB_EXC_N_2,'YYYYMMDD') AS DEB_EXC_N_2 FROM SOC
J'ai paramétré le Result Set à 'Single Row' (General), et ajouté ma variable
User::Date_debut en nommant le résultat DEB_EXC_N_2 (Result set).
Cette tâche ne renvoie aucune erreur.
Le dataflow qui s'exécute immédiatement derrière cette tâche appelle la base
SQL.
Schématiquement, le code utilisé est :
SELECT * FROM TABLE1 T1 INNER JOIN TABLE2 T2
ON T1.Code = T2.Code
WHERE T1.Date_deb > ? OR T2.Date_deb > ?
Dans les paramètres SQL j'ai affecté User::Date_debut à Parameter0 et
Parameter1.
Cette tâche non plus ne renvoie pas d'erreur, comme le reste du lot
d'ailleurs.
Cependant la valeur chargée devrait être le 1er janvier 2005, or je récupère
les données quelle que soit la valeur de leur date.
Apparemment il est possible de définir des variables pour exécuter du code,
ce qui pourrait peut-être permettre de contourner cette difficulté, mais cela
signifie donc une variable par requête, ce que je voudrais éviter.
Est-il possible d'envisager de fonctionner ainsi, ou fais-je fausse route ?
Merci de vos lumières et conseils, et bonne journée à tous.
OokieDookie a écrit :
> Bonjour à tous,
>
> Je développe un lot SSIS afin de récupérer, entre autres, les données d'une
> comptabilité (base Oracle) et celles d'une base de production (base SQL).
>
> Il faut limiter la récupération des éléments dans le temps, ce qui se fait
> très simplement pour la base Oracle (qui stocke l'information dans une table
> que j'utilise en condition de mes requêtes Oracle). La subtilité, c'est que
> les dates sont stockées sous forme de nombres.
>
> J'ai donc créé une variable Date_debut avec un scope au niveau de mon lot.
>
> J'ai ensuite créé une tâche SQL qui exécute le script Oracle suivant :
> SELECT TO_DATE(DEB_EXC_N_2,'YYYYMMDD') AS DEB_EXC_N_2 FROM SOC
> J'ai paramétré le Result Set à 'Single Row' (General), et ajouté ma variable
> User::Date_debut en nommant le résultat DEB_EXC_N_2 (Result set).
> Cette tâche ne renvoie aucune erreur.
>
> Le dataflow qui s'exécute immédiatement derrière cette tâche appelle la base
> SQL.
> Schématiquement, le code utilisé est :
> SELECT * FROM TABLE1 T1 INNER JOIN TABLE2 T2
> ON T1.Code = T2.Code
> WHERE T1.Date_deb > ? OR T2.Date_deb > ?
>
> Dans les paramètres SQL j'ai affecté User::Date_debut à Parameter0 et
> Parameter1.
>
> Cette tâche non plus ne renvoie pas d'erreur, comme le reste du lot
> d'ailleurs.
>
> Cependant la valeur chargée devrait être le 1er janvier 2005, or je récupère
> les données quelle que soit la valeur de leur date.
>
> Apparemment il est possible de définir des variables pour exécuter du code,
> ce qui pourrait peut-être permettre de contourner cette difficulté, mais cela
> signifie donc une variable par requête, ce que je voudrais éviter.
>
> Est-il possible d'envisager de fonctionner ainsi, ou fais-je fausse route ?
>
> Merci de vos lumières et conseils, et bonne journée à tous.
>
>
>
>
pourquoi ne pas ajouter à votre modèle une table de saisie comportant
vos valeurs de sélection, alimenter cette table dans le flux et faire
une requête dessus.
Quelque chose comme :
Exemple :
CREATE TABLE T_LIMITE_TEMPS_LTP
(LTP_DATE_DEBUT DATETIME NOT NULL,
LTP_DATE_FIN DATETIME NOT NULL)
GO
DELETE FROM T_LIMITE_TEMPS_LTP
GO
INSERT INTO T_LIMITE_TEMPS_LTP
VALUES (DATEADD(day, -7, CURRENT_TIMESTAMP)), CURRENT_TIMESTAMP)
GO
-- Votre requête modifiée :
SELECT *
FROM TABLE1 T1
INNER JOIN TABLE2 T2
ON T1.Code = T2.Code
INNER JOIN T_LIMITE_TEMPS_LTP T3
ON T1.Date_deb > T3.LTP_DATE_DEBUT
OR T2.Date_deb > T3.LTP_DATE_FIN
A +
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************
OokieDookie a écrit :
> Bonjour à tous,
>
> Je développe un lot SSIS afin de récupérer, entre autres, les données d'une
> comptabilité (base Oracle) et celles d'une base de production (base SQL).
>
> Il faut limiter la récupération des éléments dans le temps, ce qui se fait
> très simplement pour la base Oracle (qui stocke l'information dans une table
> que j'utilise en condition de mes requêtes Oracle). La subtilité, c'est que
> les dates sont stockées sous forme de nombres.
>
> J'ai donc créé une variable Date_debut avec un scope au niveau de mon lot.
>
> J'ai ensuite créé une tâche SQL qui exécute le script Oracle suivant :
> SELECT TO_DATE(DEB_EXC_N_2,'YYYYMMDD') AS DEB_EXC_N_2 FROM SOC
> J'ai paramétré le Result Set à 'Single Row' (General), et ajouté ma variable
> User::Date_debut en nommant le résultat DEB_EXC_N_2 (Result set).
> Cette tâche ne renvoie aucune erreur.
>
> Le dataflow qui s'exécute immédiatement derrière cette tâche appelle la base
> SQL.
> Schématiquement, le code utilisé est :
> SELECT * FROM TABLE1 T1 INNER JOIN TABLE2 T2
> ON T1.Code = T2.Code
> WHERE T1.Date_deb > ? OR T2.Date_deb > ?
>
> Dans les paramètres SQL j'ai affecté User::Date_debut à Parameter0 et
> Parameter1.
>
> Cette tâche non plus ne renvoie pas d'erreur, comme le reste du lot
> d'ailleurs.
>
> Cependant la valeur chargée devrait être le 1er janvier 2005, or je récupère
> les données quelle que soit la valeur de leur date.
>
> Apparemment il est possible de définir des variables pour exécuter du code,
> ce qui pourrait peut-être permettre de contourner cette difficulté, mais cela
> signifie donc une variable par requête, ce que je voudrais éviter.
>
> Est-il possible d'envisager de fonctionner ainsi, ou fais-je fausse route ?
>
> Merci de vos lumières et conseils, et bonne journée à tous.
>
>
>
>
pourquoi ne pas ajouter à votre modèle une table de saisie comportant
vos valeurs de sélection, alimenter cette table dans le flux et faire
une requête dessus.
Quelque chose comme :
Exemple :
CREATE TABLE T_LIMITE_TEMPS_LTP
(LTP_DATE_DEBUT DATETIME NOT NULL,
LTP_DATE_FIN DATETIME NOT NULL)
GO
DELETE FROM T_LIMITE_TEMPS_LTP
GO
INSERT INTO T_LIMITE_TEMPS_LTP
VALUES (DATEADD(day, -7, CURRENT_TIMESTAMP)), CURRENT_TIMESTAMP)
GO
-- Votre requête modifiée :
SELECT *
FROM TABLE1 T1
INNER JOIN TABLE2 T2
ON T1.Code = T2.Code
INNER JOIN T_LIMITE_TEMPS_LTP T3
ON T1.Date_deb > T3.LTP_DATE_DEBUT
OR T2.Date_deb > T3.LTP_DATE_FIN
A +
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************
OokieDookie a écrit :
> Bonjour à tous,
>
> Je développe un lot SSIS afin de récupérer, entre autres, les données d'une
> comptabilité (base Oracle) et celles d'une base de production (base SQL).
>
> Il faut limiter la récupération des éléments dans le temps, ce qui se fait
> très simplement pour la base Oracle (qui stocke l'information dans une table
> que j'utilise en condition de mes requêtes Oracle). La subtilité, c'est que
> les dates sont stockées sous forme de nombres.
>
> J'ai donc créé une variable Date_debut avec un scope au niveau de mon lot.
>
> J'ai ensuite créé une tâche SQL qui exécute le script Oracle suivant :
> SELECT TO_DATE(DEB_EXC_N_2,'YYYYMMDD') AS DEB_EXC_N_2 FROM SOC
> J'ai paramétré le Result Set à 'Single Row' (General), et ajouté ma variable
> User::Date_debut en nommant le résultat DEB_EXC_N_2 (Result set).
> Cette tâche ne renvoie aucune erreur.
>
> Le dataflow qui s'exécute immédiatement derrière cette tâche appelle la base
> SQL.
> Schématiquement, le code utilisé est :
> SELECT * FROM TABLE1 T1 INNER JOIN TABLE2 T2
> ON T1.Code = T2.Code
> WHERE T1.Date_deb > ? OR T2.Date_deb > ?
>
> Dans les paramètres SQL j'ai affecté User::Date_debut à Parameter0 et
> Parameter1.
>
> Cette tâche non plus ne renvoie pas d'erreur, comme le reste du lot
> d'ailleurs.
>
> Cependant la valeur chargée devrait être le 1er janvier 2005, or je récupère
> les données quelle que soit la valeur de leur date.
>
> Apparemment il est possible de définir des variables pour exécuter du code,
> ce qui pourrait peut-être permettre de contourner cette difficulté, mais cela
> signifie donc une variable par requête, ce que je voudrais éviter.
>
> Est-il possible d'envisager de fonctionner ainsi, ou fais-je fausse route ?
>
> Merci de vos lumières et conseils, et bonne journée à tous.
>
>
>
>
pourquoi ne pas ajouter à votre modèle une table de saisie comportant
vos valeurs de sélection, alimenter cette table dans le flux et faire
une requête dessus.
Quelque chose comme :
Exemple :
CREATE TABLE T_LIMITE_TEMPS_LTP
(LTP_DATE_DEBUT DATETIME NOT NULL,
LTP_DATE_FIN DATETIME NOT NULL)
GO
DELETE FROM T_LIMITE_TEMPS_LTP
GO
INSERT INTO T_LIMITE_TEMPS_LTP
VALUES (DATEADD(day, -7, CURRENT_TIMESTAMP)), CURRENT_TIMESTAMP)
GO
-- Votre requête modifiée :
SELECT *
FROM TABLE1 T1
INNER JOIN TABLE2 T2
ON T1.Code = T2.Code
INNER JOIN T_LIMITE_TEMPS_LTP T3
ON T1.Date_deb > T3.LTP_DATE_DEBUT
OR T2.Date_deb > T3.LTP_DATE_FIN
A +
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************
"Fred BROUARD" a écrit :OokieDookie a écrit :Bonjour à tous,
Je développe un lot SSIS afin de récupérer, entre autres, les données d'une
comptabilité (base Oracle) et celles d'une base de production (base SQL).
Il faut limiter la récupération des éléments dans le temps, ce qui se fait
très simplement pour la base Oracle (qui stocke l'information dans une table
que j'utilise en condition de mes requêtes Oracle). La subtilité, c'est que
les dates sont stockées sous forme de nombres.
J'ai donc créé une variable Date_debut avec un scope au niveau de mon lot.
J'ai ensuite créé une tâche SQL qui exécute le script Oracle suivant :
SELECT TO_DATE(DEB_EXC_N_2,'YYYYMMDD') AS DEB_EXC_N_2 FROM SOC
J'ai paramétré le Result Set à 'Single Row' (General), et ajouté ma variable
User::Date_debut en nommant le résultat DEB_EXC_N_2 (Result set).
Cette tâche ne renvoie aucune erreur.
Le dataflow qui s'exécute immédiatement derrière cette tâche appelle la base
SQL.
Schématiquement, le code utilisé est :
SELECT * FROM TABLE1 T1 INNER JOIN TABLE2 T2
ON T1.Code = T2.Code
WHERE T1.Date_deb > ? OR T2.Date_deb > ?
Dans les paramètres SQL j'ai affecté User::Date_debut à Parameter0 et
Parameter1.
Cette tâche non plus ne renvoie pas d'erreur, comme le reste du lot
d'ailleurs.
Cependant la valeur chargée devrait être le 1er janvier 2005, or je récupère
les données quelle que soit la valeur de leur date.
Apparemment il est possible de définir des variables pour exécuter du code,
ce qui pourrait peut-être permettre de contourner cette difficulté, mais cela
signifie donc une variable par requête, ce que je voudrais éviter.
Est-il possible d'envisager de fonctionner ainsi, ou fais-je fausse route ?
Merci de vos lumières et conseils, et bonne journée à tous.
pourquoi ne pas ajouter à votre modèle une table de saisie comportant
vos valeurs de sélection, alimenter cette table dans le flux et faire
une requête dessus.
Quelque chose comme :
Exemple :
CREATE TABLE T_LIMITE_TEMPS_LTP
(LTP_DATE_DEBUT DATETIME NOT NULL,
LTP_DATE_FIN DATETIME NOT NULL)
GO
DELETE FROM T_LIMITE_TEMPS_LTP
GO
INSERT INTO T_LIMITE_TEMPS_LTP
VALUES (DATEADD(day, -7, CURRENT_TIMESTAMP)), CURRENT_TIMESTAMP)
GO
-- Votre requête modifiée :
SELECT *
FROM TABLE1 T1
INNER JOIN TABLE2 T2
ON T1.Code = T2.Code
INNER JOIN T_LIMITE_TEMPS_LTP T3
ON T1.Date_deb > T3.LTP_DATE_DEBUT
OR T2.Date_deb > T3.LTP_DATE_FIN
A +
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************
Merci de votre réponse.
J'ai déjà pensé à cela, en essayant d'éviter de modifier la base de
production, mais je n'arrive pas à utiliser deux connexions dans une même
requête.
De plus, même s'il est possible de se baser sur la date en cours pour
déduire mon information, on me demande de me baser sur la date contenue dans
la base Oracle.
- Puis-je envisager de m'entêter à (essayer d') utiliser une variable ;) ?
- Si non, est-il obligatoire d'altérer le schéma de ma base de production,
ou existe-t-il une façon de stocker l'information dans ma base de
destination, et de m'en servir dans une requête portant sur une autre base ?
Merci.
"Fred BROUARD" a écrit :
OokieDookie a écrit :
Bonjour à tous,
Je développe un lot SSIS afin de récupérer, entre autres, les données d'une
comptabilité (base Oracle) et celles d'une base de production (base SQL).
Il faut limiter la récupération des éléments dans le temps, ce qui se fait
très simplement pour la base Oracle (qui stocke l'information dans une table
que j'utilise en condition de mes requêtes Oracle). La subtilité, c'est que
les dates sont stockées sous forme de nombres.
J'ai donc créé une variable Date_debut avec un scope au niveau de mon lot.
J'ai ensuite créé une tâche SQL qui exécute le script Oracle suivant :
SELECT TO_DATE(DEB_EXC_N_2,'YYYYMMDD') AS DEB_EXC_N_2 FROM SOC
J'ai paramétré le Result Set à 'Single Row' (General), et ajouté ma variable
User::Date_debut en nommant le résultat DEB_EXC_N_2 (Result set).
Cette tâche ne renvoie aucune erreur.
Le dataflow qui s'exécute immédiatement derrière cette tâche appelle la base
SQL.
Schématiquement, le code utilisé est :
SELECT * FROM TABLE1 T1 INNER JOIN TABLE2 T2
ON T1.Code = T2.Code
WHERE T1.Date_deb > ? OR T2.Date_deb > ?
Dans les paramètres SQL j'ai affecté User::Date_debut à Parameter0 et
Parameter1.
Cette tâche non plus ne renvoie pas d'erreur, comme le reste du lot
d'ailleurs.
Cependant la valeur chargée devrait être le 1er janvier 2005, or je récupère
les données quelle que soit la valeur de leur date.
Apparemment il est possible de définir des variables pour exécuter du code,
ce qui pourrait peut-être permettre de contourner cette difficulté, mais cela
signifie donc une variable par requête, ce que je voudrais éviter.
Est-il possible d'envisager de fonctionner ainsi, ou fais-je fausse route ?
Merci de vos lumières et conseils, et bonne journée à tous.
pourquoi ne pas ajouter à votre modèle une table de saisie comportant
vos valeurs de sélection, alimenter cette table dans le flux et faire
une requête dessus.
Quelque chose comme :
Exemple :
CREATE TABLE T_LIMITE_TEMPS_LTP
(LTP_DATE_DEBUT DATETIME NOT NULL,
LTP_DATE_FIN DATETIME NOT NULL)
GO
DELETE FROM T_LIMITE_TEMPS_LTP
GO
INSERT INTO T_LIMITE_TEMPS_LTP
VALUES (DATEADD(day, -7, CURRENT_TIMESTAMP)), CURRENT_TIMESTAMP)
GO
-- Votre requête modifiée :
SELECT *
FROM TABLE1 T1
INNER JOIN TABLE2 T2
ON T1.Code = T2.Code
INNER JOIN T_LIMITE_TEMPS_LTP T3
ON T1.Date_deb > T3.LTP_DATE_DEBUT
OR T2.Date_deb > T3.LTP_DATE_FIN
A +
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************
Merci de votre réponse.
J'ai déjà pensé à cela, en essayant d'éviter de modifier la base de
production, mais je n'arrive pas à utiliser deux connexions dans une même
requête.
De plus, même s'il est possible de se baser sur la date en cours pour
déduire mon information, on me demande de me baser sur la date contenue dans
la base Oracle.
- Puis-je envisager de m'entêter à (essayer d') utiliser une variable ;) ?
- Si non, est-il obligatoire d'altérer le schéma de ma base de production,
ou existe-t-il une façon de stocker l'information dans ma base de
destination, et de m'en servir dans une requête portant sur une autre base ?
Merci.
"Fred BROUARD" a écrit :OokieDookie a écrit :Bonjour à tous,
Je développe un lot SSIS afin de récupérer, entre autres, les données d'une
comptabilité (base Oracle) et celles d'une base de production (base SQL).
Il faut limiter la récupération des éléments dans le temps, ce qui se fait
très simplement pour la base Oracle (qui stocke l'information dans une table
que j'utilise en condition de mes requêtes Oracle). La subtilité, c'est que
les dates sont stockées sous forme de nombres.
J'ai donc créé une variable Date_debut avec un scope au niveau de mon lot.
J'ai ensuite créé une tâche SQL qui exécute le script Oracle suivant :
SELECT TO_DATE(DEB_EXC_N_2,'YYYYMMDD') AS DEB_EXC_N_2 FROM SOC
J'ai paramétré le Result Set à 'Single Row' (General), et ajouté ma variable
User::Date_debut en nommant le résultat DEB_EXC_N_2 (Result set).
Cette tâche ne renvoie aucune erreur.
Le dataflow qui s'exécute immédiatement derrière cette tâche appelle la base
SQL.
Schématiquement, le code utilisé est :
SELECT * FROM TABLE1 T1 INNER JOIN TABLE2 T2
ON T1.Code = T2.Code
WHERE T1.Date_deb > ? OR T2.Date_deb > ?
Dans les paramètres SQL j'ai affecté User::Date_debut à Parameter0 et
Parameter1.
Cette tâche non plus ne renvoie pas d'erreur, comme le reste du lot
d'ailleurs.
Cependant la valeur chargée devrait être le 1er janvier 2005, or je récupère
les données quelle que soit la valeur de leur date.
Apparemment il est possible de définir des variables pour exécuter du code,
ce qui pourrait peut-être permettre de contourner cette difficulté, mais cela
signifie donc une variable par requête, ce que je voudrais éviter.
Est-il possible d'envisager de fonctionner ainsi, ou fais-je fausse route ?
Merci de vos lumières et conseils, et bonne journée à tous.
pourquoi ne pas ajouter à votre modèle une table de saisie comportant
vos valeurs de sélection, alimenter cette table dans le flux et faire
une requête dessus.
Quelque chose comme :
Exemple :
CREATE TABLE T_LIMITE_TEMPS_LTP
(LTP_DATE_DEBUT DATETIME NOT NULL,
LTP_DATE_FIN DATETIME NOT NULL)
GO
DELETE FROM T_LIMITE_TEMPS_LTP
GO
INSERT INTO T_LIMITE_TEMPS_LTP
VALUES (DATEADD(day, -7, CURRENT_TIMESTAMP)), CURRENT_TIMESTAMP)
GO
-- Votre requête modifiée :
SELECT *
FROM TABLE1 T1
INNER JOIN TABLE2 T2
ON T1.Code = T2.Code
INNER JOIN T_LIMITE_TEMPS_LTP T3
ON T1.Date_deb > T3.LTP_DATE_DEBUT
OR T2.Date_deb > T3.LTP_DATE_FIN
A +
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************
Merci de votre réponse.
J'ai déjà pensé à cela, en essayant d'éviter de modifier la base de
production, mais je n'arrive pas à utiliser deux connexions dans une même
requête.
De plus, même s'il est possible de se baser sur la date en cours pour
déduire mon information, on me demande de me baser sur la date contenue dans
la base Oracle.
- Puis-je envisager de m'entêter à (essayer d') utiliser une variable ;) ?
- Si non, est-il obligatoire d'altérer le schéma de ma base de production,
ou existe-t-il une façon de stocker l'information dans ma base de
destination, et de m'en servir dans une requête portant sur une autre base ?
Merci.
OokieDookie a écrit :
>
> "Fred BROUARD" a écrit :
>
>> OokieDookie a écrit :
>>> Bonjour à tous,
>>>
>>> Je développe un lot SSIS afin de récupérer, entre autres, les données d'une
>>> comptabilité (base Oracle) et celles d'une base de production (base SQL).
>>>
>>> Il faut limiter la récupération des éléments dans le temps, ce qui se fait
>>> très simplement pour la base Oracle (qui stocke l'information dans une table
>>> que j'utilise en condition de mes requêtes Oracle). La subtilité, c'est que
>>> les dates sont stockées sous forme de nombres.
>>>
>>> J'ai donc créé une variable Date_debut avec un scope au niveau de mon lot.
>>>
>>> J'ai ensuite créé une tâche SQL qui exécute le script Oracle suivant :
>>> SELECT TO_DATE(DEB_EXC_N_2,'YYYYMMDD') AS DEB_EXC_N_2 FROM SOC
>>> J'ai paramétré le Result Set à 'Single Row' (General), et ajouté ma variable
>>> User::Date_debut en nommant le résultat DEB_EXC_N_2 (Result set).
>>> Cette tâche ne renvoie aucune erreur.
>>>
>>> Le dataflow qui s'exécute immédiatement derrière cette tâche appelle la base
>>> SQL.
>>> Schématiquement, le code utilisé est :
>>> SELECT * FROM TABLE1 T1 INNER JOIN TABLE2 T2
>>> ON T1.Code = T2.Code
>>> WHERE T1.Date_deb > ? OR T2.Date_deb > ?
>>>
>>> Dans les paramètres SQL j'ai affecté User::Date_debut à Parameter0 et
>>> Parameter1.
>>>
>>> Cette tâche non plus ne renvoie pas d'erreur, comme le reste du lot
>>> d'ailleurs.
>>>
>>> Cependant la valeur chargée devrait être le 1er janvier 2005, or je récupère
>>> les données quelle que soit la valeur de leur date.
>>>
>>> Apparemment il est possible de définir des variables pour exécuter du code,
>>> ce qui pourrait peut-être permettre de contourner cette difficulté, mais cela
>>> signifie donc une variable par requête, ce que je voudrais éviter.
>>>
>>> Est-il possible d'envisager de fonctionner ainsi, ou fais-je fausse route ?
>>>
>>> Merci de vos lumières et conseils, et bonne journée à tous.
>>>
>>>
>>>
>>>
>> pourquoi ne pas ajouter à votre modèle une table de saisie comportant
>> vos valeurs de sélection, alimenter cette table dans le flux et faire
>> une requête dessus.
>>
>> Quelque chose comme :
>>
>> Exemple :
>> CREATE TABLE T_LIMITE_TEMPS_LTP
>> (LTP_DATE_DEBUT DATETIME NOT NULL,
>> LTP_DATE_FIN DATETIME NOT NULL)
>> GO
>>
>> DELETE FROM T_LIMITE_TEMPS_LTP
>> GO
>>
>> INSERT INTO T_LIMITE_TEMPS_LTP
>> VALUES (DATEADD(day, -7, CURRENT_TIMESTAMP)), CURRENT_TIMESTAMP)
>> GO
>>
>> -- Votre requête modifiée :
>>
>> SELECT *
>> FROM TABLE1 T1
>> INNER JOIN TABLE2 T2
>> ON T1.Code = T2.Code
>> INNER JOIN T_LIMITE_TEMPS_LTP T3
>> ON T1.Date_deb > T3.LTP_DATE_DEBUT
>> OR T2.Date_deb > T3.LTP_DATE_FIN
>>
>> A +
>>
>> --
>> Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
>> Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
>> Audit, conseil, expertise, formation, modélisation, tuning, optimisation
>> ********************* http://www.datasapiens.com ***********************
>>
>
> Merci de votre réponse.
>
> J'ai déjà pensé à cela, en essayant d'éviter de modifier la base de
> production, mais je n'arrive pas à utiliser deux connexions dans une même
> requête.
> De plus, même s'il est possible de se baser sur la date en cours pour
> déduire mon information, on me demande de me baser sur la date contenue dans
> la base Oracle.
>
> - Puis-je envisager de m'entêter à (essayer d') utiliser une variable ;) ?
Difficile mais pas impossible à condition de travailler en ligne de
commande...
> - Si non, est-il obligatoire d'altérer le schéma de ma base de production,
> ou existe-t-il une façon de stocker l'information dans ma base de
> destination, et de m'en servir dans une requête portant sur une autre base ?
vous pouvez parfaitement créer une nouvelle base comportant ces
informations.
Cepanjdant sachez que selon des règles de Codd qui dictent les principes
des SGBD relationnels depuis des décennies, l'ajout d'un objet à la base
n'altère pas son fonctionnement. Heureusement d'ailleurs, sinon il nous
faudrait envisager de retourner à la gestion de fichiers pour les
données !!!
>
> Merci.
>
>
A +
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************
OokieDookie a écrit :
>
> "Fred BROUARD" a écrit :
>
>> OokieDookie a écrit :
>>> Bonjour à tous,
>>>
>>> Je développe un lot SSIS afin de récupérer, entre autres, les données d'une
>>> comptabilité (base Oracle) et celles d'une base de production (base SQL).
>>>
>>> Il faut limiter la récupération des éléments dans le temps, ce qui se fait
>>> très simplement pour la base Oracle (qui stocke l'information dans une table
>>> que j'utilise en condition de mes requêtes Oracle). La subtilité, c'est que
>>> les dates sont stockées sous forme de nombres.
>>>
>>> J'ai donc créé une variable Date_debut avec un scope au niveau de mon lot.
>>>
>>> J'ai ensuite créé une tâche SQL qui exécute le script Oracle suivant :
>>> SELECT TO_DATE(DEB_EXC_N_2,'YYYYMMDD') AS DEB_EXC_N_2 FROM SOC
>>> J'ai paramétré le Result Set à 'Single Row' (General), et ajouté ma variable
>>> User::Date_debut en nommant le résultat DEB_EXC_N_2 (Result set).
>>> Cette tâche ne renvoie aucune erreur.
>>>
>>> Le dataflow qui s'exécute immédiatement derrière cette tâche appelle la base
>>> SQL.
>>> Schématiquement, le code utilisé est :
>>> SELECT * FROM TABLE1 T1 INNER JOIN TABLE2 T2
>>> ON T1.Code = T2.Code
>>> WHERE T1.Date_deb > ? OR T2.Date_deb > ?
>>>
>>> Dans les paramètres SQL j'ai affecté User::Date_debut à Parameter0 et
>>> Parameter1.
>>>
>>> Cette tâche non plus ne renvoie pas d'erreur, comme le reste du lot
>>> d'ailleurs.
>>>
>>> Cependant la valeur chargée devrait être le 1er janvier 2005, or je récupère
>>> les données quelle que soit la valeur de leur date.
>>>
>>> Apparemment il est possible de définir des variables pour exécuter du code,
>>> ce qui pourrait peut-être permettre de contourner cette difficulté, mais cela
>>> signifie donc une variable par requête, ce que je voudrais éviter.
>>>
>>> Est-il possible d'envisager de fonctionner ainsi, ou fais-je fausse route ?
>>>
>>> Merci de vos lumières et conseils, et bonne journée à tous.
>>>
>>>
>>>
>>>
>> pourquoi ne pas ajouter à votre modèle une table de saisie comportant
>> vos valeurs de sélection, alimenter cette table dans le flux et faire
>> une requête dessus.
>>
>> Quelque chose comme :
>>
>> Exemple :
>> CREATE TABLE T_LIMITE_TEMPS_LTP
>> (LTP_DATE_DEBUT DATETIME NOT NULL,
>> LTP_DATE_FIN DATETIME NOT NULL)
>> GO
>>
>> DELETE FROM T_LIMITE_TEMPS_LTP
>> GO
>>
>> INSERT INTO T_LIMITE_TEMPS_LTP
>> VALUES (DATEADD(day, -7, CURRENT_TIMESTAMP)), CURRENT_TIMESTAMP)
>> GO
>>
>> -- Votre requête modifiée :
>>
>> SELECT *
>> FROM TABLE1 T1
>> INNER JOIN TABLE2 T2
>> ON T1.Code = T2.Code
>> INNER JOIN T_LIMITE_TEMPS_LTP T3
>> ON T1.Date_deb > T3.LTP_DATE_DEBUT
>> OR T2.Date_deb > T3.LTP_DATE_FIN
>>
>> A +
>>
>> --
>> Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
>> Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
>> Audit, conseil, expertise, formation, modélisation, tuning, optimisation
>> ********************* http://www.datasapiens.com ***********************
>>
>
> Merci de votre réponse.
>
> J'ai déjà pensé à cela, en essayant d'éviter de modifier la base de
> production, mais je n'arrive pas à utiliser deux connexions dans une même
> requête.
> De plus, même s'il est possible de se baser sur la date en cours pour
> déduire mon information, on me demande de me baser sur la date contenue dans
> la base Oracle.
>
> - Puis-je envisager de m'entêter à (essayer d') utiliser une variable ;) ?
Difficile mais pas impossible à condition de travailler en ligne de
commande...
> - Si non, est-il obligatoire d'altérer le schéma de ma base de production,
> ou existe-t-il une façon de stocker l'information dans ma base de
> destination, et de m'en servir dans une requête portant sur une autre base ?
vous pouvez parfaitement créer une nouvelle base comportant ces
informations.
Cepanjdant sachez que selon des règles de Codd qui dictent les principes
des SGBD relationnels depuis des décennies, l'ajout d'un objet à la base
n'altère pas son fonctionnement. Heureusement d'ailleurs, sinon il nous
faudrait envisager de retourner à la gestion de fichiers pour les
données !!!
>
> Merci.
>
>
A +
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************
OokieDookie a écrit :
>
> "Fred BROUARD" a écrit :
>
>> OokieDookie a écrit :
>>> Bonjour à tous,
>>>
>>> Je développe un lot SSIS afin de récupérer, entre autres, les données d'une
>>> comptabilité (base Oracle) et celles d'une base de production (base SQL).
>>>
>>> Il faut limiter la récupération des éléments dans le temps, ce qui se fait
>>> très simplement pour la base Oracle (qui stocke l'information dans une table
>>> que j'utilise en condition de mes requêtes Oracle). La subtilité, c'est que
>>> les dates sont stockées sous forme de nombres.
>>>
>>> J'ai donc créé une variable Date_debut avec un scope au niveau de mon lot.
>>>
>>> J'ai ensuite créé une tâche SQL qui exécute le script Oracle suivant :
>>> SELECT TO_DATE(DEB_EXC_N_2,'YYYYMMDD') AS DEB_EXC_N_2 FROM SOC
>>> J'ai paramétré le Result Set à 'Single Row' (General), et ajouté ma variable
>>> User::Date_debut en nommant le résultat DEB_EXC_N_2 (Result set).
>>> Cette tâche ne renvoie aucune erreur.
>>>
>>> Le dataflow qui s'exécute immédiatement derrière cette tâche appelle la base
>>> SQL.
>>> Schématiquement, le code utilisé est :
>>> SELECT * FROM TABLE1 T1 INNER JOIN TABLE2 T2
>>> ON T1.Code = T2.Code
>>> WHERE T1.Date_deb > ? OR T2.Date_deb > ?
>>>
>>> Dans les paramètres SQL j'ai affecté User::Date_debut à Parameter0 et
>>> Parameter1.
>>>
>>> Cette tâche non plus ne renvoie pas d'erreur, comme le reste du lot
>>> d'ailleurs.
>>>
>>> Cependant la valeur chargée devrait être le 1er janvier 2005, or je récupère
>>> les données quelle que soit la valeur de leur date.
>>>
>>> Apparemment il est possible de définir des variables pour exécuter du code,
>>> ce qui pourrait peut-être permettre de contourner cette difficulté, mais cela
>>> signifie donc une variable par requête, ce que je voudrais éviter.
>>>
>>> Est-il possible d'envisager de fonctionner ainsi, ou fais-je fausse route ?
>>>
>>> Merci de vos lumières et conseils, et bonne journée à tous.
>>>
>>>
>>>
>>>
>> pourquoi ne pas ajouter à votre modèle une table de saisie comportant
>> vos valeurs de sélection, alimenter cette table dans le flux et faire
>> une requête dessus.
>>
>> Quelque chose comme :
>>
>> Exemple :
>> CREATE TABLE T_LIMITE_TEMPS_LTP
>> (LTP_DATE_DEBUT DATETIME NOT NULL,
>> LTP_DATE_FIN DATETIME NOT NULL)
>> GO
>>
>> DELETE FROM T_LIMITE_TEMPS_LTP
>> GO
>>
>> INSERT INTO T_LIMITE_TEMPS_LTP
>> VALUES (DATEADD(day, -7, CURRENT_TIMESTAMP)), CURRENT_TIMESTAMP)
>> GO
>>
>> -- Votre requête modifiée :
>>
>> SELECT *
>> FROM TABLE1 T1
>> INNER JOIN TABLE2 T2
>> ON T1.Code = T2.Code
>> INNER JOIN T_LIMITE_TEMPS_LTP T3
>> ON T1.Date_deb > T3.LTP_DATE_DEBUT
>> OR T2.Date_deb > T3.LTP_DATE_FIN
>>
>> A +
>>
>> --
>> Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
>> Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
>> Audit, conseil, expertise, formation, modélisation, tuning, optimisation
>> ********************* http://www.datasapiens.com ***********************
>>
>
> Merci de votre réponse.
>
> J'ai déjà pensé à cela, en essayant d'éviter de modifier la base de
> production, mais je n'arrive pas à utiliser deux connexions dans une même
> requête.
> De plus, même s'il est possible de se baser sur la date en cours pour
> déduire mon information, on me demande de me baser sur la date contenue dans
> la base Oracle.
>
> - Puis-je envisager de m'entêter à (essayer d') utiliser une variable ;) ?
Difficile mais pas impossible à condition de travailler en ligne de
commande...
> - Si non, est-il obligatoire d'altérer le schéma de ma base de production,
> ou existe-t-il une façon de stocker l'information dans ma base de
> destination, et de m'en servir dans une requête portant sur une autre base ?
vous pouvez parfaitement créer une nouvelle base comportant ces
informations.
Cepanjdant sachez que selon des règles de Codd qui dictent les principes
des SGBD relationnels depuis des décennies, l'ajout d'un objet à la base
n'altère pas son fonctionnement. Heureusement d'ailleurs, sinon il nous
faudrait envisager de retourner à la gestion de fichiers pour les
données !!!
>
> Merci.
>
>
A +
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************