Bonjour
j'ai un petit soucis avec une procédure de mise à jour :
lorsque je la lance, j'obtiens l'erreur suivante
Serveur : Msg 7102, Niveau 20, État 99, Procédure Vendeur_Modif, Ligne 5
Erreur interne SQL Server. Le gestionnaire de texte ne peut pas continuer
avec la présente instruction.
sur la msdn, je ne comprend pas trop ce à quoi c'es du (a priori parce la
ligne a été supprimée par une autre connection), or je suis le seul a bosser
sur la table...
il est egalement dit
-soit d'enlever l'option NOLOCK de la clause select, je veux bien mais
comme je ne l'ai pas mise, je ne vois pas où l'enlever.
-soit de changer le type de curseur (ok mais comment?)
Il est egalement précisé que ce pbm a été réglé par le SP2 de SQL7 , sauf
que j'ai SQL2000 en SP3...
il est a noter que je met 160 champs à jour avec quelques champs ntext...
Quelqu'un aurait il une idée, une voie, une solution?
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
Fred BROUARD
si le nombre d'octets mis à jour dépasse 8060 c'est normal.
Il n'est pas possible de mettre à jour une ligne de table de plus de 8060 octets en une seule passe.
D'autant plus si la table contient de nombreuses colonnes TEXT, pire si c'est du NTEXT.
Un SGBDR n'est pas un traitement de texte. 160 colonnes à modifier montre à l'évidence une absence de maîtrise des concepts de bases des SGBDR et du modèle relationnel en particulier.
A +
TopBidouille a écrit:
Bonjour j'ai un petit soucis avec une procédure de mise à jour : lorsque je la lance, j'obtiens l'erreur suivante Serveur : Msg 7102, Niveau 20, État 99, Procédure Vendeur_Modif, Ligne 5 Erreur interne SQL Server. Le gestionnaire de texte ne peut pas continuer avec la présente instruction.
sur la msdn, je ne comprend pas trop ce à quoi c'es du (a priori parce la ligne a été supprimée par une autre connection), or je suis le seul a bosser sur la table... il est egalement dit -soit d'enlever l'option NOLOCK de la clause select, je veux bien mais comme je ne l'ai pas mise, je ne vois pas où l'enlever. -soit de changer le type de curseur (ok mais comment?)
Il est egalement précisé que ce pbm a été réglé par le SP2 de SQL7 , sauf que j'ai SQL2000 en SP3...
il est a noter que je met 160 champs à jour avec quelques champs ntext... Quelqu'un aurait il une idée, une voie, une solution?
Merci Christophe
-- Frédéric BROUARD, MVP Microsoft SQL Server. Langage SQL / Delphi / web Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com ****************** mailto: ******************
si le nombre d'octets mis à jour dépasse 8060 c'est normal.
Il n'est pas possible de mettre à jour une ligne de table de plus de
8060 octets en une seule passe.
D'autant plus si la table contient de nombreuses colonnes TEXT, pire si
c'est du NTEXT.
Un SGBDR n'est pas un traitement de texte.
160 colonnes à modifier montre à l'évidence une absence de maîtrise des
concepts de bases des SGBDR et du modèle relationnel en particulier.
A +
TopBidouille a écrit:
Bonjour
j'ai un petit soucis avec une procédure de mise à jour :
lorsque je la lance, j'obtiens l'erreur suivante
Serveur : Msg 7102, Niveau 20, État 99, Procédure Vendeur_Modif, Ligne 5
Erreur interne SQL Server. Le gestionnaire de texte ne peut pas continuer
avec la présente instruction.
sur la msdn, je ne comprend pas trop ce à quoi c'es du (a priori parce la
ligne a été supprimée par une autre connection), or je suis le seul a bosser
sur la table...
il est egalement dit
-soit d'enlever l'option NOLOCK de la clause select, je veux bien mais
comme je ne l'ai pas mise, je ne vois pas où l'enlever.
-soit de changer le type de curseur (ok mais comment?)
Il est egalement précisé que ce pbm a été réglé par le SP2 de SQL7 , sauf
que j'ai SQL2000 en SP3...
il est a noter que je met 160 champs à jour avec quelques champs ntext...
Quelqu'un aurait il une idée, une voie, une solution?
Merci
Christophe
--
Frédéric BROUARD, MVP Microsoft SQL Server. Langage SQL / Delphi / web
Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html
Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com
****************** mailto:brouardf@club-internet.fr ******************
si le nombre d'octets mis à jour dépasse 8060 c'est normal.
Il n'est pas possible de mettre à jour une ligne de table de plus de 8060 octets en une seule passe.
D'autant plus si la table contient de nombreuses colonnes TEXT, pire si c'est du NTEXT.
Un SGBDR n'est pas un traitement de texte. 160 colonnes à modifier montre à l'évidence une absence de maîtrise des concepts de bases des SGBDR et du modèle relationnel en particulier.
A +
TopBidouille a écrit:
Bonjour j'ai un petit soucis avec une procédure de mise à jour : lorsque je la lance, j'obtiens l'erreur suivante Serveur : Msg 7102, Niveau 20, État 99, Procédure Vendeur_Modif, Ligne 5 Erreur interne SQL Server. Le gestionnaire de texte ne peut pas continuer avec la présente instruction.
sur la msdn, je ne comprend pas trop ce à quoi c'es du (a priori parce la ligne a été supprimée par une autre connection), or je suis le seul a bosser sur la table... il est egalement dit -soit d'enlever l'option NOLOCK de la clause select, je veux bien mais comme je ne l'ai pas mise, je ne vois pas où l'enlever. -soit de changer le type de curseur (ok mais comment?)
Il est egalement précisé que ce pbm a été réglé par le SP2 de SQL7 , sauf que j'ai SQL2000 en SP3...
il est a noter que je met 160 champs à jour avec quelques champs ntext... Quelqu'un aurait il une idée, une voie, une solution?
Merci Christophe
-- Frédéric BROUARD, MVP Microsoft SQL Server. Langage SQL / Delphi / web Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com ****************** mailto: ******************
TopBidouille
Bonjour, efectivement, en effectuant ma requete en plusieurs fois, ca passe. (mais c'est tres long -il faut dire que j'attaque un serveur lié Access) En ce qui concerne "l'absence de maitrise des concepts des base SGBDR et du modèle relationnel en particulier", il faut d'abord connaitre la base de données en question avant de pouvoir donner un jugement (qui pourrait sembler hatif). Je vous expliquerai simplement, qu'en ce qui concerne cette table elle collecte les informations de 130 agences reparties sur toute la france d'une appli ACCESS (donc pas de client serveur possible pour les mises a jour) et expliquez moi donc comment etre certain de ne pas manquer la modification d'un seul champ sur les données distantes sans refaire l'appli existante ou en tout cas lui faire une tres serieuse mise a jour) (chose qui est exclue par les plus hautes instances que moi). Je suis totalement d'accord sur le fait que les relations 1-1 peuvent etre utiles lorsque les utilisateurs (que ce soient ceux qui saisissent ou ceux qui exploitent) n'ont pas besoin de toute l'information sur l'entité mais il est des cas ou avoir tout les champs se rapportant a une entité dans la table peut se révéler utile. (lorsque nous avons besoins de TOUS les champs en sortie systematiquement -à quelques un près - et a ce moment là eviter de "reconstruire" la table entière via les liens 1-1 ) En ce qui concerne "la base de données qui n'est pas un traitement de texte..." je suis au regret de vous dire que certaines bases servent à faire des supports publicitaires avec un joli texte publicitaire et des commentaires pour les collègues qui reprennent la suite.
En conclusion, je vai d'abord inserer toutes mes valeurs à modifier dans une table SQL Tempo et traiterai tout en sql au lieu d'attaquer la base Access depuis SQL afin d'accélerer le taitement.
Merci pour la réponse. a+ Christophe "Fred BROUARD" a écrit dans le message de news:
si le nombre d'octets mis à jour dépasse 8060 c'est normal.
Il n'est pas possible de mettre à jour une ligne de table de plus de 8060 octets en une seule passe.
D'autant plus si la table contient de nombreuses colonnes TEXT, pire si c'est du NTEXT.
Un SGBDR n'est pas un traitement de texte. 160 colonnes à modifier montre à l'évidence une absence de maîtrise des concepts de bases des SGBDR et du modèle relationnel en particulier.
A +
TopBidouille a écrit: > Bonjour > j'ai un petit soucis avec une procédure de mise à jour : > lorsque je la lance, j'obtiens l'erreur suivante > Serveur : Msg 7102, Niveau 20, État 99, Procédure Vendeur_Modif, Ligne
5
> Erreur interne SQL Server. Le gestionnaire de texte ne peut pas
continuer
> avec la présente instruction. > > > sur la msdn, je ne comprend pas trop ce à quoi c'es du (a priori parce
la
> ligne a été supprimée par une autre connection), or je suis le seul a
bosser
> sur la table... > il est egalement dit > -soit d'enlever l'option NOLOCK de la clause select, je veux bien
mais
> comme je ne l'ai pas mise, je ne vois pas où l'enlever. > -soit de changer le type de curseur (ok mais comment?) > > Il est egalement précisé que ce pbm a été réglé par le SP2 de SQL7 ,
sauf
> que j'ai SQL2000 en SP3... > > il est a noter que je met 160 champs à jour avec quelques champs
ntext...
> Quelqu'un aurait il une idée, une voie, une solution? > > Merci > Christophe > > >
-- Frédéric BROUARD, MVP Microsoft SQL Server. Langage SQL / Delphi / web Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com ****************** mailto: ******************
Bonjour,
efectivement, en effectuant ma requete en plusieurs fois, ca passe. (mais
c'est tres long -il faut dire que j'attaque un serveur lié Access)
En ce qui concerne "l'absence de maitrise des concepts des base SGBDR et du
modèle relationnel en particulier", il faut d'abord connaitre la base de
données en question avant de pouvoir donner un jugement (qui pourrait
sembler hatif).
Je vous expliquerai simplement, qu'en ce qui concerne cette table elle
collecte les informations de 130 agences reparties sur toute la france d'une
appli ACCESS (donc pas de client serveur possible pour les mises a jour) et
expliquez moi donc comment etre certain de ne pas manquer la modification
d'un seul champ sur les données distantes sans refaire l'appli existante ou
en tout cas lui faire une tres serieuse mise a jour) (chose qui est exclue
par les plus hautes instances que moi).
Je suis totalement d'accord sur le fait que les relations 1-1 peuvent etre
utiles lorsque les utilisateurs (que ce soient ceux qui saisissent ou ceux
qui exploitent) n'ont pas besoin de toute l'information sur l'entité mais il
est des cas ou avoir tout les champs se rapportant a une entité dans la
table peut se révéler utile. (lorsque nous avons besoins de TOUS les
champs en sortie systematiquement -à quelques un près - et a ce moment là
eviter de "reconstruire" la table entière via les liens 1-1 )
En ce qui concerne "la base de données qui n'est pas un traitement de
texte..." je suis au regret de vous dire que certaines bases servent à faire
des supports publicitaires avec un joli texte publicitaire et des
commentaires pour les collègues qui reprennent la suite.
En conclusion, je vai d'abord inserer toutes mes valeurs à modifier dans une
table SQL Tempo et traiterai tout en sql au lieu d'attaquer la base Access
depuis SQL afin d'accélerer le taitement.
Merci pour la réponse.
a+
Christophe
"Fred BROUARD" <brouardf@club-internet.fr> a écrit dans le message de
news:u9F8A8WAEHA.3828@TK2MSFTNGP10.phx.gbl...
si le nombre d'octets mis à jour dépasse 8060 c'est normal.
Il n'est pas possible de mettre à jour une ligne de table de plus de
8060 octets en une seule passe.
D'autant plus si la table contient de nombreuses colonnes TEXT, pire si
c'est du NTEXT.
Un SGBDR n'est pas un traitement de texte.
160 colonnes à modifier montre à l'évidence une absence de maîtrise des
concepts de bases des SGBDR et du modèle relationnel en particulier.
A +
TopBidouille a écrit:
> Bonjour
> j'ai un petit soucis avec une procédure de mise à jour :
> lorsque je la lance, j'obtiens l'erreur suivante
> Serveur : Msg 7102, Niveau 20, État 99, Procédure Vendeur_Modif, Ligne
5
> Erreur interne SQL Server. Le gestionnaire de texte ne peut pas
continuer
> avec la présente instruction.
>
>
> sur la msdn, je ne comprend pas trop ce à quoi c'es du (a priori parce
la
> ligne a été supprimée par une autre connection), or je suis le seul a
bosser
> sur la table...
> il est egalement dit
> -soit d'enlever l'option NOLOCK de la clause select, je veux bien
mais
> comme je ne l'ai pas mise, je ne vois pas où l'enlever.
> -soit de changer le type de curseur (ok mais comment?)
>
> Il est egalement précisé que ce pbm a été réglé par le SP2 de SQL7 ,
sauf
> que j'ai SQL2000 en SP3...
>
> il est a noter que je met 160 champs à jour avec quelques champs
ntext...
> Quelqu'un aurait il une idée, une voie, une solution?
>
> Merci
> Christophe
>
>
>
--
Frédéric BROUARD, MVP Microsoft SQL Server. Langage SQL / Delphi / web
Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html
Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com
****************** mailto:brouardf@club-internet.fr ******************
Bonjour, efectivement, en effectuant ma requete en plusieurs fois, ca passe. (mais c'est tres long -il faut dire que j'attaque un serveur lié Access) En ce qui concerne "l'absence de maitrise des concepts des base SGBDR et du modèle relationnel en particulier", il faut d'abord connaitre la base de données en question avant de pouvoir donner un jugement (qui pourrait sembler hatif). Je vous expliquerai simplement, qu'en ce qui concerne cette table elle collecte les informations de 130 agences reparties sur toute la france d'une appli ACCESS (donc pas de client serveur possible pour les mises a jour) et expliquez moi donc comment etre certain de ne pas manquer la modification d'un seul champ sur les données distantes sans refaire l'appli existante ou en tout cas lui faire une tres serieuse mise a jour) (chose qui est exclue par les plus hautes instances que moi). Je suis totalement d'accord sur le fait que les relations 1-1 peuvent etre utiles lorsque les utilisateurs (que ce soient ceux qui saisissent ou ceux qui exploitent) n'ont pas besoin de toute l'information sur l'entité mais il est des cas ou avoir tout les champs se rapportant a une entité dans la table peut se révéler utile. (lorsque nous avons besoins de TOUS les champs en sortie systematiquement -à quelques un près - et a ce moment là eviter de "reconstruire" la table entière via les liens 1-1 ) En ce qui concerne "la base de données qui n'est pas un traitement de texte..." je suis au regret de vous dire que certaines bases servent à faire des supports publicitaires avec un joli texte publicitaire et des commentaires pour les collègues qui reprennent la suite.
En conclusion, je vai d'abord inserer toutes mes valeurs à modifier dans une table SQL Tempo et traiterai tout en sql au lieu d'attaquer la base Access depuis SQL afin d'accélerer le taitement.
Merci pour la réponse. a+ Christophe "Fred BROUARD" a écrit dans le message de news:
si le nombre d'octets mis à jour dépasse 8060 c'est normal.
Il n'est pas possible de mettre à jour une ligne de table de plus de 8060 octets en une seule passe.
D'autant plus si la table contient de nombreuses colonnes TEXT, pire si c'est du NTEXT.
Un SGBDR n'est pas un traitement de texte. 160 colonnes à modifier montre à l'évidence une absence de maîtrise des concepts de bases des SGBDR et du modèle relationnel en particulier.
A +
TopBidouille a écrit: > Bonjour > j'ai un petit soucis avec une procédure de mise à jour : > lorsque je la lance, j'obtiens l'erreur suivante > Serveur : Msg 7102, Niveau 20, État 99, Procédure Vendeur_Modif, Ligne
5
> Erreur interne SQL Server. Le gestionnaire de texte ne peut pas
continuer
> avec la présente instruction. > > > sur la msdn, je ne comprend pas trop ce à quoi c'es du (a priori parce
la
> ligne a été supprimée par une autre connection), or je suis le seul a
bosser
> sur la table... > il est egalement dit > -soit d'enlever l'option NOLOCK de la clause select, je veux bien
mais
> comme je ne l'ai pas mise, je ne vois pas où l'enlever. > -soit de changer le type de curseur (ok mais comment?) > > Il est egalement précisé que ce pbm a été réglé par le SP2 de SQL7 ,
sauf
> que j'ai SQL2000 en SP3... > > il est a noter que je met 160 champs à jour avec quelques champs
ntext...
> Quelqu'un aurait il une idée, une voie, une solution? > > Merci > Christophe > > >
-- Frédéric BROUARD, MVP Microsoft SQL Server. Langage SQL / Delphi / web Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com ****************** mailto: ******************
