Bonjour à tous,
Je dois réaliser une consolidation d'une trentaine de bases issues d'une
même application, mais qui ne gèrent pas de notion d'entité.
J'ai déjà crée un lot DTS qui assure la partie récupération et
transformation des données. Le problème auquel je me heurte est celui de la
modification de la structure de certaines tables suite à une mise à jour du
logiciel.
La "méthode" que j'utilise actuellement consite à :
- Restaurer une base d'exploitation sous un autre nom
- Supprimer en masse les lignes sysobjects hébergeant les contraintes
- Générer ensuite des scripts de création de table à partir de SQLEM pour
les tables désirées
- Executer ces scripts dans une base vierge
- Ajouter manuellement (dans le fichier de script ou dans SQLEM) ma colonne
'Societe'
- Créer manuellement les PK en associant les colonnes utilisées à l'origine
et ma colonne 'Societe'
Ce qui me prend évidemment beaucoup de temps...
J'ai regardé les vues INFORMATION_SCHEMA et tenté de créer un script en
lisant ces informations, mais je bute notamment sur la suppression de la
virgule sur la ligne de la dernière colonne de chaque table (ça ne doit pas
être très méchant, mais c'est très contrariant ;)
Par ailleurs, ce traitement devra un jour pouvoir être porté en
environnement SQL2005, mais ce n'est pas une priorité.
Sachant tout cela, je voudrais connaître vos opinions sur la conduite à
tenir pour obtenir mon résultat (j'utiliserai le lot DTS pour l'alimentation
quoiqu'il arrive mais j'ai lu dernièrement que BULK INSERT pouvait
représenter une bonne alternative dans ce genre de projet).
Merci d'avance pour vos lumières et suggestions.
Excellente fin de journée à tous.
Bonjour à tous,
Je dois réaliser une consolidation d'une trentaine de bases issues d'une
même application, mais qui ne gèrent pas de notion d'entité.
J'ai déjà crée un lot DTS qui assure la partie récupération et
transformation des données. Le problème auquel je me heurte est celui de la
modification de la structure de certaines tables suite à une mise à jour du
logiciel.
La "méthode" que j'utilise actuellement consite à :
- Restaurer une base d'exploitation sous un autre nom
- Supprimer en masse les lignes sysobjects hébergeant les contraintes
- Générer ensuite des scripts de création de table à partir de SQLEM pour
les tables désirées
- Executer ces scripts dans une base vierge
- Ajouter manuellement (dans le fichier de script ou dans SQLEM) ma colonne
'Societe'
- Créer manuellement les PK en associant les colonnes utilisées à l'origine
et ma colonne 'Societe'
Ce qui me prend évidemment beaucoup de temps...
J'ai regardé les vues INFORMATION_SCHEMA et tenté de créer un script en
lisant ces informations, mais je bute notamment sur la suppression de la
virgule sur la ligne de la dernière colonne de chaque table (ça ne doit pas
être très méchant, mais c'est très contrariant ;)
Par ailleurs, ce traitement devra un jour pouvoir être porté en
environnement SQL2005, mais ce n'est pas une priorité.
Sachant tout cela, je voudrais connaître vos opinions sur la conduite à
tenir pour obtenir mon résultat (j'utiliserai le lot DTS pour l'alimentation
quoiqu'il arrive mais j'ai lu dernièrement que BULK INSERT pouvait
représenter une bonne alternative dans ce genre de projet).
Merci d'avance pour vos lumières et suggestions.
Excellente fin de journée à tous.
Bonjour à tous,
Je dois réaliser une consolidation d'une trentaine de bases issues d'une
même application, mais qui ne gèrent pas de notion d'entité.
J'ai déjà crée un lot DTS qui assure la partie récupération et
transformation des données. Le problème auquel je me heurte est celui de la
modification de la structure de certaines tables suite à une mise à jour du
logiciel.
La "méthode" que j'utilise actuellement consite à :
- Restaurer une base d'exploitation sous un autre nom
- Supprimer en masse les lignes sysobjects hébergeant les contraintes
- Générer ensuite des scripts de création de table à partir de SQLEM pour
les tables désirées
- Executer ces scripts dans une base vierge
- Ajouter manuellement (dans le fichier de script ou dans SQLEM) ma colonne
'Societe'
- Créer manuellement les PK en associant les colonnes utilisées à l'origine
et ma colonne 'Societe'
Ce qui me prend évidemment beaucoup de temps...
J'ai regardé les vues INFORMATION_SCHEMA et tenté de créer un script en
lisant ces informations, mais je bute notamment sur la suppression de la
virgule sur la ligne de la dernière colonne de chaque table (ça ne doit pas
être très méchant, mais c'est très contrariant ;)
Par ailleurs, ce traitement devra un jour pouvoir être porté en
environnement SQL2005, mais ce n'est pas une priorité.
Sachant tout cela, je voudrais connaître vos opinions sur la conduite à
tenir pour obtenir mon résultat (j'utiliserai le lot DTS pour l'alimentation
quoiqu'il arrive mais j'ai lu dernièrement que BULK INSERT pouvait
représenter une bonne alternative dans ce genre de projet).
Merci d'avance pour vos lumières et suggestions.
Excellente fin de journée à tous.
Bonjour,
OokieDookie a écrit :
> Bonjour à tous,
>
> Je dois réaliser une consolidation d'une trentaine de bases issues d'une
> même application, mais qui ne gèrent pas de notion d'entité.
>
> J'ai déjà crée un lot DTS qui assure la partie récupération et
> transformation des données. Le problème auquel je me heurte est celui de la
> modification de la structure de certaines tables suite à une mise à jour du
> logiciel.
>
> La "méthode" que j'utilise actuellement consite à :
> - Restaurer une base d'exploitation sous un autre nom
> - Supprimer en masse les lignes sysobjects hébergeant les contraintes
Monstrueux !!! Ce n'est pas en bidouillant les tables systèmes que vous
ferez sauter les contraintes. Vous risquez simplement de rendre votre
base de données totalement incohérente. De plus la modification directe
des tables système est totalement impossible en version 2005 (et
heureusement d'ailleurs lorsque l'on lit de telles chose !)
> - Générer ensuite des scripts de création de table à partir de SQLEM pour
> les tables désirées
> - Executer ces scripts dans une base vierge
> - Ajouter manuellement (dans le fichier de script ou dans SQLEM) ma colonne
> 'Societe'
> - Créer manuellement les PK en associant les colonnes utilisées à l'origine
> et ma colonne 'Societe'
>
> Ce qui me prend évidemment beaucoup de temps...
> J'ai regardé les vues INFORMATION_SCHEMA et tenté de créer un script en
> lisant ces informations, mais je bute notamment sur la suppression de la
> virgule sur la ligne de la dernière colonne de chaque table (ça ne doit pas
> être très méchant, mais c'est très contrariant ;)
Il suffit d'utiliser un outil prévu pour cela comme Power AMC (ex AMC
Designer) capable de faire de la rétro ingéniérie. Il vous constituera à
partir de la base un MPD et si vous le désirez un MCD que vous pourrez
modifier à souhait. Dès lors vous obtiendrez un nouveau script de
création de la base de données, ce qui vous demandera en tout et pour
tout 10 minutes de travail !
>
> Par ailleurs, ce traitement devra un jour pouvoir être porté en
> environnement SQL2005, mais ce n'est pas une priorité.
>
> Sachant tout cela, je voudrais connaître vos opinions sur la conduite à
> tenir pour obtenir mon résultat (j'utiliserai le lot DTS pour l'alimentation
> quoiqu'il arrive mais j'ai lu dernièrement que BULK INSERT pouvait
> représenter une bonne alternative dans ce genre de projet).
il serait plus intelligent de se pencher sur une réplication, en
étudiant la réplication transactionnelle ou en cliché et en évitant le
réplication de fusion, peu adaptée à votre cas.
En quelques minutes vous serez capable de mettre en ouvre votre flux de
données montant et votre base de consolidation pourra être à jour avec
l'intervalle de latence désiré (une seconde, 5 minutes, 3 heures, une
journée...).
>
> Merci d'avance pour vos lumières et suggestions.
> Excellente fin de journée à tous.
Il serait peut être temps de vous pencher sur une solide formation
d'administration de bases de donénes SQL Server !
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 ***********************
Bonjour,
OokieDookie a écrit :
> Bonjour à tous,
>
> Je dois réaliser une consolidation d'une trentaine de bases issues d'une
> même application, mais qui ne gèrent pas de notion d'entité.
>
> J'ai déjà crée un lot DTS qui assure la partie récupération et
> transformation des données. Le problème auquel je me heurte est celui de la
> modification de la structure de certaines tables suite à une mise à jour du
> logiciel.
>
> La "méthode" que j'utilise actuellement consite à :
> - Restaurer une base d'exploitation sous un autre nom
> - Supprimer en masse les lignes sysobjects hébergeant les contraintes
Monstrueux !!! Ce n'est pas en bidouillant les tables systèmes que vous
ferez sauter les contraintes. Vous risquez simplement de rendre votre
base de données totalement incohérente. De plus la modification directe
des tables système est totalement impossible en version 2005 (et
heureusement d'ailleurs lorsque l'on lit de telles chose !)
> - Générer ensuite des scripts de création de table à partir de SQLEM pour
> les tables désirées
> - Executer ces scripts dans une base vierge
> - Ajouter manuellement (dans le fichier de script ou dans SQLEM) ma colonne
> 'Societe'
> - Créer manuellement les PK en associant les colonnes utilisées à l'origine
> et ma colonne 'Societe'
>
> Ce qui me prend évidemment beaucoup de temps...
> J'ai regardé les vues INFORMATION_SCHEMA et tenté de créer un script en
> lisant ces informations, mais je bute notamment sur la suppression de la
> virgule sur la ligne de la dernière colonne de chaque table (ça ne doit pas
> être très méchant, mais c'est très contrariant ;)
Il suffit d'utiliser un outil prévu pour cela comme Power AMC (ex AMC
Designer) capable de faire de la rétro ingéniérie. Il vous constituera à
partir de la base un MPD et si vous le désirez un MCD que vous pourrez
modifier à souhait. Dès lors vous obtiendrez un nouveau script de
création de la base de données, ce qui vous demandera en tout et pour
tout 10 minutes de travail !
>
> Par ailleurs, ce traitement devra un jour pouvoir être porté en
> environnement SQL2005, mais ce n'est pas une priorité.
>
> Sachant tout cela, je voudrais connaître vos opinions sur la conduite à
> tenir pour obtenir mon résultat (j'utiliserai le lot DTS pour l'alimentation
> quoiqu'il arrive mais j'ai lu dernièrement que BULK INSERT pouvait
> représenter une bonne alternative dans ce genre de projet).
il serait plus intelligent de se pencher sur une réplication, en
étudiant la réplication transactionnelle ou en cliché et en évitant le
réplication de fusion, peu adaptée à votre cas.
En quelques minutes vous serez capable de mettre en ouvre votre flux de
données montant et votre base de consolidation pourra être à jour avec
l'intervalle de latence désiré (une seconde, 5 minutes, 3 heures, une
journée...).
>
> Merci d'avance pour vos lumières et suggestions.
> Excellente fin de journée à tous.
Il serait peut être temps de vous pencher sur une solide formation
d'administration de bases de donénes SQL Server !
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 ***********************
Bonjour,
OokieDookie a écrit :
> Bonjour à tous,
>
> Je dois réaliser une consolidation d'une trentaine de bases issues d'une
> même application, mais qui ne gèrent pas de notion d'entité.
>
> J'ai déjà crée un lot DTS qui assure la partie récupération et
> transformation des données. Le problème auquel je me heurte est celui de la
> modification de la structure de certaines tables suite à une mise à jour du
> logiciel.
>
> La "méthode" que j'utilise actuellement consite à :
> - Restaurer une base d'exploitation sous un autre nom
> - Supprimer en masse les lignes sysobjects hébergeant les contraintes
Monstrueux !!! Ce n'est pas en bidouillant les tables systèmes que vous
ferez sauter les contraintes. Vous risquez simplement de rendre votre
base de données totalement incohérente. De plus la modification directe
des tables système est totalement impossible en version 2005 (et
heureusement d'ailleurs lorsque l'on lit de telles chose !)
> - Générer ensuite des scripts de création de table à partir de SQLEM pour
> les tables désirées
> - Executer ces scripts dans une base vierge
> - Ajouter manuellement (dans le fichier de script ou dans SQLEM) ma colonne
> 'Societe'
> - Créer manuellement les PK en associant les colonnes utilisées à l'origine
> et ma colonne 'Societe'
>
> Ce qui me prend évidemment beaucoup de temps...
> J'ai regardé les vues INFORMATION_SCHEMA et tenté de créer un script en
> lisant ces informations, mais je bute notamment sur la suppression de la
> virgule sur la ligne de la dernière colonne de chaque table (ça ne doit pas
> être très méchant, mais c'est très contrariant ;)
Il suffit d'utiliser un outil prévu pour cela comme Power AMC (ex AMC
Designer) capable de faire de la rétro ingéniérie. Il vous constituera à
partir de la base un MPD et si vous le désirez un MCD que vous pourrez
modifier à souhait. Dès lors vous obtiendrez un nouveau script de
création de la base de données, ce qui vous demandera en tout et pour
tout 10 minutes de travail !
>
> Par ailleurs, ce traitement devra un jour pouvoir être porté en
> environnement SQL2005, mais ce n'est pas une priorité.
>
> Sachant tout cela, je voudrais connaître vos opinions sur la conduite à
> tenir pour obtenir mon résultat (j'utiliserai le lot DTS pour l'alimentation
> quoiqu'il arrive mais j'ai lu dernièrement que BULK INSERT pouvait
> représenter une bonne alternative dans ce genre de projet).
il serait plus intelligent de se pencher sur une réplication, en
étudiant la réplication transactionnelle ou en cliché et en évitant le
réplication de fusion, peu adaptée à votre cas.
En quelques minutes vous serez capable de mettre en ouvre votre flux de
données montant et votre base de consolidation pourra être à jour avec
l'intervalle de latence désiré (une seconde, 5 minutes, 3 heures, une
journée...).
>
> Merci d'avance pour vos lumières et suggestions.
> Excellente fin de journée à tous.
Il serait peut être temps de vous pencher sur une solide formation
d'administration de bases de donénes SQL Server !
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 ***********************
Bonjour,
Merci beaucoup pour vos indications. Je me doutais bien que je me ferais
remonter les bretelles en posant cette question, mais comme vous l'avez
constaté, mon profil est bien éloigné d'un dba (consultant logiciel /
développeur de requêtes sur le tas est plus adapté ;)
Peut-être me pardonnerez-vous cet affront au bon sens si je vous dis que
désormais (au prix de quelques jours de réflexion intense), je constitue la
structure de la base consolidée et son alimentation par le biais de scripts
basés sur les vues INFORMATION_SCHEMA d'une base de production n'ayant pas
bénéficié de mon traitement "à la hache" ;). J'ai en effet contourné mon
problème de "dernière colonne" avec un test sur ORDINAL_POSITION dans un
curseur, et ça marche plutôt bien (20 secondes seulement et ça marche avec
deux versions du produit à tous les coups) et abandonné l'utilisation de lots
dans le même temps.
Effectivement je ne rechignerai pas à suivre une formation adaptée pour
éviter mes bricolages, et pour tout dire je suis en attente...
Excellente journée.
"Fred BROUARD" a écrit :Bonjour,
OokieDookie a écrit :Bonjour à tous,
Je dois réaliser une consolidation d'une trentaine de bases issues d'une
même application, mais qui ne gèrent pas de notion d'entité.
J'ai déjà crée un lot DTS qui assure la partie récupération et
transformation des données. Le problème auquel je me heurte est celui de la
modification de la structure de certaines tables suite à une mise à jour du
logiciel.
La "méthode" que j'utilise actuellement consite à :
- Restaurer une base d'exploitation sous un autre nom
- Supprimer en masse les lignes sysobjects hébergeant les contraintes
Monstrueux !!! Ce n'est pas en bidouillant les tables systèmes que vous
ferez sauter les contraintes. Vous risquez simplement de rendre votre
base de données totalement incohérente. De plus la modification directe
des tables système est totalement impossible en version 2005 (et
heureusement d'ailleurs lorsque l'on lit de telles chose !)- Générer ensuite des scripts de création de table à partir de SQLEM pour
les tables désirées
- Executer ces scripts dans une base vierge
- Ajouter manuellement (dans le fichier de script ou dans SQLEM) ma colonne
'Societe'
- Créer manuellement les PK en associant les colonnes utilisées à l'origine
et ma colonne 'Societe'
Ce qui me prend évidemment beaucoup de temps...
J'ai regardé les vues INFORMATION_SCHEMA et tenté de créer un script en
lisant ces informations, mais je bute notamment sur la suppression de la
virgule sur la ligne de la dernière colonne de chaque table (ça ne doit pas
être très méchant, mais c'est très contrariant ;)
Il suffit d'utiliser un outil prévu pour cela comme Power AMC (ex AMC
Designer) capable de faire de la rétro ingéniérie. Il vous constituera à
partir de la base un MPD et si vous le désirez un MCD que vous pourrez
modifier à souhait. Dès lors vous obtiendrez un nouveau script de
création de la base de données, ce qui vous demandera en tout et pour
tout 10 minutes de travail !Par ailleurs, ce traitement devra un jour pouvoir être porté en
environnement SQL2005, mais ce n'est pas une priorité.
Sachant tout cela, je voudrais connaître vos opinions sur la conduite à
tenir pour obtenir mon résultat (j'utiliserai le lot DTS pour l'alimentation
quoiqu'il arrive mais j'ai lu dernièrement que BULK INSERT pouvait
représenter une bonne alternative dans ce genre de projet).
il serait plus intelligent de se pencher sur une réplication, en
étudiant la réplication transactionnelle ou en cliché et en évitant le
réplication de fusion, peu adaptée à votre cas.
En quelques minutes vous serez capable de mettre en ouvre votre flux de
données montant et votre base de consolidation pourra être à jour avec
l'intervalle de latence désiré (une seconde, 5 minutes, 3 heures, une
journée...).Merci d'avance pour vos lumières et suggestions.
Excellente fin de journée à tous.
Il serait peut être temps de vous pencher sur une solide formation
d'administration de bases de donénes SQL Server !
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 ***********************
Bonjour,
Merci beaucoup pour vos indications. Je me doutais bien que je me ferais
remonter les bretelles en posant cette question, mais comme vous l'avez
constaté, mon profil est bien éloigné d'un dba (consultant logiciel /
développeur de requêtes sur le tas est plus adapté ;)
Peut-être me pardonnerez-vous cet affront au bon sens si je vous dis que
désormais (au prix de quelques jours de réflexion intense), je constitue la
structure de la base consolidée et son alimentation par le biais de scripts
basés sur les vues INFORMATION_SCHEMA d'une base de production n'ayant pas
bénéficié de mon traitement "à la hache" ;). J'ai en effet contourné mon
problème de "dernière colonne" avec un test sur ORDINAL_POSITION dans un
curseur, et ça marche plutôt bien (20 secondes seulement et ça marche avec
deux versions du produit à tous les coups) et abandonné l'utilisation de lots
dans le même temps.
Effectivement je ne rechignerai pas à suivre une formation adaptée pour
éviter mes bricolages, et pour tout dire je suis en attente...
Excellente journée.
"Fred BROUARD" a écrit :
Bonjour,
OokieDookie a écrit :
Bonjour à tous,
Je dois réaliser une consolidation d'une trentaine de bases issues d'une
même application, mais qui ne gèrent pas de notion d'entité.
J'ai déjà crée un lot DTS qui assure la partie récupération et
transformation des données. Le problème auquel je me heurte est celui de la
modification de la structure de certaines tables suite à une mise à jour du
logiciel.
La "méthode" que j'utilise actuellement consite à :
- Restaurer une base d'exploitation sous un autre nom
- Supprimer en masse les lignes sysobjects hébergeant les contraintes
Monstrueux !!! Ce n'est pas en bidouillant les tables systèmes que vous
ferez sauter les contraintes. Vous risquez simplement de rendre votre
base de données totalement incohérente. De plus la modification directe
des tables système est totalement impossible en version 2005 (et
heureusement d'ailleurs lorsque l'on lit de telles chose !)
- Générer ensuite des scripts de création de table à partir de SQLEM pour
les tables désirées
- Executer ces scripts dans une base vierge
- Ajouter manuellement (dans le fichier de script ou dans SQLEM) ma colonne
'Societe'
- Créer manuellement les PK en associant les colonnes utilisées à l'origine
et ma colonne 'Societe'
Ce qui me prend évidemment beaucoup de temps...
J'ai regardé les vues INFORMATION_SCHEMA et tenté de créer un script en
lisant ces informations, mais je bute notamment sur la suppression de la
virgule sur la ligne de la dernière colonne de chaque table (ça ne doit pas
être très méchant, mais c'est très contrariant ;)
Il suffit d'utiliser un outil prévu pour cela comme Power AMC (ex AMC
Designer) capable de faire de la rétro ingéniérie. Il vous constituera à
partir de la base un MPD et si vous le désirez un MCD que vous pourrez
modifier à souhait. Dès lors vous obtiendrez un nouveau script de
création de la base de données, ce qui vous demandera en tout et pour
tout 10 minutes de travail !
Par ailleurs, ce traitement devra un jour pouvoir être porté en
environnement SQL2005, mais ce n'est pas une priorité.
Sachant tout cela, je voudrais connaître vos opinions sur la conduite à
tenir pour obtenir mon résultat (j'utiliserai le lot DTS pour l'alimentation
quoiqu'il arrive mais j'ai lu dernièrement que BULK INSERT pouvait
représenter une bonne alternative dans ce genre de projet).
il serait plus intelligent de se pencher sur une réplication, en
étudiant la réplication transactionnelle ou en cliché et en évitant le
réplication de fusion, peu adaptée à votre cas.
En quelques minutes vous serez capable de mettre en ouvre votre flux de
données montant et votre base de consolidation pourra être à jour avec
l'intervalle de latence désiré (une seconde, 5 minutes, 3 heures, une
journée...).
Merci d'avance pour vos lumières et suggestions.
Excellente fin de journée à tous.
Il serait peut être temps de vous pencher sur une solide formation
d'administration de bases de donénes SQL Server !
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 ***********************
Bonjour,
Merci beaucoup pour vos indications. Je me doutais bien que je me ferais
remonter les bretelles en posant cette question, mais comme vous l'avez
constaté, mon profil est bien éloigné d'un dba (consultant logiciel /
développeur de requêtes sur le tas est plus adapté ;)
Peut-être me pardonnerez-vous cet affront au bon sens si je vous dis que
désormais (au prix de quelques jours de réflexion intense), je constitue la
structure de la base consolidée et son alimentation par le biais de scripts
basés sur les vues INFORMATION_SCHEMA d'une base de production n'ayant pas
bénéficié de mon traitement "à la hache" ;). J'ai en effet contourné mon
problème de "dernière colonne" avec un test sur ORDINAL_POSITION dans un
curseur, et ça marche plutôt bien (20 secondes seulement et ça marche avec
deux versions du produit à tous les coups) et abandonné l'utilisation de lots
dans le même temps.
Effectivement je ne rechignerai pas à suivre une formation adaptée pour
éviter mes bricolages, et pour tout dire je suis en attente...
Excellente journée.
"Fred BROUARD" a écrit :Bonjour,
OokieDookie a écrit :Bonjour à tous,
Je dois réaliser une consolidation d'une trentaine de bases issues d'une
même application, mais qui ne gèrent pas de notion d'entité.
J'ai déjà crée un lot DTS qui assure la partie récupération et
transformation des données. Le problème auquel je me heurte est celui de la
modification de la structure de certaines tables suite à une mise à jour du
logiciel.
La "méthode" que j'utilise actuellement consite à :
- Restaurer une base d'exploitation sous un autre nom
- Supprimer en masse les lignes sysobjects hébergeant les contraintes
Monstrueux !!! Ce n'est pas en bidouillant les tables systèmes que vous
ferez sauter les contraintes. Vous risquez simplement de rendre votre
base de données totalement incohérente. De plus la modification directe
des tables système est totalement impossible en version 2005 (et
heureusement d'ailleurs lorsque l'on lit de telles chose !)- Générer ensuite des scripts de création de table à partir de SQLEM pour
les tables désirées
- Executer ces scripts dans une base vierge
- Ajouter manuellement (dans le fichier de script ou dans SQLEM) ma colonne
'Societe'
- Créer manuellement les PK en associant les colonnes utilisées à l'origine
et ma colonne 'Societe'
Ce qui me prend évidemment beaucoup de temps...
J'ai regardé les vues INFORMATION_SCHEMA et tenté de créer un script en
lisant ces informations, mais je bute notamment sur la suppression de la
virgule sur la ligne de la dernière colonne de chaque table (ça ne doit pas
être très méchant, mais c'est très contrariant ;)
Il suffit d'utiliser un outil prévu pour cela comme Power AMC (ex AMC
Designer) capable de faire de la rétro ingéniérie. Il vous constituera à
partir de la base un MPD et si vous le désirez un MCD que vous pourrez
modifier à souhait. Dès lors vous obtiendrez un nouveau script de
création de la base de données, ce qui vous demandera en tout et pour
tout 10 minutes de travail !Par ailleurs, ce traitement devra un jour pouvoir être porté en
environnement SQL2005, mais ce n'est pas une priorité.
Sachant tout cela, je voudrais connaître vos opinions sur la conduite à
tenir pour obtenir mon résultat (j'utiliserai le lot DTS pour l'alimentation
quoiqu'il arrive mais j'ai lu dernièrement que BULK INSERT pouvait
représenter une bonne alternative dans ce genre de projet).
il serait plus intelligent de se pencher sur une réplication, en
étudiant la réplication transactionnelle ou en cliché et en évitant le
réplication de fusion, peu adaptée à votre cas.
En quelques minutes vous serez capable de mettre en ouvre votre flux de
données montant et votre base de consolidation pourra être à jour avec
l'intervalle de latence désiré (une seconde, 5 minutes, 3 heures, une
journée...).Merci d'avance pour vos lumières et suggestions.
Excellente fin de journée à tous.
Il serait peut être temps de vous pencher sur une solide formation
d'administration de bases de donénes SQL Server !
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,
>
> Merci beaucoup pour vos indications. Je me doutais bien que je me ferais
> remonter les bretelles en posant cette question, mais comme vous l'avez
> constaté, mon profil est bien éloigné d'un dba (consultant logiciel /
> développeur de requêtes sur le tas est plus adapté ;)
>
> Peut-être me pardonnerez-vous cet affront au bon sens si je vous dis que
> désormais (au prix de quelques jours de réflexion intense), je constitue la
> structure de la base consolidée et son alimentation par le biais de scripts
> basés sur les vues INFORMATION_SCHEMA d'une base de production n'ayant pas
> bénéficié de mon traitement "à la hache" ;). J'ai en effet contourné mon
> problème de "dernière colonne" avec un test sur ORDINAL_POSITION dans un
> curseur, et ça marche plutôt bien (20 secondes seulement et ça marche avec
> deux versions du produit à tous les coups) et abandonné l'utilisation de lots
> dans le même temps.
Méfiez vous de l'ORDINAL_POSITION. Des bases identiques peuvent avoir
des diffences au niveau de cet élément. Il vaut donc mieux toujours se
base sur les noms et jamais sur les éléments ordinaux. La notion d'ordre
est absoluement inconnues des SGBDR dont la logique est ensembliste. Cet
abominable ORDINAL_POSITION contrevient à cette notion et n'est donc pas
sans danger !
A +
>
> Effectivement je ne rechignerai pas à suivre une formation adaptée pour
> éviter mes bricolages, et pour tout dire je suis en attente...
>
> Excellente journée.
>
> "Fred BROUARD" a écrit :
>
>> Bonjour,
>>
>> OokieDookie a écrit :
>>> Bonjour à tous,
>>>
>>> Je dois réaliser une consolidation d'une trentaine de bases issues d'une
>>> même application, mais qui ne gèrent pas de notion d'entité.
>>>
>>> J'ai déjà crée un lot DTS qui assure la partie récupération et
>>> transformation des données. Le problème auquel je me heurte est celui de la
>>> modification de la structure de certaines tables suite à une mise à jour du
>>> logiciel.
>>>
>>> La "méthode" que j'utilise actuellement consite à :
>>> - Restaurer une base d'exploitation sous un autre nom
>>> - Supprimer en masse les lignes sysobjects hébergeant les contraintes
>> Monstrueux !!! Ce n'est pas en bidouillant les tables systèmes que vous
>> ferez sauter les contraintes. Vous risquez simplement de rendre votre
>> base de données totalement incohérente. De plus la modification directe
>> des tables système est totalement impossible en version 2005 (et
>> heureusement d'ailleurs lorsque l'on lit de telles chose !)
>>
>>> - Générer ensuite des scripts de création de table à partir de SQLEM pour
>>> les tables désirées
>>> - Executer ces scripts dans une base vierge
>>> - Ajouter manuellement (dans le fichier de script ou dans SQLEM) ma colonne
>>> 'Societe'
>>> - Créer manuellement les PK en associant les colonnes utilisées à l'origine
>>> et ma colonne 'Societe'
>>>
>>> Ce qui me prend évidemment beaucoup de temps...
>>> J'ai regardé les vues INFORMATION_SCHEMA et tenté de créer un script en
>>> lisant ces informations, mais je bute notamment sur la suppression de la
>>> virgule sur la ligne de la dernière colonne de chaque table (ça ne doit pas
>>> être très méchant, mais c'est très contrariant ;)
>> Il suffit d'utiliser un outil prévu pour cela comme Power AMC (ex AMC
>> Designer) capable de faire de la rétro ingéniérie. Il vous constituera à
>> partir de la base un MPD et si vous le désirez un MCD que vous pourrez
>> modifier à souhait. Dès lors vous obtiendrez un nouveau script de
>> création de la base de données, ce qui vous demandera en tout et pour
>> tout 10 minutes de travail !
>>
>>
>>> Par ailleurs, ce traitement devra un jour pouvoir être porté en
>>> environnement SQL2005, mais ce n'est pas une priorité.
>>>
>>> Sachant tout cela, je voudrais connaître vos opinions sur la conduite à
>>> tenir pour obtenir mon résultat (j'utiliserai le lot DTS pour l'alimentation
>>> quoiqu'il arrive mais j'ai lu dernièrement que BULK INSERT pouvait
>>> représenter une bonne alternative dans ce genre de projet).
>> il serait plus intelligent de se pencher sur une réplication, en
>> étudiant la réplication transactionnelle ou en cliché et en évitant le
>> réplication de fusion, peu adaptée à votre cas.
>>
>> En quelques minutes vous serez capable de mettre en ouvre votre flux de
>> données montant et votre base de consolidation pourra être à jour avec
>> l'intervalle de latence désiré (une seconde, 5 minutes, 3 heures, une
>> journée...).
>>
>>> Merci d'avance pour vos lumières et suggestions.
>>> Excellente fin de journée à tous.
>> Il serait peut être temps de vous pencher sur une solide formation
>> d'administration de bases de donénes SQL Server !
>>
>> 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 ***********************
>>
--
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,
>
> Merci beaucoup pour vos indications. Je me doutais bien que je me ferais
> remonter les bretelles en posant cette question, mais comme vous l'avez
> constaté, mon profil est bien éloigné d'un dba (consultant logiciel /
> développeur de requêtes sur le tas est plus adapté ;)
>
> Peut-être me pardonnerez-vous cet affront au bon sens si je vous dis que
> désormais (au prix de quelques jours de réflexion intense), je constitue la
> structure de la base consolidée et son alimentation par le biais de scripts
> basés sur les vues INFORMATION_SCHEMA d'une base de production n'ayant pas
> bénéficié de mon traitement "à la hache" ;). J'ai en effet contourné mon
> problème de "dernière colonne" avec un test sur ORDINAL_POSITION dans un
> curseur, et ça marche plutôt bien (20 secondes seulement et ça marche avec
> deux versions du produit à tous les coups) et abandonné l'utilisation de lots
> dans le même temps.
Méfiez vous de l'ORDINAL_POSITION. Des bases identiques peuvent avoir
des diffences au niveau de cet élément. Il vaut donc mieux toujours se
base sur les noms et jamais sur les éléments ordinaux. La notion d'ordre
est absoluement inconnues des SGBDR dont la logique est ensembliste. Cet
abominable ORDINAL_POSITION contrevient à cette notion et n'est donc pas
sans danger !
A +
>
> Effectivement je ne rechignerai pas à suivre une formation adaptée pour
> éviter mes bricolages, et pour tout dire je suis en attente...
>
> Excellente journée.
>
> "Fred BROUARD" a écrit :
>
>> Bonjour,
>>
>> OokieDookie a écrit :
>>> Bonjour à tous,
>>>
>>> Je dois réaliser une consolidation d'une trentaine de bases issues d'une
>>> même application, mais qui ne gèrent pas de notion d'entité.
>>>
>>> J'ai déjà crée un lot DTS qui assure la partie récupération et
>>> transformation des données. Le problème auquel je me heurte est celui de la
>>> modification de la structure de certaines tables suite à une mise à jour du
>>> logiciel.
>>>
>>> La "méthode" que j'utilise actuellement consite à :
>>> - Restaurer une base d'exploitation sous un autre nom
>>> - Supprimer en masse les lignes sysobjects hébergeant les contraintes
>> Monstrueux !!! Ce n'est pas en bidouillant les tables systèmes que vous
>> ferez sauter les contraintes. Vous risquez simplement de rendre votre
>> base de données totalement incohérente. De plus la modification directe
>> des tables système est totalement impossible en version 2005 (et
>> heureusement d'ailleurs lorsque l'on lit de telles chose !)
>>
>>> - Générer ensuite des scripts de création de table à partir de SQLEM pour
>>> les tables désirées
>>> - Executer ces scripts dans une base vierge
>>> - Ajouter manuellement (dans le fichier de script ou dans SQLEM) ma colonne
>>> 'Societe'
>>> - Créer manuellement les PK en associant les colonnes utilisées à l'origine
>>> et ma colonne 'Societe'
>>>
>>> Ce qui me prend évidemment beaucoup de temps...
>>> J'ai regardé les vues INFORMATION_SCHEMA et tenté de créer un script en
>>> lisant ces informations, mais je bute notamment sur la suppression de la
>>> virgule sur la ligne de la dernière colonne de chaque table (ça ne doit pas
>>> être très méchant, mais c'est très contrariant ;)
>> Il suffit d'utiliser un outil prévu pour cela comme Power AMC (ex AMC
>> Designer) capable de faire de la rétro ingéniérie. Il vous constituera à
>> partir de la base un MPD et si vous le désirez un MCD que vous pourrez
>> modifier à souhait. Dès lors vous obtiendrez un nouveau script de
>> création de la base de données, ce qui vous demandera en tout et pour
>> tout 10 minutes de travail !
>>
>>
>>> Par ailleurs, ce traitement devra un jour pouvoir être porté en
>>> environnement SQL2005, mais ce n'est pas une priorité.
>>>
>>> Sachant tout cela, je voudrais connaître vos opinions sur la conduite à
>>> tenir pour obtenir mon résultat (j'utiliserai le lot DTS pour l'alimentation
>>> quoiqu'il arrive mais j'ai lu dernièrement que BULK INSERT pouvait
>>> représenter une bonne alternative dans ce genre de projet).
>> il serait plus intelligent de se pencher sur une réplication, en
>> étudiant la réplication transactionnelle ou en cliché et en évitant le
>> réplication de fusion, peu adaptée à votre cas.
>>
>> En quelques minutes vous serez capable de mettre en ouvre votre flux de
>> données montant et votre base de consolidation pourra être à jour avec
>> l'intervalle de latence désiré (une seconde, 5 minutes, 3 heures, une
>> journée...).
>>
>>> Merci d'avance pour vos lumières et suggestions.
>>> Excellente fin de journée à tous.
>> Il serait peut être temps de vous pencher sur une solide formation
>> d'administration de bases de donénes SQL Server !
>>
>> 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 ***********************
>>
--
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,
>
> Merci beaucoup pour vos indications. Je me doutais bien que je me ferais
> remonter les bretelles en posant cette question, mais comme vous l'avez
> constaté, mon profil est bien éloigné d'un dba (consultant logiciel /
> développeur de requêtes sur le tas est plus adapté ;)
>
> Peut-être me pardonnerez-vous cet affront au bon sens si je vous dis que
> désormais (au prix de quelques jours de réflexion intense), je constitue la
> structure de la base consolidée et son alimentation par le biais de scripts
> basés sur les vues INFORMATION_SCHEMA d'une base de production n'ayant pas
> bénéficié de mon traitement "à la hache" ;). J'ai en effet contourné mon
> problème de "dernière colonne" avec un test sur ORDINAL_POSITION dans un
> curseur, et ça marche plutôt bien (20 secondes seulement et ça marche avec
> deux versions du produit à tous les coups) et abandonné l'utilisation de lots
> dans le même temps.
Méfiez vous de l'ORDINAL_POSITION. Des bases identiques peuvent avoir
des diffences au niveau de cet élément. Il vaut donc mieux toujours se
base sur les noms et jamais sur les éléments ordinaux. La notion d'ordre
est absoluement inconnues des SGBDR dont la logique est ensembliste. Cet
abominable ORDINAL_POSITION contrevient à cette notion et n'est donc pas
sans danger !
A +
>
> Effectivement je ne rechignerai pas à suivre une formation adaptée pour
> éviter mes bricolages, et pour tout dire je suis en attente...
>
> Excellente journée.
>
> "Fred BROUARD" a écrit :
>
>> Bonjour,
>>
>> OokieDookie a écrit :
>>> Bonjour à tous,
>>>
>>> Je dois réaliser une consolidation d'une trentaine de bases issues d'une
>>> même application, mais qui ne gèrent pas de notion d'entité.
>>>
>>> J'ai déjà crée un lot DTS qui assure la partie récupération et
>>> transformation des données. Le problème auquel je me heurte est celui de la
>>> modification de la structure de certaines tables suite à une mise à jour du
>>> logiciel.
>>>
>>> La "méthode" que j'utilise actuellement consite à :
>>> - Restaurer une base d'exploitation sous un autre nom
>>> - Supprimer en masse les lignes sysobjects hébergeant les contraintes
>> Monstrueux !!! Ce n'est pas en bidouillant les tables systèmes que vous
>> ferez sauter les contraintes. Vous risquez simplement de rendre votre
>> base de données totalement incohérente. De plus la modification directe
>> des tables système est totalement impossible en version 2005 (et
>> heureusement d'ailleurs lorsque l'on lit de telles chose !)
>>
>>> - Générer ensuite des scripts de création de table à partir de SQLEM pour
>>> les tables désirées
>>> - Executer ces scripts dans une base vierge
>>> - Ajouter manuellement (dans le fichier de script ou dans SQLEM) ma colonne
>>> 'Societe'
>>> - Créer manuellement les PK en associant les colonnes utilisées à l'origine
>>> et ma colonne 'Societe'
>>>
>>> Ce qui me prend évidemment beaucoup de temps...
>>> J'ai regardé les vues INFORMATION_SCHEMA et tenté de créer un script en
>>> lisant ces informations, mais je bute notamment sur la suppression de la
>>> virgule sur la ligne de la dernière colonne de chaque table (ça ne doit pas
>>> être très méchant, mais c'est très contrariant ;)
>> Il suffit d'utiliser un outil prévu pour cela comme Power AMC (ex AMC
>> Designer) capable de faire de la rétro ingéniérie. Il vous constituera à
>> partir de la base un MPD et si vous le désirez un MCD que vous pourrez
>> modifier à souhait. Dès lors vous obtiendrez un nouveau script de
>> création de la base de données, ce qui vous demandera en tout et pour
>> tout 10 minutes de travail !
>>
>>
>>> Par ailleurs, ce traitement devra un jour pouvoir être porté en
>>> environnement SQL2005, mais ce n'est pas une priorité.
>>>
>>> Sachant tout cela, je voudrais connaître vos opinions sur la conduite à
>>> tenir pour obtenir mon résultat (j'utiliserai le lot DTS pour l'alimentation
>>> quoiqu'il arrive mais j'ai lu dernièrement que BULK INSERT pouvait
>>> représenter une bonne alternative dans ce genre de projet).
>> il serait plus intelligent de se pencher sur une réplication, en
>> étudiant la réplication transactionnelle ou en cliché et en évitant le
>> réplication de fusion, peu adaptée à votre cas.
>>
>> En quelques minutes vous serez capable de mettre en ouvre votre flux de
>> données montant et votre base de consolidation pourra être à jour avec
>> l'intervalle de latence désiré (une seconde, 5 minutes, 3 heures, une
>> journée...).
>>
>>> Merci d'avance pour vos lumières et suggestions.
>>> Excellente fin de journée à tous.
>> Il serait peut être temps de vous pencher sur une solide formation
>> d'administration de bases de donénes SQL Server !
>>
>> 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 ***********************
>>
--
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 ces précisions.
J'abuse de votre disponibilité :
Peut-on affirmer cependant que dans le cadre de mon périmètre cela n'est pas
un problème, dans le sens ou je me base sur cette valeur pour constater si
elle est égal au maximum pour une table donnée ?
Ceci ayant pour effet d'inhiber les virgules finales dans le curseur qui
crée les instructions suivantes :
CREATE TABLE MaTable (Societe, Champ1, ..., ChampN [ici])
et
INSERT INTO Base1..MaTable (Societe, Champ1, ..., ChampN[ici]) SELECT
'Toto', Champ1,..., ChampN[et ici] FROM Base2..MaTable)
Car travailler avec les noms ne me semble pas facile dans mon cas, il
faudrait que j'arrive à référencer un nom par table pour mon test. A moins
que vous n'ayiez une astuce à me soumettre ?
Merci encore.
"Fred BROUARD" a écrit :OokieDookie a écrit :Bonjour,
Merci beaucoup pour vos indications. Je me doutais bien que je me ferais
remonter les bretelles en posant cette question, mais comme vous l'avez
constaté, mon profil est bien éloigné d'un dba (consultant logiciel /
développeur de requêtes sur le tas est plus adapté ;)
Peut-être me pardonnerez-vous cet affront au bon sens si je vous dis que
désormais (au prix de quelques jours de réflexion intense), je constitue la
structure de la base consolidée et son alimentation par le biais de scripts
basés sur les vues INFORMATION_SCHEMA d'une base de production n'ayant pas
bénéficié de mon traitement "à la hache" ;). J'ai en effet contourné mon
problème de "dernière colonne" avec un test sur ORDINAL_POSITION dans un
curseur, et ça marche plutôt bien (20 secondes seulement et ça marche avec
deux versions du produit à tous les coups) et abandonné l'utilisation de lots
dans le même temps.
Méfiez vous de l'ORDINAL_POSITION. Des bases identiques peuvent avoir
des diffences au niveau de cet élément. Il vaut donc mieux toujours se
base sur les noms et jamais sur les éléments ordinaux. La notion d'ordre
est absoluement inconnues des SGBDR dont la logique est ensembliste. Cet
abominable ORDINAL_POSITION contrevient à cette notion et n'est donc pas
sans danger !
A +Effectivement je ne rechignerai pas à suivre une formation adaptée pour
éviter mes bricolages, et pour tout dire je suis en attente...
Excellente journée.
"Fred BROUARD" a écrit :Bonjour,
OokieDookie a écrit :Bonjour à tous,
Je dois réaliser une consolidation d'une trentaine de bases issues d'une
même application, mais qui ne gèrent pas de notion d'entité.
J'ai déjà crée un lot DTS qui assure la partie récupération et
transformation des données. Le problème auquel je me heurte est celui de la
modification de la structure de certaines tables suite à une mise à jour du
logiciel.
La "méthode" que j'utilise actuellement consite à :
- Restaurer une base d'exploitation sous un autre nom
- Supprimer en masse les lignes sysobjects hébergeant les contraintes
Monstrueux !!! Ce n'est pas en bidouillant les tables systèmes que vous
ferez sauter les contraintes. Vous risquez simplement de rendre votre
base de données totalement incohérente. De plus la modification directe
des tables système est totalement impossible en version 2005 (et
heureusement d'ailleurs lorsque l'on lit de telles chose !)- Générer ensuite des scripts de création de table à partir de SQLEM pour
les tables désirées
- Executer ces scripts dans une base vierge
- Ajouter manuellement (dans le fichier de script ou dans SQLEM) ma colonne
'Societe'
- Créer manuellement les PK en associant les colonnes utilisées à l'origine
et ma colonne 'Societe'
Ce qui me prend évidemment beaucoup de temps...
J'ai regardé les vues INFORMATION_SCHEMA et tenté de créer un script en
lisant ces informations, mais je bute notamment sur la suppression de la
virgule sur la ligne de la dernière colonne de chaque table (ça ne doit pas
être très méchant, mais c'est très contrariant ;)
Il suffit d'utiliser un outil prévu pour cela comme Power AMC (ex AMC
Designer) capable de faire de la rétro ingéniérie. Il vous constituera à
partir de la base un MPD et si vous le désirez un MCD que vous pourrez
modifier à souhait. Dès lors vous obtiendrez un nouveau script de
création de la base de données, ce qui vous demandera en tout et pour
tout 10 minutes de travail !Par ailleurs, ce traitement devra un jour pouvoir être porté en
environnement SQL2005, mais ce n'est pas une priorité.
Sachant tout cela, je voudrais connaître vos opinions sur la conduite à
tenir pour obtenir mon résultat (j'utiliserai le lot DTS pour l'alimentation
quoiqu'il arrive mais j'ai lu dernièrement que BULK INSERT pouvait
représenter une bonne alternative dans ce genre de projet).
il serait plus intelligent de se pencher sur une réplication, en
étudiant la réplication transactionnelle ou en cliché et en évitant le
réplication de fusion, peu adaptée à votre cas.
En quelques minutes vous serez capable de mettre en ouvre votre flux de
données montant et votre base de consolidation pourra être à jour avec
l'intervalle de latence désiré (une seconde, 5 minutes, 3 heures, une
journée...).Merci d'avance pour vos lumières et suggestions.
Excellente fin de journée à tous.
Il serait peut être temps de vous pencher sur une solide formation
d'administration de bases de donénes SQL Server !
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 ***********************
--
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 ces précisions.
J'abuse de votre disponibilité :
Peut-on affirmer cependant que dans le cadre de mon périmètre cela n'est pas
un problème, dans le sens ou je me base sur cette valeur pour constater si
elle est égal au maximum pour une table donnée ?
Ceci ayant pour effet d'inhiber les virgules finales dans le curseur qui
crée les instructions suivantes :
CREATE TABLE MaTable (Societe, Champ1, ..., ChampN [ici])
et
INSERT INTO Base1..MaTable (Societe, Champ1, ..., ChampN[ici]) SELECT
'Toto', Champ1,..., ChampN[et ici] FROM Base2..MaTable)
Car travailler avec les noms ne me semble pas facile dans mon cas, il
faudrait que j'arrive à référencer un nom par table pour mon test. A moins
que vous n'ayiez une astuce à me soumettre ?
Merci encore.
"Fred BROUARD" a écrit :
OokieDookie a écrit :
Bonjour,
Merci beaucoup pour vos indications. Je me doutais bien que je me ferais
remonter les bretelles en posant cette question, mais comme vous l'avez
constaté, mon profil est bien éloigné d'un dba (consultant logiciel /
développeur de requêtes sur le tas est plus adapté ;)
Peut-être me pardonnerez-vous cet affront au bon sens si je vous dis que
désormais (au prix de quelques jours de réflexion intense), je constitue la
structure de la base consolidée et son alimentation par le biais de scripts
basés sur les vues INFORMATION_SCHEMA d'une base de production n'ayant pas
bénéficié de mon traitement "à la hache" ;). J'ai en effet contourné mon
problème de "dernière colonne" avec un test sur ORDINAL_POSITION dans un
curseur, et ça marche plutôt bien (20 secondes seulement et ça marche avec
deux versions du produit à tous les coups) et abandonné l'utilisation de lots
dans le même temps.
Méfiez vous de l'ORDINAL_POSITION. Des bases identiques peuvent avoir
des diffences au niveau de cet élément. Il vaut donc mieux toujours se
base sur les noms et jamais sur les éléments ordinaux. La notion d'ordre
est absoluement inconnues des SGBDR dont la logique est ensembliste. Cet
abominable ORDINAL_POSITION contrevient à cette notion et n'est donc pas
sans danger !
A +
Effectivement je ne rechignerai pas à suivre une formation adaptée pour
éviter mes bricolages, et pour tout dire je suis en attente...
Excellente journée.
"Fred BROUARD" a écrit :
Bonjour,
OokieDookie a écrit :
Bonjour à tous,
Je dois réaliser une consolidation d'une trentaine de bases issues d'une
même application, mais qui ne gèrent pas de notion d'entité.
J'ai déjà crée un lot DTS qui assure la partie récupération et
transformation des données. Le problème auquel je me heurte est celui de la
modification de la structure de certaines tables suite à une mise à jour du
logiciel.
La "méthode" que j'utilise actuellement consite à :
- Restaurer une base d'exploitation sous un autre nom
- Supprimer en masse les lignes sysobjects hébergeant les contraintes
Monstrueux !!! Ce n'est pas en bidouillant les tables systèmes que vous
ferez sauter les contraintes. Vous risquez simplement de rendre votre
base de données totalement incohérente. De plus la modification directe
des tables système est totalement impossible en version 2005 (et
heureusement d'ailleurs lorsque l'on lit de telles chose !)
- Générer ensuite des scripts de création de table à partir de SQLEM pour
les tables désirées
- Executer ces scripts dans une base vierge
- Ajouter manuellement (dans le fichier de script ou dans SQLEM) ma colonne
'Societe'
- Créer manuellement les PK en associant les colonnes utilisées à l'origine
et ma colonne 'Societe'
Ce qui me prend évidemment beaucoup de temps...
J'ai regardé les vues INFORMATION_SCHEMA et tenté de créer un script en
lisant ces informations, mais je bute notamment sur la suppression de la
virgule sur la ligne de la dernière colonne de chaque table (ça ne doit pas
être très méchant, mais c'est très contrariant ;)
Il suffit d'utiliser un outil prévu pour cela comme Power AMC (ex AMC
Designer) capable de faire de la rétro ingéniérie. Il vous constituera à
partir de la base un MPD et si vous le désirez un MCD que vous pourrez
modifier à souhait. Dès lors vous obtiendrez un nouveau script de
création de la base de données, ce qui vous demandera en tout et pour
tout 10 minutes de travail !
Par ailleurs, ce traitement devra un jour pouvoir être porté en
environnement SQL2005, mais ce n'est pas une priorité.
Sachant tout cela, je voudrais connaître vos opinions sur la conduite à
tenir pour obtenir mon résultat (j'utiliserai le lot DTS pour l'alimentation
quoiqu'il arrive mais j'ai lu dernièrement que BULK INSERT pouvait
représenter une bonne alternative dans ce genre de projet).
il serait plus intelligent de se pencher sur une réplication, en
étudiant la réplication transactionnelle ou en cliché et en évitant le
réplication de fusion, peu adaptée à votre cas.
En quelques minutes vous serez capable de mettre en ouvre votre flux de
données montant et votre base de consolidation pourra être à jour avec
l'intervalle de latence désiré (une seconde, 5 minutes, 3 heures, une
journée...).
Merci d'avance pour vos lumières et suggestions.
Excellente fin de journée à tous.
Il serait peut être temps de vous pencher sur une solide formation
d'administration de bases de donénes SQL Server !
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 ***********************
--
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 ces précisions.
J'abuse de votre disponibilité :
Peut-on affirmer cependant que dans le cadre de mon périmètre cela n'est pas
un problème, dans le sens ou je me base sur cette valeur pour constater si
elle est égal au maximum pour une table donnée ?
Ceci ayant pour effet d'inhiber les virgules finales dans le curseur qui
crée les instructions suivantes :
CREATE TABLE MaTable (Societe, Champ1, ..., ChampN [ici])
et
INSERT INTO Base1..MaTable (Societe, Champ1, ..., ChampN[ici]) SELECT
'Toto', Champ1,..., ChampN[et ici] FROM Base2..MaTable)
Car travailler avec les noms ne me semble pas facile dans mon cas, il
faudrait que j'arrive à référencer un nom par table pour mon test. A moins
que vous n'ayiez une astuce à me soumettre ?
Merci encore.
"Fred BROUARD" a écrit :OokieDookie a écrit :Bonjour,
Merci beaucoup pour vos indications. Je me doutais bien que je me ferais
remonter les bretelles en posant cette question, mais comme vous l'avez
constaté, mon profil est bien éloigné d'un dba (consultant logiciel /
développeur de requêtes sur le tas est plus adapté ;)
Peut-être me pardonnerez-vous cet affront au bon sens si je vous dis que
désormais (au prix de quelques jours de réflexion intense), je constitue la
structure de la base consolidée et son alimentation par le biais de scripts
basés sur les vues INFORMATION_SCHEMA d'une base de production n'ayant pas
bénéficié de mon traitement "à la hache" ;). J'ai en effet contourné mon
problème de "dernière colonne" avec un test sur ORDINAL_POSITION dans un
curseur, et ça marche plutôt bien (20 secondes seulement et ça marche avec
deux versions du produit à tous les coups) et abandonné l'utilisation de lots
dans le même temps.
Méfiez vous de l'ORDINAL_POSITION. Des bases identiques peuvent avoir
des diffences au niveau de cet élément. Il vaut donc mieux toujours se
base sur les noms et jamais sur les éléments ordinaux. La notion d'ordre
est absoluement inconnues des SGBDR dont la logique est ensembliste. Cet
abominable ORDINAL_POSITION contrevient à cette notion et n'est donc pas
sans danger !
A +Effectivement je ne rechignerai pas à suivre une formation adaptée pour
éviter mes bricolages, et pour tout dire je suis en attente...
Excellente journée.
"Fred BROUARD" a écrit :Bonjour,
OokieDookie a écrit :Bonjour à tous,
Je dois réaliser une consolidation d'une trentaine de bases issues d'une
même application, mais qui ne gèrent pas de notion d'entité.
J'ai déjà crée un lot DTS qui assure la partie récupération et
transformation des données. Le problème auquel je me heurte est celui de la
modification de la structure de certaines tables suite à une mise à jour du
logiciel.
La "méthode" que j'utilise actuellement consite à :
- Restaurer une base d'exploitation sous un autre nom
- Supprimer en masse les lignes sysobjects hébergeant les contraintes
Monstrueux !!! Ce n'est pas en bidouillant les tables systèmes que vous
ferez sauter les contraintes. Vous risquez simplement de rendre votre
base de données totalement incohérente. De plus la modification directe
des tables système est totalement impossible en version 2005 (et
heureusement d'ailleurs lorsque l'on lit de telles chose !)- Générer ensuite des scripts de création de table à partir de SQLEM pour
les tables désirées
- Executer ces scripts dans une base vierge
- Ajouter manuellement (dans le fichier de script ou dans SQLEM) ma colonne
'Societe'
- Créer manuellement les PK en associant les colonnes utilisées à l'origine
et ma colonne 'Societe'
Ce qui me prend évidemment beaucoup de temps...
J'ai regardé les vues INFORMATION_SCHEMA et tenté de créer un script en
lisant ces informations, mais je bute notamment sur la suppression de la
virgule sur la ligne de la dernière colonne de chaque table (ça ne doit pas
être très méchant, mais c'est très contrariant ;)
Il suffit d'utiliser un outil prévu pour cela comme Power AMC (ex AMC
Designer) capable de faire de la rétro ingéniérie. Il vous constituera à
partir de la base un MPD et si vous le désirez un MCD que vous pourrez
modifier à souhait. Dès lors vous obtiendrez un nouveau script de
création de la base de données, ce qui vous demandera en tout et pour
tout 10 minutes de travail !Par ailleurs, ce traitement devra un jour pouvoir être porté en
environnement SQL2005, mais ce n'est pas une priorité.
Sachant tout cela, je voudrais connaître vos opinions sur la conduite à
tenir pour obtenir mon résultat (j'utiliserai le lot DTS pour l'alimentation
quoiqu'il arrive mais j'ai lu dernièrement que BULK INSERT pouvait
représenter une bonne alternative dans ce genre de projet).
il serait plus intelligent de se pencher sur une réplication, en
étudiant la réplication transactionnelle ou en cliché et en évitant le
réplication de fusion, peu adaptée à votre cas.
En quelques minutes vous serez capable de mettre en ouvre votre flux de
données montant et votre base de consolidation pourra être à jour avec
l'intervalle de latence désiré (une seconde, 5 minutes, 3 heures, une
journée...).Merci d'avance pour vos lumières et suggestions.
Excellente fin de journée à tous.
Il serait peut être temps de vous pencher sur une solide formation
d'administration de bases de donénes SQL Server !
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 ***********************
--
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 :
> Merci de ces précisions.
>
> J'abuse de votre disponibilité :
> Peut-on affirmer cependant que dans le cadre de mon périmètre cela n'est pas
> un problème, dans le sens ou je me base sur cette valeur pour constater si
> elle est égal au maximum pour une table donnée ?
> Ceci ayant pour effet d'inhiber les virgules finales dans le curseur qui
> crée les instructions suivantes :
>
> CREATE TABLE MaTable (Societe, Champ1, ..., ChampN [ici])
>
> et
>
> INSERT INTO Base1..MaTable (Societe, Champ1, ..., ChampN[ici]) SELECT
> 'Toto', Champ1,..., ChampN[et ici] FROM Base2..MaTable)
>
> Car travailler avec les noms ne me semble pas facile dans mon cas, il
> faudrait que j'arrive à référencer un nom par table pour mon test. A moins
> que vous n'ayiez une astuce à me soumettre ?
Si vous voulez toutes les colonnes d'une table il y a plus simple :
un petit exemple :
USE master
DECLARE @COLS VARCHAR(8000)
SET @COLS = ''
SELECT @COLS = @COLS + COLUMN_NAME + ', '
FROM INFORMATION_SCHEMA.COLUMNS
WHERE TABLE_SCHEMA = 'dbo'
AND TABLE_NAME = 'syslogins'
SET @COLS = SUBSTRING(@COLS, 1, LEN(@COLS) -1)
PRINT @COLS
A +
>
> Merci encore.
>
> "Fred BROUARD" a écrit :
>
>> OokieDookie a écrit :
>>> Bonjour,
>>>
>>> Merci beaucoup pour vos indications. Je me doutais bien que je me ferais
>>> remonter les bretelles en posant cette question, mais comme vous l'avez
>>> constaté, mon profil est bien éloigné d'un dba (consultant logiciel /
>>> développeur de requêtes sur le tas est plus adapté ;)
>>>
>>> Peut-être me pardonnerez-vous cet affront au bon sens si je vous dis que
>>> désormais (au prix de quelques jours de réflexion intense), je constitue la
>>> structure de la base consolidée et son alimentation par le biais de scripts
>>> basés sur les vues INFORMATION_SCHEMA d'une base de production n'ayant pas
>>> bénéficié de mon traitement "à la hache" ;). J'ai en effet contourné mon
>>> problème de "dernière colonne" avec un test sur ORDINAL_POSITION dans un
>>> curseur, et ça marche plutôt bien (20 secondes seulement et ça marche avec
>>> deux versions du produit à tous les coups) et abandonné l'utilisation de lots
>>> dans le même temps.
>> Méfiez vous de l'ORDINAL_POSITION. Des bases identiques peuvent avoir
>> des diffences au niveau de cet élément. Il vaut donc mieux toujours se
>> base sur les noms et jamais sur les éléments ordinaux. La notion d'ordre
>> est absoluement inconnues des SGBDR dont la logique est ensembliste. Cet
>> abominable ORDINAL_POSITION contrevient à cette notion et n'est donc pas
>> sans danger !
>>
>> A +
>>
>>> Effectivement je ne rechignerai pas à suivre une formation adaptée pour
>>> éviter mes bricolages, et pour tout dire je suis en attente...
>>>
>>> Excellente journée.
>>>
>>> "Fred BROUARD" a écrit :
>>>
>>>> Bonjour,
>>>>
>>>> OokieDookie a écrit :
>>>>> Bonjour à tous,
>>>>>
>>>>> Je dois réaliser une consolidation d'une trentaine de bases issues d'une
>>>>> même application, mais qui ne gèrent pas de notion d'entité.
>>>>>
>>>>> J'ai déjà crée un lot DTS qui assure la partie récupération et
>>>>> transformation des données. Le problème auquel je me heurte est celui de la
>>>>> modification de la structure de certaines tables suite à une mise à jour du
>>>>> logiciel.
>>>>>
>>>>> La "méthode" que j'utilise actuellement consite à :
>>>>> - Restaurer une base d'exploitation sous un autre nom
>>>>> - Supprimer en masse les lignes sysobjects hébergeant les contraintes
>>>> Monstrueux !!! Ce n'est pas en bidouillant les tables systèmes que vous
>>>> ferez sauter les contraintes. Vous risquez simplement de rendre votre
>>>> base de données totalement incohérente. De plus la modification directe
>>>> des tables système est totalement impossible en version 2005 (et
>>>> heureusement d'ailleurs lorsque l'on lit de telles chose !)
>>>>
>>>>> - Générer ensuite des scripts de création de table à partir de SQLEM pour
>>>>> les tables désirées
>>>>> - Executer ces scripts dans une base vierge
>>>>> - Ajouter manuellement (dans le fichier de script ou dans SQLEM) ma colonne
>>>>> 'Societe'
>>>>> - Créer manuellement les PK en associant les colonnes utilisées à l'origine
>>>>> et ma colonne 'Societe'
>>>>>
>>>>> Ce qui me prend évidemment beaucoup de temps...
>>>>> J'ai regardé les vues INFORMATION_SCHEMA et tenté de créer un script en
>>>>> lisant ces informations, mais je bute notamment sur la suppression de la
>>>>> virgule sur la ligne de la dernière colonne de chaque table (ça ne doit pas
>>>>> être très méchant, mais c'est très contrariant ;)
>>>> Il suffit d'utiliser un outil prévu pour cela comme Power AMC (ex AMC
>>>> Designer) capable de faire de la rétro ingéniérie. Il vous constituera à
>>>> partir de la base un MPD et si vous le désirez un MCD que vous pourrez
>>>> modifier à souhait. Dès lors vous obtiendrez un nouveau script de
>>>> création de la base de données, ce qui vous demandera en tout et pour
>>>> tout 10 minutes de travail !
>>>>
>>>>
>>>>> Par ailleurs, ce traitement devra un jour pouvoir être porté en
>>>>> environnement SQL2005, mais ce n'est pas une priorité.
>>>>>
>>>>> Sachant tout cela, je voudrais connaître vos opinions sur la conduite à
>>>>> tenir pour obtenir mon résultat (j'utiliserai le lot DTS pour l'alimentation
>>>>> quoiqu'il arrive mais j'ai lu dernièrement que BULK INSERT pouvait
>>>>> représenter une bonne alternative dans ce genre de projet).
>>>> il serait plus intelligent de se pencher sur une réplication, en
>>>> étudiant la réplication transactionnelle ou en cliché et en évitant le
>>>> réplication de fusion, peu adaptée à votre cas.
>>>>
>>>> En quelques minutes vous serez capable de mettre en ouvre votre flux de
>>>> données montant et votre base de consolidation pourra être à jour avec
>>>> l'intervalle de latence désiré (une seconde, 5 minutes, 3 heures, une
>>>> journée...).
>>>>
>>>>> Merci d'avance pour vos lumières et suggestions.
>>>>> Excellente fin de journée à tous.
>>>> Il serait peut être temps de vous pencher sur une solide formation
>>>> d'administration de bases de donénes SQL Server !
>>>>
>>>> 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 ***********************
>>>>
>>
>> --
>> 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 ***********************
>>
--
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 :
> Merci de ces précisions.
>
> J'abuse de votre disponibilité :
> Peut-on affirmer cependant que dans le cadre de mon périmètre cela n'est pas
> un problème, dans le sens ou je me base sur cette valeur pour constater si
> elle est égal au maximum pour une table donnée ?
> Ceci ayant pour effet d'inhiber les virgules finales dans le curseur qui
> crée les instructions suivantes :
>
> CREATE TABLE MaTable (Societe, Champ1, ..., ChampN [ici])
>
> et
>
> INSERT INTO Base1..MaTable (Societe, Champ1, ..., ChampN[ici]) SELECT
> 'Toto', Champ1,..., ChampN[et ici] FROM Base2..MaTable)
>
> Car travailler avec les noms ne me semble pas facile dans mon cas, il
> faudrait que j'arrive à référencer un nom par table pour mon test. A moins
> que vous n'ayiez une astuce à me soumettre ?
Si vous voulez toutes les colonnes d'une table il y a plus simple :
un petit exemple :
USE master
DECLARE @COLS VARCHAR(8000)
SET @COLS = ''
SELECT @COLS = @COLS + COLUMN_NAME + ', '
FROM INFORMATION_SCHEMA.COLUMNS
WHERE TABLE_SCHEMA = 'dbo'
AND TABLE_NAME = 'syslogins'
SET @COLS = SUBSTRING(@COLS, 1, LEN(@COLS) -1)
PRINT @COLS
A +
>
> Merci encore.
>
> "Fred BROUARD" a écrit :
>
>> OokieDookie a écrit :
>>> Bonjour,
>>>
>>> Merci beaucoup pour vos indications. Je me doutais bien que je me ferais
>>> remonter les bretelles en posant cette question, mais comme vous l'avez
>>> constaté, mon profil est bien éloigné d'un dba (consultant logiciel /
>>> développeur de requêtes sur le tas est plus adapté ;)
>>>
>>> Peut-être me pardonnerez-vous cet affront au bon sens si je vous dis que
>>> désormais (au prix de quelques jours de réflexion intense), je constitue la
>>> structure de la base consolidée et son alimentation par le biais de scripts
>>> basés sur les vues INFORMATION_SCHEMA d'une base de production n'ayant pas
>>> bénéficié de mon traitement "à la hache" ;). J'ai en effet contourné mon
>>> problème de "dernière colonne" avec un test sur ORDINAL_POSITION dans un
>>> curseur, et ça marche plutôt bien (20 secondes seulement et ça marche avec
>>> deux versions du produit à tous les coups) et abandonné l'utilisation de lots
>>> dans le même temps.
>> Méfiez vous de l'ORDINAL_POSITION. Des bases identiques peuvent avoir
>> des diffences au niveau de cet élément. Il vaut donc mieux toujours se
>> base sur les noms et jamais sur les éléments ordinaux. La notion d'ordre
>> est absoluement inconnues des SGBDR dont la logique est ensembliste. Cet
>> abominable ORDINAL_POSITION contrevient à cette notion et n'est donc pas
>> sans danger !
>>
>> A +
>>
>>> Effectivement je ne rechignerai pas à suivre une formation adaptée pour
>>> éviter mes bricolages, et pour tout dire je suis en attente...
>>>
>>> Excellente journée.
>>>
>>> "Fred BROUARD" a écrit :
>>>
>>>> Bonjour,
>>>>
>>>> OokieDookie a écrit :
>>>>> Bonjour à tous,
>>>>>
>>>>> Je dois réaliser une consolidation d'une trentaine de bases issues d'une
>>>>> même application, mais qui ne gèrent pas de notion d'entité.
>>>>>
>>>>> J'ai déjà crée un lot DTS qui assure la partie récupération et
>>>>> transformation des données. Le problème auquel je me heurte est celui de la
>>>>> modification de la structure de certaines tables suite à une mise à jour du
>>>>> logiciel.
>>>>>
>>>>> La "méthode" que j'utilise actuellement consite à :
>>>>> - Restaurer une base d'exploitation sous un autre nom
>>>>> - Supprimer en masse les lignes sysobjects hébergeant les contraintes
>>>> Monstrueux !!! Ce n'est pas en bidouillant les tables systèmes que vous
>>>> ferez sauter les contraintes. Vous risquez simplement de rendre votre
>>>> base de données totalement incohérente. De plus la modification directe
>>>> des tables système est totalement impossible en version 2005 (et
>>>> heureusement d'ailleurs lorsque l'on lit de telles chose !)
>>>>
>>>>> - Générer ensuite des scripts de création de table à partir de SQLEM pour
>>>>> les tables désirées
>>>>> - Executer ces scripts dans une base vierge
>>>>> - Ajouter manuellement (dans le fichier de script ou dans SQLEM) ma colonne
>>>>> 'Societe'
>>>>> - Créer manuellement les PK en associant les colonnes utilisées à l'origine
>>>>> et ma colonne 'Societe'
>>>>>
>>>>> Ce qui me prend évidemment beaucoup de temps...
>>>>> J'ai regardé les vues INFORMATION_SCHEMA et tenté de créer un script en
>>>>> lisant ces informations, mais je bute notamment sur la suppression de la
>>>>> virgule sur la ligne de la dernière colonne de chaque table (ça ne doit pas
>>>>> être très méchant, mais c'est très contrariant ;)
>>>> Il suffit d'utiliser un outil prévu pour cela comme Power AMC (ex AMC
>>>> Designer) capable de faire de la rétro ingéniérie. Il vous constituera à
>>>> partir de la base un MPD et si vous le désirez un MCD que vous pourrez
>>>> modifier à souhait. Dès lors vous obtiendrez un nouveau script de
>>>> création de la base de données, ce qui vous demandera en tout et pour
>>>> tout 10 minutes de travail !
>>>>
>>>>
>>>>> Par ailleurs, ce traitement devra un jour pouvoir être porté en
>>>>> environnement SQL2005, mais ce n'est pas une priorité.
>>>>>
>>>>> Sachant tout cela, je voudrais connaître vos opinions sur la conduite à
>>>>> tenir pour obtenir mon résultat (j'utiliserai le lot DTS pour l'alimentation
>>>>> quoiqu'il arrive mais j'ai lu dernièrement que BULK INSERT pouvait
>>>>> représenter une bonne alternative dans ce genre de projet).
>>>> il serait plus intelligent de se pencher sur une réplication, en
>>>> étudiant la réplication transactionnelle ou en cliché et en évitant le
>>>> réplication de fusion, peu adaptée à votre cas.
>>>>
>>>> En quelques minutes vous serez capable de mettre en ouvre votre flux de
>>>> données montant et votre base de consolidation pourra être à jour avec
>>>> l'intervalle de latence désiré (une seconde, 5 minutes, 3 heures, une
>>>> journée...).
>>>>
>>>>> Merci d'avance pour vos lumières et suggestions.
>>>>> Excellente fin de journée à tous.
>>>> Il serait peut être temps de vous pencher sur une solide formation
>>>> d'administration de bases de donénes SQL Server !
>>>>
>>>> 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 ***********************
>>>>
>>
>> --
>> 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 ***********************
>>
--
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 :
> Merci de ces précisions.
>
> J'abuse de votre disponibilité :
> Peut-on affirmer cependant que dans le cadre de mon périmètre cela n'est pas
> un problème, dans le sens ou je me base sur cette valeur pour constater si
> elle est égal au maximum pour une table donnée ?
> Ceci ayant pour effet d'inhiber les virgules finales dans le curseur qui
> crée les instructions suivantes :
>
> CREATE TABLE MaTable (Societe, Champ1, ..., ChampN [ici])
>
> et
>
> INSERT INTO Base1..MaTable (Societe, Champ1, ..., ChampN[ici]) SELECT
> 'Toto', Champ1,..., ChampN[et ici] FROM Base2..MaTable)
>
> Car travailler avec les noms ne me semble pas facile dans mon cas, il
> faudrait que j'arrive à référencer un nom par table pour mon test. A moins
> que vous n'ayiez une astuce à me soumettre ?
Si vous voulez toutes les colonnes d'une table il y a plus simple :
un petit exemple :
USE master
DECLARE @COLS VARCHAR(8000)
SET @COLS = ''
SELECT @COLS = @COLS + COLUMN_NAME + ', '
FROM INFORMATION_SCHEMA.COLUMNS
WHERE TABLE_SCHEMA = 'dbo'
AND TABLE_NAME = 'syslogins'
SET @COLS = SUBSTRING(@COLS, 1, LEN(@COLS) -1)
PRINT @COLS
A +
>
> Merci encore.
>
> "Fred BROUARD" a écrit :
>
>> OokieDookie a écrit :
>>> Bonjour,
>>>
>>> Merci beaucoup pour vos indications. Je me doutais bien que je me ferais
>>> remonter les bretelles en posant cette question, mais comme vous l'avez
>>> constaté, mon profil est bien éloigné d'un dba (consultant logiciel /
>>> développeur de requêtes sur le tas est plus adapté ;)
>>>
>>> Peut-être me pardonnerez-vous cet affront au bon sens si je vous dis que
>>> désormais (au prix de quelques jours de réflexion intense), je constitue la
>>> structure de la base consolidée et son alimentation par le biais de scripts
>>> basés sur les vues INFORMATION_SCHEMA d'une base de production n'ayant pas
>>> bénéficié de mon traitement "à la hache" ;). J'ai en effet contourné mon
>>> problème de "dernière colonne" avec un test sur ORDINAL_POSITION dans un
>>> curseur, et ça marche plutôt bien (20 secondes seulement et ça marche avec
>>> deux versions du produit à tous les coups) et abandonné l'utilisation de lots
>>> dans le même temps.
>> Méfiez vous de l'ORDINAL_POSITION. Des bases identiques peuvent avoir
>> des diffences au niveau de cet élément. Il vaut donc mieux toujours se
>> base sur les noms et jamais sur les éléments ordinaux. La notion d'ordre
>> est absoluement inconnues des SGBDR dont la logique est ensembliste. Cet
>> abominable ORDINAL_POSITION contrevient à cette notion et n'est donc pas
>> sans danger !
>>
>> A +
>>
>>> Effectivement je ne rechignerai pas à suivre une formation adaptée pour
>>> éviter mes bricolages, et pour tout dire je suis en attente...
>>>
>>> Excellente journée.
>>>
>>> "Fred BROUARD" a écrit :
>>>
>>>> Bonjour,
>>>>
>>>> OokieDookie a écrit :
>>>>> Bonjour à tous,
>>>>>
>>>>> Je dois réaliser une consolidation d'une trentaine de bases issues d'une
>>>>> même application, mais qui ne gèrent pas de notion d'entité.
>>>>>
>>>>> J'ai déjà crée un lot DTS qui assure la partie récupération et
>>>>> transformation des données. Le problème auquel je me heurte est celui de la
>>>>> modification de la structure de certaines tables suite à une mise à jour du
>>>>> logiciel.
>>>>>
>>>>> La "méthode" que j'utilise actuellement consite à :
>>>>> - Restaurer une base d'exploitation sous un autre nom
>>>>> - Supprimer en masse les lignes sysobjects hébergeant les contraintes
>>>> Monstrueux !!! Ce n'est pas en bidouillant les tables systèmes que vous
>>>> ferez sauter les contraintes. Vous risquez simplement de rendre votre
>>>> base de données totalement incohérente. De plus la modification directe
>>>> des tables système est totalement impossible en version 2005 (et
>>>> heureusement d'ailleurs lorsque l'on lit de telles chose !)
>>>>
>>>>> - Générer ensuite des scripts de création de table à partir de SQLEM pour
>>>>> les tables désirées
>>>>> - Executer ces scripts dans une base vierge
>>>>> - Ajouter manuellement (dans le fichier de script ou dans SQLEM) ma colonne
>>>>> 'Societe'
>>>>> - Créer manuellement les PK en associant les colonnes utilisées à l'origine
>>>>> et ma colonne 'Societe'
>>>>>
>>>>> Ce qui me prend évidemment beaucoup de temps...
>>>>> J'ai regardé les vues INFORMATION_SCHEMA et tenté de créer un script en
>>>>> lisant ces informations, mais je bute notamment sur la suppression de la
>>>>> virgule sur la ligne de la dernière colonne de chaque table (ça ne doit pas
>>>>> être très méchant, mais c'est très contrariant ;)
>>>> Il suffit d'utiliser un outil prévu pour cela comme Power AMC (ex AMC
>>>> Designer) capable de faire de la rétro ingéniérie. Il vous constituera à
>>>> partir de la base un MPD et si vous le désirez un MCD que vous pourrez
>>>> modifier à souhait. Dès lors vous obtiendrez un nouveau script de
>>>> création de la base de données, ce qui vous demandera en tout et pour
>>>> tout 10 minutes de travail !
>>>>
>>>>
>>>>> Par ailleurs, ce traitement devra un jour pouvoir être porté en
>>>>> environnement SQL2005, mais ce n'est pas une priorité.
>>>>>
>>>>> Sachant tout cela, je voudrais connaître vos opinions sur la conduite à
>>>>> tenir pour obtenir mon résultat (j'utiliserai le lot DTS pour l'alimentation
>>>>> quoiqu'il arrive mais j'ai lu dernièrement que BULK INSERT pouvait
>>>>> représenter une bonne alternative dans ce genre de projet).
>>>> il serait plus intelligent de se pencher sur une réplication, en
>>>> étudiant la réplication transactionnelle ou en cliché et en évitant le
>>>> réplication de fusion, peu adaptée à votre cas.
>>>>
>>>> En quelques minutes vous serez capable de mettre en ouvre votre flux de
>>>> données montant et votre base de consolidation pourra être à jour avec
>>>> l'intervalle de latence désiré (une seconde, 5 minutes, 3 heures, une
>>>> journée...).
>>>>
>>>>> Merci d'avance pour vos lumières et suggestions.
>>>>> Excellente fin de journée à tous.
>>>> Il serait peut être temps de vous pencher sur une solide formation
>>>> d'administration de bases de donénes SQL Server !
>>>>
>>>> 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 ***********************
>>>>
>>
>> --
>> 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 ***********************
>>
--
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 ***********************