je cherche un outils, ou une option dans l'editeur de Sql Management Studio
Express 2005, qui me permette de verifier "fortement" le texte d'une proc.
genre si je check aujourd'hui une store proc qui contient , SELECT truc FROM
tableinnexistante, ça passe. je voudrais detecter qu'il y'a une embrouille
avant le test, et de preference, celui effectué par le client :)
pour l'instant, j'ai proposé une approche test : chaque proc de la base est
appellée via un TestFixture... mais ça demande un peu de boulot à la main,
et comme nous l'evoquions il n'y a pas si longtemps dans un autre thread, ça
n'est pas simple à automatiser completement sans suppositions sur ce que
font les procs.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Philippe TROTIN [MS]
Bonjour,
Pourquoi ne pas simplement gérer les erreurs au niveau de votre code SQL via des instructions ?
BEGIN TRY MonCode END TRY BEGIN CATCH MonCodeException (RAISERROR(...)) END CATCH
Cordialement _______________________________
Philippe TROTIN Microsoft Services France _______________________________
"Ambassadeur kosh" a écrit dans le message de groupe de discussion : BAB9j.52$
Bonjour
je cherche un outils, ou une option dans l'editeur de Sql Management Studio Express 2005, qui me permette de verifier "fortement" le texte d'une proc.
genre si je check aujourd'hui une store proc qui contient , SELECT truc FROM tableinnexistante, ça passe. je voudrais detecter qu'il y'a une embrouille avant le test, et de preference, celui effectué par le client :)
pour l'instant, j'ai proposé une approche test : chaque proc de la base est appellée via un TestFixture... mais ça demande un peu de boulot à la main, et comme nous l'evoquions il n'y a pas si longtemps dans un autre thread, ça n'est pas simple à automatiser completement sans suppositions sur ce que font les procs.
merci d'avance pour vos lumieres
Frédéric
Bonjour,
Pourquoi ne pas simplement gérer les erreurs au niveau de votre code SQL via
des instructions ?
BEGIN TRY
MonCode
END TRY
BEGIN CATCH
MonCodeException (RAISERROR(...))
END CATCH
Cordialement
_______________________________
Philippe TROTIN
Microsoft Services France
_______________________________
"Ambassadeur kosh" <kosh.naranek@babylon5.net> a écrit dans le message de
groupe de discussion : BAB9j.52$_25.68@nntpserver.swip.net...
Bonjour
je cherche un outils, ou une option dans l'editeur de Sql Management
Studio Express 2005, qui me permette de verifier "fortement" le texte
d'une proc.
genre si je check aujourd'hui une store proc qui contient , SELECT truc
FROM tableinnexistante, ça passe. je voudrais detecter qu'il y'a une
embrouille avant le test, et de preference, celui effectué par le client
:)
pour l'instant, j'ai proposé une approche test : chaque proc de la base
est appellée via un TestFixture... mais ça demande un peu de boulot à la
main, et comme nous l'evoquions il n'y a pas si longtemps dans un autre
thread, ça n'est pas simple à automatiser completement sans suppositions
sur ce que font les procs.
Pourquoi ne pas simplement gérer les erreurs au niveau de votre code SQL via des instructions ?
BEGIN TRY MonCode END TRY BEGIN CATCH MonCodeException (RAISERROR(...)) END CATCH
Cordialement _______________________________
Philippe TROTIN Microsoft Services France _______________________________
"Ambassadeur kosh" a écrit dans le message de groupe de discussion : BAB9j.52$
Bonjour
je cherche un outils, ou une option dans l'editeur de Sql Management Studio Express 2005, qui me permette de verifier "fortement" le texte d'une proc.
genre si je check aujourd'hui une store proc qui contient , SELECT truc FROM tableinnexistante, ça passe. je voudrais detecter qu'il y'a une embrouille avant le test, et de preference, celui effectué par le client :)
pour l'instant, j'ai proposé une approche test : chaque proc de la base est appellée via un TestFixture... mais ça demande un peu de boulot à la main, et comme nous l'evoquions il n'y a pas si longtemps dans un autre thread, ça n'est pas simple à automatiser completement sans suppositions sur ce que font les procs.
merci d'avance pour vos lumieres
Frédéric
Ambassadeur kosh
Bonjour Philippe
Bien sur, nous avons une gestion des erreurs dans le SQL. elle fonctionne avec @@error et des goto, mais en gros, ça revient à ça.
Sur notre projet, nous avions décidé de faire des tests unitaires et des tests d'integration avant de livrer. nous nous sommes rendu compte que dans la pratique, les gens ne testent pas leur code, et commit beaucoup de sql avec des noms de champs inexistants ou d'autres choses. Et si on modifie une table ou une vue, personne ne se soucie en general de modifier en conséquence tout ce qui en dépend. Les tests d'integration, qui sont souvent faits à moitié par manque de temps en fin de projet, ce qui nous amene chez le client avec une qualité, disons, differente de ce à quoi nous nous sommes engagés :)
En xml, on a la verification de la forme du document, et la validation par rapport au schéma, et la, je cherche la validation en Sql... ça apportera une garantie en amont, et ainsi, on s'attachera d'avantage au fonctionnel.
Sinon, comme je dispose du schéma de la base, je peux facilement generer une batterie de tests unitaires, et les executer regulierement pour deceler les @@error.
sinon, je peux écrire un parser sql, et greffer des tas de mécanismes dessus (validation, normes et precos "La poste", réecriture...), mais je sens que le boss ne va pas apprecier la facture :) à défaut de l'ecrire, il y'en a peut etre un que vous me recommanderiez, idéalement en .Net...
Cordialement,
Frédéric DIDIER SQLI Montpellier
"Philippe TROTIN [MS]" a écrit dans le message de news:
Bonjour,
Pourquoi ne pas simplement gérer les erreurs au niveau de votre code SQL via des instructions ?
BEGIN TRY MonCode END TRY BEGIN CATCH MonCodeException (RAISERROR(...)) END CATCH
Cordialement _______________________________
Philippe TROTIN Microsoft Services France _______________________________
"Ambassadeur kosh" a écrit dans le message de groupe de discussion : BAB9j.52$
Bonjour
je cherche un outils, ou une option dans l'editeur de Sql Management Studio Express 2005, qui me permette de verifier "fortement" le texte d'une proc.
genre si je check aujourd'hui une store proc qui contient , SELECT truc FROM tableinnexistante, ça passe. je voudrais detecter qu'il y'a une embrouille avant le test, et de preference, celui effectué par le client :)
pour l'instant, j'ai proposé une approche test : chaque proc de la base est appellée via un TestFixture... mais ça demande un peu de boulot à la main, et comme nous l'evoquions il n'y a pas si longtemps dans un autre thread, ça n'est pas simple à automatiser completement sans suppositions sur ce que font les procs.
merci d'avance pour vos lumieres
Frédéric
Bonjour Philippe
Bien sur, nous avons une gestion des erreurs dans le SQL. elle fonctionne
avec @@error et des goto, mais en gros, ça revient à ça.
Sur notre projet, nous avions décidé de faire des tests unitaires et des
tests d'integration avant de livrer. nous nous sommes rendu compte que dans
la pratique, les gens ne testent pas leur code, et commit beaucoup de sql
avec des noms de champs inexistants ou d'autres choses. Et si on modifie une
table ou une vue, personne ne se soucie en general de modifier en
conséquence tout ce qui en dépend. Les tests d'integration, qui sont souvent
faits à moitié par manque de temps en fin de projet, ce qui nous amene chez
le client avec une qualité, disons, differente de ce à quoi nous nous sommes
engagés :)
En xml, on a la verification de la forme du document, et la validation par
rapport au schéma, et la, je cherche la validation en Sql... ça apportera
une garantie en amont, et ainsi, on s'attachera d'avantage au fonctionnel.
Sinon, comme je dispose du schéma de la base, je peux facilement generer une
batterie de tests unitaires, et les executer regulierement pour deceler les
@@error.
sinon, je peux écrire un parser sql, et greffer des tas de mécanismes dessus
(validation, normes et precos "La poste", réecriture...), mais je sens que
le boss ne va pas apprecier la facture :)
à défaut de l'ecrire, il y'en a peut etre un que vous me recommanderiez,
idéalement en .Net...
Cordialement,
Frédéric DIDIER
SQLI Montpellier
"Philippe TROTIN [MS]" <ptrotin@online.microsoft.com> a écrit dans le
message de news: 78452920-1B58-42F5-BF2D-EB4152067C78@microsoft.com...
Bonjour,
Pourquoi ne pas simplement gérer les erreurs au niveau de votre code SQL
via des instructions ?
BEGIN TRY
MonCode
END TRY
BEGIN CATCH
MonCodeException (RAISERROR(...))
END CATCH
Cordialement
_______________________________
Philippe TROTIN
Microsoft Services France
_______________________________
"Ambassadeur kosh" <kosh.naranek@babylon5.net> a écrit dans le message de
groupe de discussion : BAB9j.52$_25.68@nntpserver.swip.net...
Bonjour
je cherche un outils, ou une option dans l'editeur de Sql Management
Studio Express 2005, qui me permette de verifier "fortement" le texte
d'une proc.
genre si je check aujourd'hui une store proc qui contient , SELECT truc
FROM tableinnexistante, ça passe. je voudrais detecter qu'il y'a une
embrouille avant le test, et de preference, celui effectué par le client
:)
pour l'instant, j'ai proposé une approche test : chaque proc de la base
est appellée via un TestFixture... mais ça demande un peu de boulot à la
main, et comme nous l'evoquions il n'y a pas si longtemps dans un autre
thread, ça n'est pas simple à automatiser completement sans suppositions
sur ce que font les procs.
Bien sur, nous avons une gestion des erreurs dans le SQL. elle fonctionne avec @@error et des goto, mais en gros, ça revient à ça.
Sur notre projet, nous avions décidé de faire des tests unitaires et des tests d'integration avant de livrer. nous nous sommes rendu compte que dans la pratique, les gens ne testent pas leur code, et commit beaucoup de sql avec des noms de champs inexistants ou d'autres choses. Et si on modifie une table ou une vue, personne ne se soucie en general de modifier en conséquence tout ce qui en dépend. Les tests d'integration, qui sont souvent faits à moitié par manque de temps en fin de projet, ce qui nous amene chez le client avec une qualité, disons, differente de ce à quoi nous nous sommes engagés :)
En xml, on a la verification de la forme du document, et la validation par rapport au schéma, et la, je cherche la validation en Sql... ça apportera une garantie en amont, et ainsi, on s'attachera d'avantage au fonctionnel.
Sinon, comme je dispose du schéma de la base, je peux facilement generer une batterie de tests unitaires, et les executer regulierement pour deceler les @@error.
sinon, je peux écrire un parser sql, et greffer des tas de mécanismes dessus (validation, normes et precos "La poste", réecriture...), mais je sens que le boss ne va pas apprecier la facture :) à défaut de l'ecrire, il y'en a peut etre un que vous me recommanderiez, idéalement en .Net...
Cordialement,
Frédéric DIDIER SQLI Montpellier
"Philippe TROTIN [MS]" a écrit dans le message de news:
Bonjour,
Pourquoi ne pas simplement gérer les erreurs au niveau de votre code SQL via des instructions ?
BEGIN TRY MonCode END TRY BEGIN CATCH MonCodeException (RAISERROR(...)) END CATCH
Cordialement _______________________________
Philippe TROTIN Microsoft Services France _______________________________
"Ambassadeur kosh" a écrit dans le message de groupe de discussion : BAB9j.52$
Bonjour
je cherche un outils, ou une option dans l'editeur de Sql Management Studio Express 2005, qui me permette de verifier "fortement" le texte d'une proc.
genre si je check aujourd'hui une store proc qui contient , SELECT truc FROM tableinnexistante, ça passe. je voudrais detecter qu'il y'a une embrouille avant le test, et de preference, celui effectué par le client :)
pour l'instant, j'ai proposé une approche test : chaque proc de la base est appellée via un TestFixture... mais ça demande un peu de boulot à la main, et comme nous l'evoquions il n'y a pas si longtemps dans un autre thread, ça n'est pas simple à automatiser completement sans suppositions sur ce que font les procs.
merci d'avance pour vos lumieres
Frédéric
Rudi Bruchez
Bonjour,
Ambassadeur kosh a écrit:
genre si je check aujourd'hui une store proc qui contient , SELECT truc FROM tableinnexistante, ça passe. je voudrais detecter qu'il y'a une embrouille avant le test, et de preference, celui effectué par le client :)
Tu ne peux pas forcer un teste de table inexistante, SQL Server a un procédé de résolution de nom différé, qui ne valide cela qu'à l'optimisation de la proc. Mais tu peux te faire des tests unitaires, par exemple avec ceci : http://tsqlunit.sourceforge.net/
genre si je check aujourd'hui une store proc qui contient , SELECT truc FROM
tableinnexistante, ça passe. je voudrais detecter qu'il y'a une embrouille
avant le test, et de preference, celui effectué par le client :)
Tu ne peux pas forcer un teste de table inexistante, SQL Server a un
procédé de résolution de nom différé, qui ne valide cela qu'à
l'optimisation de la proc.
Mais tu peux te faire des tests unitaires, par exemple avec ceci :
http://tsqlunit.sourceforge.net/
genre si je check aujourd'hui une store proc qui contient , SELECT truc FROM tableinnexistante, ça passe. je voudrais detecter qu'il y'a une embrouille avant le test, et de preference, celui effectué par le client :)
Tu ne peux pas forcer un teste de table inexistante, SQL Server a un procédé de résolution de nom différé, qui ne valide cela qu'à l'optimisation de la proc. Mais tu peux te faire des tests unitaires, par exemple avec ceci : http://tsqlunit.sourceforge.net/
Une bonne méthode consiste peut être à : - Générer un script de création de votre base (incluant les procédures, fonctions, ...), - Recréer une base vide - Appliquer le script généré
Vous risquez de détecter pas mal de problème en effectuant cette opération.
Après, il y a peut être mieux...
Cordialement _______________________________
Philippe TROTIN Microsoft Services France _______________________________
"Ambassadeur kosh" a écrit dans le message de groupe de discussion : 6t3aj.5$
Bonjour Philippe
Bien sur, nous avons une gestion des erreurs dans le SQL. elle fonctionne avec @@error et des goto, mais en gros, ça revient à ça.
Sur notre projet, nous avions décidé de faire des tests unitaires et des tests d'integration avant de livrer. nous nous sommes rendu compte que dans la pratique, les gens ne testent pas leur code, et commit beaucoup de sql avec des noms de champs inexistants ou d'autres choses. Et si on modifie une table ou une vue, personne ne se soucie en general de modifier en conséquence tout ce qui en dépend. Les tests d'integration, qui sont souvent faits à moitié par manque de temps en fin de projet, ce qui nous amene chez le client avec une qualité, disons, differente de ce à quoi nous nous sommes engagés :)
En xml, on a la verification de la forme du document, et la validation par rapport au schéma, et la, je cherche la validation en Sql... ça apportera une garantie en amont, et ainsi, on s'attachera d'avantage au fonctionnel.
Sinon, comme je dispose du schéma de la base, je peux facilement generer une batterie de tests unitaires, et les executer regulierement pour deceler les @@error.
sinon, je peux écrire un parser sql, et greffer des tas de mécanismes dessus (validation, normes et precos "La poste", réecriture...), mais je sens que le boss ne va pas apprecier la facture :) à défaut de l'ecrire, il y'en a peut etre un que vous me recommanderiez, idéalement en .Net...
Cordialement,
Frédéric DIDIER SQLI Montpellier
"Philippe TROTIN [MS]" a écrit dans le message de news:
Bonjour,
Pourquoi ne pas simplement gérer les erreurs au niveau de votre code SQL via des instructions ?
BEGIN TRY MonCode END TRY BEGIN CATCH MonCodeException (RAISERROR(...)) END CATCH
Cordialement _______________________________
Philippe TROTIN Microsoft Services France _______________________________
"Ambassadeur kosh" a écrit dans le message de groupe de discussion : BAB9j.52$
Bonjour
je cherche un outils, ou une option dans l'editeur de Sql Management Studio Express 2005, qui me permette de verifier "fortement" le texte d'une proc.
genre si je check aujourd'hui une store proc qui contient , SELECT truc FROM tableinnexistante, ça passe. je voudrais detecter qu'il y'a une embrouille avant le test, et de preference, celui effectué par le client :)
pour l'instant, j'ai proposé une approche test : chaque proc de la base est appellée via un TestFixture... mais ça demande un peu de boulot à la main, et comme nous l'evoquions il n'y a pas si longtemps dans un autre thread, ça n'est pas simple à automatiser completement sans suppositions sur ce que font les procs.
merci d'avance pour vos lumieres
Frédéric
Bonjour,
Une bonne méthode consiste peut être à :
- Générer un script de création de votre base (incluant les procédures,
fonctions, ...),
- Recréer une base vide
- Appliquer le script généré
Vous risquez de détecter pas mal de problème en effectuant cette opération.
Après, il y a peut être mieux...
Cordialement
_______________________________
Philippe TROTIN
Microsoft Services France
_______________________________
"Ambassadeur kosh" <kosh.naranek@babylon5.net> a écrit dans le message de
groupe de discussion : 6t3aj.5$yG2.48@nntpserver.swip.net...
Bonjour Philippe
Bien sur, nous avons une gestion des erreurs dans le SQL. elle fonctionne
avec @@error et des goto, mais en gros, ça revient à ça.
Sur notre projet, nous avions décidé de faire des tests unitaires et des
tests d'integration avant de livrer. nous nous sommes rendu compte que
dans la pratique, les gens ne testent pas leur code, et commit beaucoup de
sql avec des noms de champs inexistants ou d'autres choses. Et si on
modifie une table ou une vue, personne ne se soucie en general de modifier
en conséquence tout ce qui en dépend. Les tests d'integration, qui sont
souvent faits à moitié par manque de temps en fin de projet, ce qui nous
amene chez le client avec une qualité, disons, differente de ce à quoi
nous nous sommes engagés :)
En xml, on a la verification de la forme du document, et la validation par
rapport au schéma, et la, je cherche la validation en Sql... ça apportera
une garantie en amont, et ainsi, on s'attachera d'avantage au fonctionnel.
Sinon, comme je dispose du schéma de la base, je peux facilement generer
une batterie de tests unitaires, et les executer regulierement pour
deceler les @@error.
sinon, je peux écrire un parser sql, et greffer des tas de mécanismes
dessus (validation, normes et precos "La poste", réecriture...), mais je
sens que le boss ne va pas apprecier la facture :)
à défaut de l'ecrire, il y'en a peut etre un que vous me recommanderiez,
idéalement en .Net...
Cordialement,
Frédéric DIDIER
SQLI Montpellier
"Philippe TROTIN [MS]" <ptrotin@online.microsoft.com> a écrit dans le
message de news: 78452920-1B58-42F5-BF2D-EB4152067C78@microsoft.com...
Bonjour,
Pourquoi ne pas simplement gérer les erreurs au niveau de votre code SQL
via des instructions ?
BEGIN TRY
MonCode
END TRY
BEGIN CATCH
MonCodeException (RAISERROR(...))
END CATCH
Cordialement
_______________________________
Philippe TROTIN
Microsoft Services France
_______________________________
"Ambassadeur kosh" <kosh.naranek@babylon5.net> a écrit dans le message de
groupe de discussion : BAB9j.52$_25.68@nntpserver.swip.net...
Bonjour
je cherche un outils, ou une option dans l'editeur de Sql Management
Studio Express 2005, qui me permette de verifier "fortement" le texte
d'une proc.
genre si je check aujourd'hui une store proc qui contient , SELECT truc
FROM tableinnexistante, ça passe. je voudrais detecter qu'il y'a une
embrouille avant le test, et de preference, celui effectué par le client
:)
pour l'instant, j'ai proposé une approche test : chaque proc de la base
est appellée via un TestFixture... mais ça demande un peu de boulot à la
main, et comme nous l'evoquions il n'y a pas si longtemps dans un autre
thread, ça n'est pas simple à automatiser completement sans suppositions
sur ce que font les procs.
Une bonne méthode consiste peut être à : - Générer un script de création de votre base (incluant les procédures, fonctions, ...), - Recréer une base vide - Appliquer le script généré
Vous risquez de détecter pas mal de problème en effectuant cette opération.
Après, il y a peut être mieux...
Cordialement _______________________________
Philippe TROTIN Microsoft Services France _______________________________
"Ambassadeur kosh" a écrit dans le message de groupe de discussion : 6t3aj.5$
Bonjour Philippe
Bien sur, nous avons une gestion des erreurs dans le SQL. elle fonctionne avec @@error et des goto, mais en gros, ça revient à ça.
Sur notre projet, nous avions décidé de faire des tests unitaires et des tests d'integration avant de livrer. nous nous sommes rendu compte que dans la pratique, les gens ne testent pas leur code, et commit beaucoup de sql avec des noms de champs inexistants ou d'autres choses. Et si on modifie une table ou une vue, personne ne se soucie en general de modifier en conséquence tout ce qui en dépend. Les tests d'integration, qui sont souvent faits à moitié par manque de temps en fin de projet, ce qui nous amene chez le client avec une qualité, disons, differente de ce à quoi nous nous sommes engagés :)
En xml, on a la verification de la forme du document, et la validation par rapport au schéma, et la, je cherche la validation en Sql... ça apportera une garantie en amont, et ainsi, on s'attachera d'avantage au fonctionnel.
Sinon, comme je dispose du schéma de la base, je peux facilement generer une batterie de tests unitaires, et les executer regulierement pour deceler les @@error.
sinon, je peux écrire un parser sql, et greffer des tas de mécanismes dessus (validation, normes et precos "La poste", réecriture...), mais je sens que le boss ne va pas apprecier la facture :) à défaut de l'ecrire, il y'en a peut etre un que vous me recommanderiez, idéalement en .Net...
Cordialement,
Frédéric DIDIER SQLI Montpellier
"Philippe TROTIN [MS]" a écrit dans le message de news:
Bonjour,
Pourquoi ne pas simplement gérer les erreurs au niveau de votre code SQL via des instructions ?
BEGIN TRY MonCode END TRY BEGIN CATCH MonCodeException (RAISERROR(...)) END CATCH
Cordialement _______________________________
Philippe TROTIN Microsoft Services France _______________________________
"Ambassadeur kosh" a écrit dans le message de groupe de discussion : BAB9j.52$
Bonjour
je cherche un outils, ou une option dans l'editeur de Sql Management Studio Express 2005, qui me permette de verifier "fortement" le texte d'une proc.
genre si je check aujourd'hui une store proc qui contient , SELECT truc FROM tableinnexistante, ça passe. je voudrais detecter qu'il y'a une embrouille avant le test, et de preference, celui effectué par le client :)
pour l'instant, j'ai proposé une approche test : chaque proc de la base est appellée via un TestFixture... mais ça demande un peu de boulot à la main, et comme nous l'evoquions il n'y a pas si longtemps dans un autre thread, ça n'est pas simple à automatiser completement sans suppositions sur ce que font les procs.
merci d'avance pour vos lumieres
Frédéric
Ambassadeur kosh
> Une bonne méthode consiste peut être à : - Générer un script de création de votre base (incluant les procédures, fonctions, ...), - Recréer une base vide - Appliquer le script généré
Vous risquez de détecter pas mal de problème en effectuant cette opération.
ok, ça aussi, nous le faisons. en fait, comme nous travaillons sur plusieurs sites différents, nous avons l'ensemble des "composantes" de la base qui se trouve dans un repository SVN. les gens bossent, commit, et toutes les nuits : - on restaure la base à partir d'un dump de la base client - on recupere le contenu actuel du svn - on upgrade la base avec le script de mise à jour generé à partir des fichiers .sql.
les problemes que nous detectons sont liés essentiellement à la malformation syntaxique, mais pas au schéma... quoi qu'il en soit, cette façon de faire est mise en pratique et je ne vois pas comment on pourrait faire sans pour arriver à la fin du projet avec un livrable fiable.
merci pour votre aide.
Cordialement,
Frédéric DIDIER SQLI Montpellier
> Une bonne méthode consiste peut être à :
- Générer un script de création de votre base (incluant les procédures,
fonctions, ...),
- Recréer une base vide
- Appliquer le script généré
Vous risquez de détecter pas mal de problème en effectuant cette
opération.
ok, ça aussi, nous le faisons. en fait, comme nous travaillons sur plusieurs
sites différents, nous avons l'ensemble des "composantes" de la base qui se
trouve dans un repository SVN. les gens bossent, commit, et toutes les nuits
:
- on restaure la base à partir d'un dump de la base client
- on recupere le contenu actuel du svn
- on upgrade la base avec le script de mise à jour generé à partir des
fichiers .sql.
les problemes que nous detectons sont liés essentiellement à la malformation
syntaxique, mais pas au schéma...
quoi qu'il en soit, cette façon de faire est mise en pratique et je ne vois
pas comment on pourrait faire sans pour arriver à la fin du projet avec un
livrable fiable.
> Une bonne méthode consiste peut être à : - Générer un script de création de votre base (incluant les procédures, fonctions, ...), - Recréer une base vide - Appliquer le script généré
Vous risquez de détecter pas mal de problème en effectuant cette opération.
ok, ça aussi, nous le faisons. en fait, comme nous travaillons sur plusieurs sites différents, nous avons l'ensemble des "composantes" de la base qui se trouve dans un repository SVN. les gens bossent, commit, et toutes les nuits : - on restaure la base à partir d'un dump de la base client - on recupere le contenu actuel du svn - on upgrade la base avec le script de mise à jour generé à partir des fichiers .sql.
les problemes que nous detectons sont liés essentiellement à la malformation syntaxique, mais pas au schéma... quoi qu'il en soit, cette façon de faire est mise en pratique et je ne vois pas comment on pourrait faire sans pour arriver à la fin du projet avec un livrable fiable.
merci pour votre aide.
Cordialement,
Frédéric DIDIER SQLI Montpellier
Ambassadeur kosh
> Tu ne peux pas forcer un teste de table inexistante, SQL Server a un procédé de résolution de nom différé, qui ne valide cela qu'à l'optimisation de la proc.
ok. c'est acté.
Mais tu peux te faire des tests unitaires, par exemple avec ceci : http://tsqlunit.sourceforge.net/
ça me va. j'ai un xml avec la liste des objets de la base qui peut etre generé, 10 lignes de xsl, et on en parle plus... j'avais le secret espoir qu'un parser existe quelque part, voir qu'un assembly de sql server 2005 puisse etre utilisé pour réaliser ce genre d'outils... :o)
merci pour les infos
Frédéric DIDIER SQLI Montpellier
> Tu ne peux pas forcer un teste de table inexistante, SQL Server a un
procédé de résolution de nom différé, qui ne valide cela qu'à
l'optimisation de la proc.
ok. c'est acté.
Mais tu peux te faire des tests unitaires, par exemple avec ceci :
http://tsqlunit.sourceforge.net/
ça me va. j'ai un xml avec la liste des objets de la base qui peut etre
generé, 10 lignes de xsl, et on en parle plus...
j'avais le secret espoir qu'un parser existe quelque part, voir qu'un
assembly de sql server 2005 puisse etre utilisé pour réaliser ce genre
d'outils... :o)
> Tu ne peux pas forcer un teste de table inexistante, SQL Server a un procédé de résolution de nom différé, qui ne valide cela qu'à l'optimisation de la proc.
ok. c'est acté.
Mais tu peux te faire des tests unitaires, par exemple avec ceci : http://tsqlunit.sourceforge.net/
ça me va. j'ai un xml avec la liste des objets de la base qui peut etre generé, 10 lignes de xsl, et on en parle plus... j'avais le secret espoir qu'un parser existe quelque part, voir qu'un assembly de sql server 2005 puisse etre utilisé pour réaliser ce genre d'outils... :o)
merci pour les infos
Frédéric DIDIER SQLI Montpellier
Philippe TROTIN [MS]
A ma connaissance, il n'y en a pas mais je peux me tromper. :-(
Cordialement _______________________________
Philippe TROTIN Microsoft Services France _______________________________
"Ambassadeur kosh" a écrit dans le message de groupe de discussion : rhhaj.104$
Tu ne peux pas forcer un teste de table inexistante, SQL Server a un procédé de résolution de nom différé, qui ne valide cela qu'à l'optimisation de la proc.
ok. c'est acté.
Mais tu peux te faire des tests unitaires, par exemple avec ceci : http://tsqlunit.sourceforge.net/
ça me va. j'ai un xml avec la liste des objets de la base qui peut etre generé, 10 lignes de xsl, et on en parle plus... j'avais le secret espoir qu'un parser existe quelque part, voir qu'un assembly de sql server 2005 puisse etre utilisé pour réaliser ce genre d'outils... :o)
merci pour les infos
Frédéric DIDIER SQLI Montpellier
A ma connaissance, il n'y en a pas mais je peux me tromper. :-(
Cordialement
_______________________________
Philippe TROTIN
Microsoft Services France
_______________________________
"Ambassadeur kosh" <kosh.naranek@babylon5.net> a écrit dans le message de
groupe de discussion : rhhaj.104$yG2.81@nntpserver.swip.net...
Tu ne peux pas forcer un teste de table inexistante, SQL Server a un
procédé de résolution de nom différé, qui ne valide cela qu'à
l'optimisation de la proc.
ok. c'est acté.
Mais tu peux te faire des tests unitaires, par exemple avec ceci :
http://tsqlunit.sourceforge.net/
ça me va. j'ai un xml avec la liste des objets de la base qui peut etre
generé, 10 lignes de xsl, et on en parle plus...
j'avais le secret espoir qu'un parser existe quelque part, voir qu'un
assembly de sql server 2005 puisse etre utilisé pour réaliser ce genre
d'outils... :o)
A ma connaissance, il n'y en a pas mais je peux me tromper. :-(
Cordialement _______________________________
Philippe TROTIN Microsoft Services France _______________________________
"Ambassadeur kosh" a écrit dans le message de groupe de discussion : rhhaj.104$
Tu ne peux pas forcer un teste de table inexistante, SQL Server a un procédé de résolution de nom différé, qui ne valide cela qu'à l'optimisation de la proc.
ok. c'est acté.
Mais tu peux te faire des tests unitaires, par exemple avec ceci : http://tsqlunit.sourceforge.net/
ça me va. j'ai un xml avec la liste des objets de la base qui peut etre generé, 10 lignes de xsl, et on en parle plus... j'avais le secret espoir qu'un parser existe quelque part, voir qu'un assembly de sql server 2005 puisse etre utilisé pour réaliser ce genre d'outils... :o)
merci pour les infos
Frédéric DIDIER SQLI Montpellier
Ambassadeur kosh
pas grave... merci à vous deux pour le coup de pouce...
A ma connaissance, il n'y en a pas mais je peux me tromper. :-( Cordialement
pas grave...
merci à vous deux pour le coup de pouce...
A ma connaissance, il n'y en a pas mais je peux me tromper. :-(
Cordialement
