Problème bizarre et rare : croissance auto d'une bdd
5 réponses
Sébastien Carriot
Bonjour,
Ce problème est assez rare et il n'y aucun caractère d'urgence à ce message.
Je souhaitais simplement le poster car je retombe dessus tous les 2 mois
environ et je voualis savoir si quelqu'un avait rencontré le même phénomène.
A savoir : j'ai une base en croissance automatique (qu'elle soit en
pourcentage ou en croissance fixe) comportant un seul fichier. La base est
assez importante (40 Go) mais se trouve sur un disque ayant autant d'espace
disponible. Idem pour le journal : le disque est très loin d'être saturé.
Cette base est mise à jour toutes les nuits par des lots DTS pilotés en VB.
Or de temps en temps (très rarement donc), j'ai un message d'erreur des lots
DTS m'indiquant que le fichier Primary est plein. Dans l'observateur
d'événements du serveur, même message. Je regarde alors les disques : 100 Go
de libre. Je regarde l'état de la bdd et effectivement, 0% d'espace libre.
Je teste à nouveau le lot DTS manuellement : même erreur.
Seule solution trouvée pour le moment : changer la valeur de croissance
(passer de 10% à 11%). Valider. Revenir à 10%.
Je relance le lot DTS et hop, ça passe.
Bizarre.....
Notez que j'ai eu le problème sur une autre base d'un autre serveur, tous en
SQL Server 2000 SP3 FR.
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
Sylvain Lafontaine
Début de réponse: le lot DTS s'effectue à l'intérieur d'une seule transaction globale et par conséquent doit être capable de se faire à l'intérieur du 10% permis. Il semble donc que SQL-Server ne peut pas faire des augmentations successives à l'intérieur d'une seule transaction ou quelque chose du genre.
Pourquoi vous obstiner à revenir à 10%? Garder le 11% ou mettez une valeur absolue plutôt que proportionnelle.
Le modèle de sauvegarde du journal de transaction peut également avoir une importance ici.
S. L.
"Sébastien Carriot" wrote in message news:%
Bonjour,
Ce problème est assez rare et il n'y aucun caractère d'urgence à ce message. Je souhaitais simplement le poster car je retombe dessus tous les 2 mois environ et je voualis savoir si quelqu'un avait rencontré le même phénomène.
A savoir : j'ai une base en croissance automatique (qu'elle soit en pourcentage ou en croissance fixe) comportant un seul fichier. La base est assez importante (40 Go) mais se trouve sur un disque ayant autant d'espace disponible. Idem pour le journal : le disque est très loin d'être saturé.
Cette base est mise à jour toutes les nuits par des lots DTS pilotés en VB. Or de temps en temps (très rarement donc), j'ai un message d'erreur des lots DTS m'indiquant que le fichier Primary est plein. Dans l'observateur d'événements du serveur, même message. Je regarde alors les disques : 100 Go de libre. Je regarde l'état de la bdd et effectivement, 0% d'espace libre. Je teste à nouveau le lot DTS manuellement : même erreur.
Seule solution trouvée pour le moment : changer la valeur de croissance (passer de 10% à 11%). Valider. Revenir à 10%. Je relance le lot DTS et hop, ça passe.
Bizarre.....
Notez que j'ai eu le problème sur une autre base d'un autre serveur, tous en SQL Server 2000 SP3 FR.
Sébastien
Début de réponse: le lot DTS s'effectue à l'intérieur d'une seule
transaction globale et par conséquent doit être capable de se faire à
l'intérieur du 10% permis. Il semble donc que SQL-Server ne peut pas faire
des augmentations successives à l'intérieur d'une seule transaction ou
quelque chose du genre.
Pourquoi vous obstiner à revenir à 10%? Garder le 11% ou mettez une valeur
absolue plutôt que proportionnelle.
Le modèle de sauvegarde du journal de transaction peut également avoir une
importance ici.
S. L.
"Sébastien Carriot" <sebastien@atinternet.com> wrote in message
news:%23XVwMC1wEHA.3976@TK2MSFTNGP09.phx.gbl...
Bonjour,
Ce problème est assez rare et il n'y aucun caractère d'urgence à ce
message.
Je souhaitais simplement le poster car je retombe dessus tous les 2 mois
environ et je voualis savoir si quelqu'un avait rencontré le même
phénomène.
A savoir : j'ai une base en croissance automatique (qu'elle soit en
pourcentage ou en croissance fixe) comportant un seul fichier. La base est
assez importante (40 Go) mais se trouve sur un disque ayant autant
d'espace
disponible. Idem pour le journal : le disque est très loin d'être saturé.
Cette base est mise à jour toutes les nuits par des lots DTS pilotés en
VB.
Or de temps en temps (très rarement donc), j'ai un message d'erreur des
lots
DTS m'indiquant que le fichier Primary est plein. Dans l'observateur
d'événements du serveur, même message. Je regarde alors les disques : 100
Go
de libre. Je regarde l'état de la bdd et effectivement, 0% d'espace libre.
Je teste à nouveau le lot DTS manuellement : même erreur.
Seule solution trouvée pour le moment : changer la valeur de croissance
(passer de 10% à 11%). Valider. Revenir à 10%.
Je relance le lot DTS et hop, ça passe.
Bizarre.....
Notez que j'ai eu le problème sur une autre base d'un autre serveur, tous
en
SQL Server 2000 SP3 FR.
Début de réponse: le lot DTS s'effectue à l'intérieur d'une seule transaction globale et par conséquent doit être capable de se faire à l'intérieur du 10% permis. Il semble donc que SQL-Server ne peut pas faire des augmentations successives à l'intérieur d'une seule transaction ou quelque chose du genre.
Pourquoi vous obstiner à revenir à 10%? Garder le 11% ou mettez une valeur absolue plutôt que proportionnelle.
Le modèle de sauvegarde du journal de transaction peut également avoir une importance ici.
S. L.
"Sébastien Carriot" wrote in message news:%
Bonjour,
Ce problème est assez rare et il n'y aucun caractère d'urgence à ce message. Je souhaitais simplement le poster car je retombe dessus tous les 2 mois environ et je voualis savoir si quelqu'un avait rencontré le même phénomène.
A savoir : j'ai une base en croissance automatique (qu'elle soit en pourcentage ou en croissance fixe) comportant un seul fichier. La base est assez importante (40 Go) mais se trouve sur un disque ayant autant d'espace disponible. Idem pour le journal : le disque est très loin d'être saturé.
Cette base est mise à jour toutes les nuits par des lots DTS pilotés en VB. Or de temps en temps (très rarement donc), j'ai un message d'erreur des lots DTS m'indiquant que le fichier Primary est plein. Dans l'observateur d'événements du serveur, même message. Je regarde alors les disques : 100 Go de libre. Je regarde l'état de la bdd et effectivement, 0% d'espace libre. Je teste à nouveau le lot DTS manuellement : même erreur.
Seule solution trouvée pour le moment : changer la valeur de croissance (passer de 10% à 11%). Valider. Revenir à 10%. Je relance le lot DTS et hop, ça passe.
Bizarre.....
Notez que j'ai eu le problème sur une autre base d'un autre serveur, tous en SQL Server 2000 SP3 FR.
Sébastien
Jean-Nicolas BERGER
Le fait que SQL Server ne puisse pas effectuer des Auto-grow multiples au sein d'une même transaction m'étonne beaucoup, d'autant plus qu'il me semble bien avoir lancé des transactions avec un taux de grossissement de 20%, un journal qui faisait 500Mo au début et 5 Go à la fin... Cette limitation n'est donc pas valable pour le journal. maintenant, l'est-elle pour la base...??? JN.
"Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam please)> a écrit dans le message de news:
Début de réponse: le lot DTS s'effectue à l'intérieur d'une seule transaction globale et par conséquent doit être capable de se faire à l'intérieur du 10% permis. Il semble donc que SQL-Server ne peut pas faire des augmentations successives à l'intérieur d'une seule transaction ou quelque chose du genre.
(...)
Le fait que SQL Server ne puisse pas effectuer des Auto-grow multiples au
sein d'une même transaction m'étonne beaucoup, d'autant plus qu'il me semble
bien avoir lancé des transactions avec un taux de grossissement de 20%, un
journal qui faisait 500Mo au début et 5 Go à la fin... Cette limitation
n'est donc pas valable pour le journal. maintenant, l'est-elle pour la
base...???
JN.
"Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam please)> a
écrit dans le message de news: e918k91wEHA.1564@TK2MSFTNGP09.phx.gbl...
Début de réponse: le lot DTS s'effectue à l'intérieur d'une seule
transaction globale et par conséquent doit être capable de se faire à
l'intérieur du 10% permis. Il semble donc que SQL-Server ne peut pas
faire des augmentations successives à l'intérieur d'une seule transaction
ou quelque chose du genre.
Le fait que SQL Server ne puisse pas effectuer des Auto-grow multiples au sein d'une même transaction m'étonne beaucoup, d'autant plus qu'il me semble bien avoir lancé des transactions avec un taux de grossissement de 20%, un journal qui faisait 500Mo au début et 5 Go à la fin... Cette limitation n'est donc pas valable pour le journal. maintenant, l'est-elle pour la base...??? JN.
"Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam please)> a écrit dans le message de news:
Début de réponse: le lot DTS s'effectue à l'intérieur d'une seule transaction globale et par conséquent doit être capable de se faire à l'intérieur du 10% permis. Il semble donc que SQL-Server ne peut pas faire des augmentations successives à l'intérieur d'une seule transaction ou quelque chose du genre.
(...)
Sylvain Lafontaine
Tel qu'indiqué dans le message (mais en d'autres mots), ce n'était qu'une hypothèse de recherche; personnellement, le problème ne s'est jamais posé pour moi lorsque j'utilise DTS. Le fait aussi que votre bdd ait grossi de 500Mo à 5Go en une seule opération ne signifie pas nécessairement que toute l'opération s'est effectuée à l'intérieur d'une seule et unique transaction. Tout dépend des différents paramètres utilisés.
Cependant, tout comme vous, je suis moi-même étonné d'un tel problème avec l'auto-croissance. Dans le cas de Sébastien, il y a aussi le fait que 10% de 40Go équivaut à 4Go en une seule étape; or 4Go est particulier puisqu'il correspond à la taille maximum d'un fichier en mode 32 bits; il y a peut-être un bug à ce niveau là.
S. L.
"Jean-Nicolas BERGER" wrote in message news:
Le fait que SQL Server ne puisse pas effectuer des Auto-grow multiples au sein d'une même transaction m'étonne beaucoup, d'autant plus qu'il me semble bien avoir lancé des transactions avec un taux de grossissement de 20%, un journal qui faisait 500Mo au début et 5 Go à la fin... Cette limitation n'est donc pas valable pour le journal. maintenant, l'est-elle pour la base...??? JN.
"Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam please)> a écrit dans le message de news:
Début de réponse: le lot DTS s'effectue à l'intérieur d'une seule transaction globale et par conséquent doit être capable de se faire à l'intérieur du 10% permis. Il semble donc que SQL-Server ne peut pas faire des augmentations successives à l'intérieur d'une seule transaction ou quelque chose du genre.
(...)
Tel qu'indiqué dans le message (mais en d'autres mots), ce n'était qu'une
hypothèse de recherche; personnellement, le problème ne s'est jamais posé
pour moi lorsque j'utilise DTS. Le fait aussi que votre bdd ait grossi de
500Mo à 5Go en une seule opération ne signifie pas nécessairement que toute
l'opération s'est effectuée à l'intérieur d'une seule et unique transaction.
Tout dépend des différents paramètres utilisés.
Cependant, tout comme vous, je suis moi-même étonné d'un tel problème avec
l'auto-croissance. Dans le cas de Sébastien, il y a aussi le fait que 10%
de 40Go équivaut à 4Go en une seule étape; or 4Go est particulier puisqu'il
correspond à la taille maximum d'un fichier en mode 32 bits; il y a
peut-être un bug à ce niveau là.
S. L.
"Jean-Nicolas BERGER" <jnbergerENLEVEZMOI@wanadoo.fr> wrote in message
news:ejWL6cPxEHA.2316@TK2MSFTNGP15.phx.gbl...
Le fait que SQL Server ne puisse pas effectuer des Auto-grow multiples au
sein d'une même transaction m'étonne beaucoup, d'autant plus qu'il me
semble bien avoir lancé des transactions avec un taux de grossissement de
20%, un journal qui faisait 500Mo au début et 5 Go à la fin... Cette
limitation n'est donc pas valable pour le journal. maintenant, l'est-elle
pour la base...???
JN.
"Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam please)> a
écrit dans le message de news: e918k91wEHA.1564@TK2MSFTNGP09.phx.gbl...
Début de réponse: le lot DTS s'effectue à l'intérieur d'une seule
transaction globale et par conséquent doit être capable de se faire à
l'intérieur du 10% permis. Il semble donc que SQL-Server ne peut pas
faire des augmentations successives à l'intérieur d'une seule transaction
ou quelque chose du genre.
Tel qu'indiqué dans le message (mais en d'autres mots), ce n'était qu'une hypothèse de recherche; personnellement, le problème ne s'est jamais posé pour moi lorsque j'utilise DTS. Le fait aussi que votre bdd ait grossi de 500Mo à 5Go en une seule opération ne signifie pas nécessairement que toute l'opération s'est effectuée à l'intérieur d'une seule et unique transaction. Tout dépend des différents paramètres utilisés.
Cependant, tout comme vous, je suis moi-même étonné d'un tel problème avec l'auto-croissance. Dans le cas de Sébastien, il y a aussi le fait que 10% de 40Go équivaut à 4Go en une seule étape; or 4Go est particulier puisqu'il correspond à la taille maximum d'un fichier en mode 32 bits; il y a peut-être un bug à ce niveau là.
S. L.
"Jean-Nicolas BERGER" wrote in message news:
Le fait que SQL Server ne puisse pas effectuer des Auto-grow multiples au sein d'une même transaction m'étonne beaucoup, d'autant plus qu'il me semble bien avoir lancé des transactions avec un taux de grossissement de 20%, un journal qui faisait 500Mo au début et 5 Go à la fin... Cette limitation n'est donc pas valable pour le journal. maintenant, l'est-elle pour la base...??? JN.
"Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam please)> a écrit dans le message de news:
Début de réponse: le lot DTS s'effectue à l'intérieur d'une seule transaction globale et par conséquent doit être capable de se faire à l'intérieur du 10% permis. Il semble donc que SQL-Server ne peut pas faire des augmentations successives à l'intérieur d'une seule transaction ou quelque chose du genre.
(...)
David T.
L'allocation d'un "bloc" de 4Go doit prendre un temps non négligeable et ce délai déclenche pt-être un timeout au niveau du DTS. Une croissance à taille fixe de qq centaines de Mo serait peut-être à essayer
-----Original Message----- Tel qu'indiqué dans le message (mais en d'autres mots),
ce n'était qu'une
hypothèse de recherche; personnellement, le problème ne
s'est jamais posé
pour moi lorsque j'utilise DTS. Le fait aussi que votre
bdd ait grossi de
500Mo à 5Go en une seule opération ne signifie pas
nécessairement que toute
l'opération s'est effectuée à l'intérieur d'une seule et
unique transaction.
Tout dépend des différents paramètres utilisés.
Cependant, tout comme vous, je suis moi-même étonné d'un
tel problème avec
l'auto-croissance. Dans le cas de Sébastien, il y a
aussi le fait que 10%
de 40Go équivaut à 4Go en une seule étape; or 4Go est
particulier puisqu'il
correspond à la taille maximum d'un fichier en mode 32
bits; il y a
peut-être un bug à ce niveau là.
S. L.
"Jean-Nicolas BERGER"
wrote in message
news:
Le fait que SQL Server ne puisse pas effectuer des Auto-
grow multiples au
sein d'une même transaction m'étonne beaucoup, d'autant
plus qu'il me
semble bien avoir lancé des transactions avec un taux
de grossissement de
20%, un journal qui faisait 500Mo au début et 5 Go à la
fin... Cette
limitation n'est donc pas valable pour le journal.
maintenant, l'est-elle
pour la base...??? JN.
"Sylvain Lafontaine" <sylvain aei ca (fill the blanks,
no spam please)> a
écrit dans le message de news:
Début de réponse: le lot DTS s'effectue à l'intérieur
d'une seule
transaction globale et par conséquent doit être
capable de se faire à
l'intérieur du 10% permis. Il semble donc que SQL-
Server ne peut pas
faire des augmentations successives à l'intérieur
d'une seule transaction
ou quelque chose du genre.
(...)
.
L'allocation d'un "bloc" de 4Go doit prendre un temps non
négligeable et ce délai déclenche pt-être un timeout au
niveau du DTS. Une croissance à taille fixe de qq
centaines de Mo serait peut-être à essayer
-----Original Message-----
Tel qu'indiqué dans le message (mais en d'autres mots),
ce n'était qu'une
hypothèse de recherche; personnellement, le problème ne
s'est jamais posé
pour moi lorsque j'utilise DTS. Le fait aussi que votre
bdd ait grossi de
500Mo à 5Go en une seule opération ne signifie pas
nécessairement que toute
l'opération s'est effectuée à l'intérieur d'une seule et
unique transaction.
Tout dépend des différents paramètres utilisés.
Cependant, tout comme vous, je suis moi-même étonné d'un
tel problème avec
l'auto-croissance. Dans le cas de Sébastien, il y a
aussi le fait que 10%
de 40Go équivaut à 4Go en une seule étape; or 4Go est
particulier puisqu'il
correspond à la taille maximum d'un fichier en mode 32
L'allocation d'un "bloc" de 4Go doit prendre un temps non négligeable et ce délai déclenche pt-être un timeout au niveau du DTS. Une croissance à taille fixe de qq centaines de Mo serait peut-être à essayer
-----Original Message----- Tel qu'indiqué dans le message (mais en d'autres mots),
ce n'était qu'une
hypothèse de recherche; personnellement, le problème ne
s'est jamais posé
pour moi lorsque j'utilise DTS. Le fait aussi que votre
bdd ait grossi de
500Mo à 5Go en une seule opération ne signifie pas
nécessairement que toute
l'opération s'est effectuée à l'intérieur d'une seule et
unique transaction.
Tout dépend des différents paramètres utilisés.
Cependant, tout comme vous, je suis moi-même étonné d'un
tel problème avec
l'auto-croissance. Dans le cas de Sébastien, il y a
aussi le fait que 10%
de 40Go équivaut à 4Go en une seule étape; or 4Go est
particulier puisqu'il
correspond à la taille maximum d'un fichier en mode 32
bits; il y a
peut-être un bug à ce niveau là.
S. L.
"Jean-Nicolas BERGER"
wrote in message
news:
Le fait que SQL Server ne puisse pas effectuer des Auto-
grow multiples au
sein d'une même transaction m'étonne beaucoup, d'autant
plus qu'il me
semble bien avoir lancé des transactions avec un taux
de grossissement de
20%, un journal qui faisait 500Mo au début et 5 Go à la
fin... Cette
limitation n'est donc pas valable pour le journal.
maintenant, l'est-elle
pour la base...??? JN.
"Sylvain Lafontaine" <sylvain aei ca (fill the blanks,
no spam please)> a
écrit dans le message de news:
Début de réponse: le lot DTS s'effectue à l'intérieur
d'une seule
transaction globale et par conséquent doit être
capable de se faire à
l'intérieur du 10% permis. Il semble donc que SQL-
Server ne peut pas
faire des augmentations successives à l'intérieur
d'une seule transaction
ou quelque chose du genre.
(...)
.
bruno reiter [MVP]
indépendement du problème de croissance, quel intérêt à générer de la croissance automatique et coûteuse alors que tu sais qu'il faut plus de place?
tailles ta base en fonction des besoins, éventuellement dans un job avant le passage du lot.
concernant la croissance du fichier log, les écritures dans le fichier log ne sont pas loggées, elles.
br
"Sébastien Carriot" wrote in message news:#
Bonjour,
Ce problème est assez rare et il n'y aucun caractère d'urgence à ce
message.
Je souhaitais simplement le poster car je retombe dessus tous les 2 mois environ et je voualis savoir si quelqu'un avait rencontré le même
phénomène.
A savoir : j'ai une base en croissance automatique (qu'elle soit en pourcentage ou en croissance fixe) comportant un seul fichier. La base est assez importante (40 Go) mais se trouve sur un disque ayant autant
d'espace
disponible. Idem pour le journal : le disque est très loin d'être saturé.
Cette base est mise à jour toutes les nuits par des lots DTS pilotés en
VB.
Or de temps en temps (très rarement donc), j'ai un message d'erreur des
lots
DTS m'indiquant que le fichier Primary est plein. Dans l'observateur d'événements du serveur, même message. Je regarde alors les disques : 100
Go
de libre. Je regarde l'état de la bdd et effectivement, 0% d'espace libre. Je teste à nouveau le lot DTS manuellement : même erreur.
Seule solution trouvée pour le moment : changer la valeur de croissance (passer de 10% à 11%). Valider. Revenir à 10%. Je relance le lot DTS et hop, ça passe.
Bizarre.....
Notez que j'ai eu le problème sur une autre base d'un autre serveur, tous
en
SQL Server 2000 SP3 FR.
Sébastien
indépendement du problème de croissance, quel intérêt à générer de la
croissance automatique et coûteuse alors que tu sais qu'il faut plus de
place?
tailles ta base en fonction des besoins, éventuellement dans un job avant le
passage du lot.
concernant la croissance du fichier log, les écritures dans le fichier log
ne sont pas loggées, elles.
br
"Sébastien Carriot" <sebastien@atinternet.com> wrote in message
news:#XVwMC1wEHA.3976@TK2MSFTNGP09.phx.gbl...
Bonjour,
Ce problème est assez rare et il n'y aucun caractère d'urgence à ce
message.
Je souhaitais simplement le poster car je retombe dessus tous les 2 mois
environ et je voualis savoir si quelqu'un avait rencontré le même
phénomène.
A savoir : j'ai une base en croissance automatique (qu'elle soit en
pourcentage ou en croissance fixe) comportant un seul fichier. La base est
assez importante (40 Go) mais se trouve sur un disque ayant autant
d'espace
disponible. Idem pour le journal : le disque est très loin d'être saturé.
Cette base est mise à jour toutes les nuits par des lots DTS pilotés en
VB.
Or de temps en temps (très rarement donc), j'ai un message d'erreur des
lots
DTS m'indiquant que le fichier Primary est plein. Dans l'observateur
d'événements du serveur, même message. Je regarde alors les disques : 100
Go
de libre. Je regarde l'état de la bdd et effectivement, 0% d'espace libre.
Je teste à nouveau le lot DTS manuellement : même erreur.
Seule solution trouvée pour le moment : changer la valeur de croissance
(passer de 10% à 11%). Valider. Revenir à 10%.
Je relance le lot DTS et hop, ça passe.
Bizarre.....
Notez que j'ai eu le problème sur une autre base d'un autre serveur, tous
indépendement du problème de croissance, quel intérêt à générer de la croissance automatique et coûteuse alors que tu sais qu'il faut plus de place?
tailles ta base en fonction des besoins, éventuellement dans un job avant le passage du lot.
concernant la croissance du fichier log, les écritures dans le fichier log ne sont pas loggées, elles.
br
"Sébastien Carriot" wrote in message news:#
Bonjour,
Ce problème est assez rare et il n'y aucun caractère d'urgence à ce
message.
Je souhaitais simplement le poster car je retombe dessus tous les 2 mois environ et je voualis savoir si quelqu'un avait rencontré le même
phénomène.
A savoir : j'ai une base en croissance automatique (qu'elle soit en pourcentage ou en croissance fixe) comportant un seul fichier. La base est assez importante (40 Go) mais se trouve sur un disque ayant autant
d'espace
disponible. Idem pour le journal : le disque est très loin d'être saturé.
Cette base est mise à jour toutes les nuits par des lots DTS pilotés en
VB.
Or de temps en temps (très rarement donc), j'ai un message d'erreur des
lots
DTS m'indiquant que le fichier Primary est plein. Dans l'observateur d'événements du serveur, même message. Je regarde alors les disques : 100
Go
de libre. Je regarde l'état de la bdd et effectivement, 0% d'espace libre. Je teste à nouveau le lot DTS manuellement : même erreur.
Seule solution trouvée pour le moment : changer la valeur de croissance (passer de 10% à 11%). Valider. Revenir à 10%. Je relance le lot DTS et hop, ça passe.
Bizarre.....
Notez que j'ai eu le problème sur une autre base d'un autre serveur, tous
