[SQL Server 7]Problème de taille d'une row

**zaventem** · 06/08/2008, 11h43

Bonjour,

Comme l'indique le titre, je suis confronté à un problème plutôt ennuyant avec une table centrale d'une application historique dont j'assure tant bien que mal la survie.

L'erreur provient de la taille des données insérées dans les champs de type text

qui contre toute attente semble être sinon stockée entièrement dans la row, du moins en grande partie.

Voici un exemple de message obtenu

Envoyé par SQL server

Cannot create a row of size 15107 which is greater than the allowable maximum of 8060.

J'ai tenté d'utilisée la procédure sp_tableoption de la manière suivante

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

EXEC sp_tableoption 'matable', 'text in row', 'off'

mais cela ne semble être supporté qu'à partir de la version 8

Pour compliquer les choses, la même table est attaquée par une application sur laquelle nous ne pouvons apporter aucune modification, on ne peux donc pas modifier la structure de la base ou u moins, cela doit être totalement transparent.
Auriez-vous une autre piste à explorer?

Merci beaucoup

Pour info voici le monstre (tatapay, j'y suis pour rien, j'en souffre tout les jours

)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
 
CREATE TABLE [dbo].[matable] (
	[ref_ibis] [int] NOT NULL ,
	[firme_toto] [varchar] (50) NULL ,
	[firme_bis_toto] [varchar] (50) NULL ,
	[ident_toto] [varchar] (4) NULL ,
	[login_toto] [varchar] (32) NULL ,
	[nom_gestionnaire_toto] [varchar] (50) NULL ,
	[prenom_gestionnaire_toto] [varchar] (30) NULL ,
	[code_titre_gestionnaire_toto] [char] (1) NULL ,
	[date_reception_toto] [smalldatetime] NULL ,
	[rue_toto] [varchar] (250) NULL ,
	[numero_toto] [char] (15) NULL ,
	[boite_toto] [char] (15) NULL ,
	[cp_commune_toto] [varchar] (30) NULL ,
	[nom_commune_toto] [varchar] (250) NULL ,
	[e_mail_toto] [varchar] (100) NULL ,
	[web_toto] [varchar] (50) NULL ,
	[fax_toto] [varchar] (50) NULL ,
	[gsm_toto] [varchar] (50) NULL ,
	[telephone_toto] [varchar] (50) NULL ,
	[telephone2_toto] [varchar] (50) NULL ,
	[lang_mat_demandee_toto] [char] (5) NULL ,
	[lang_document_toto] [char] (5) NULL ,
	[age_max_toto] [smallint] NULL ,
	[age_min_toto] [smallint] NULL ,
	[act_pas_sus_toto] [char] (1) NULL ,
	[type_offre_toto] [varchar] (5) NULL ,
	[date_mouv_93_toto] [smalldatetime] NULL ,
	[horaire_toto] [varchar] (5) NULL ,
	[local_toto] [varchar] (30) NULL ,
	[langue_93_toto] [char] (5) NULL ,
	[nbr_poste_toto] [int] NULL ,
	[code_activite_toto] [char] (5) NULL ,
	[motif_modif_toto] [varchar] (250) NULL ,
	[code_mode_presentation_toto] [char] (2) NULL ,
	[mode_presentation_toto] [varchar] (250) NULL ,
	[nom_personne_contact_toto] [varchar] (50) NULL ,
	[prenom_personne_contact_toto] [varchar] (30) NULL ,
	[titre_personne_contact_toto] [varchar] (30) NULL ,
	[temps_partiel_toto] [varchar] (3) NULL ,
	[duree_hebd_theorique_toto] [varchar] (2) NULL ,
	[niv_responsabilite_toto] [varchar] (2) NULL ,
	[examen_SPR_toto] [varchar] (240) NULL ,
	[permis_conduire_toto] [varchar] (5) NULL ,
	[vehicule_toto] [char] (5) NULL ,
	[libelle_stat_etudes_toto] [varchar] (250) NULL ,
	[c_profession_1_toto] [int] NULL ,
	[c_profession_2_toto] [int] NULL ,
	[agenda_toto] [text] NULL ,
	[adresse_toto] [text] NULL ,
	[resp_eng_toto] [text] NULL ,
	[present_toto] [text] NULL ,
	[job_toto] [text] NULL ,
	[descript_toto] [text] NULL ,
	[langues_toto] [text] NULL ,
	[etudes_fp_toto] [text] NULL ,
	[condit_toto] [text] NULL ,
	[modific_toto] [text] NULL ,
	[divers_toto] [text] NULL ,
	[nb_jours_diff_toto] [int] NULL ,
	[code_diff_toto] [varchar] (15) NULL ,
	[code_trt_diff_toto] [varchar] (30) NULL ,
	[lang_dossier] [char] (1) NULL ,
	[telephone_cellule] [varchar] (12) NULL ,
	[telephone_diffuse] [char] (12) NULL ,
	[presentation_fr] [text] NULL ,
	[presentation_nl] [text] NULL ,
	[en_tete_fr] [text] NULL ,
	[job_fr] [text] NULL ,
	[job_short_fr] [text] NULL ,
	[statut_job_fr] [smallint] NULL ,
	[en_tete_nl] [text] NULL ,
	[job_nl] [text] NULL ,
	[job_short_nl] [text] NULL ,
	[statut_job_nl] [smallint] NULL ,
	[vers_site] [char] (1) NULL ,
	[vers_jobphone] [char] (1) NULL ,
	[vers_rtbf] [char] (1) NULL ,
	[vers_vrt] [char] (1) NULL ,
	[vers_forem] [char] (1) NULL ,
	[vers_radio] [char] (1) NULL ,
	[vers_presse] [char] (1) NULL ,
	[vers_tvinterne] [char] (1) NULL ,
	[vers_eures] [char] (1) NULL ,
	[id_matiere_gr] [varchar] (3) NULL ,
	[id_matiere] [varchar] (3) NULL ,
	[critere_duree] [smallint] NULL ,
	[critere_experience] [smallint] NULL ,
	[critere_lieu] [smallint] NULL ,
	[critere_interim] [smallint] NULL ,
	[date_demarrage] [datetime] NULL ,
	[date_fin] [datetime] NULL ,
	[date_derniere_modif] [datetime] NULL ,
	[compteur_jours_diff] [int] NULL ,
	[statut_impression] [char] (1) NULL ,
	[date_impression] [smalldatetime] NULL ,
	[nb_impression] [smallint] NULL ,
	[description_tv] [text] NULL ,
	[ligne1_tv] [varchar] (37) NULL ,
	[ligne2_tv] [varchar] (37) NULL ,
	[ligne3_tv] [varchar] (37) NULL ,
	[ligne4_tv] [varchar] (37) NULL ,
	[ligne5_tv] [varchar] (37) NULL ,
	[ligne6_tv] [varchar] (37) NULL ,
	[ligne7_tv] [varchar] (37) NULL ,
	[ligne8_tv] [varchar] (37) NULL ,
	[ligne9_tv] [varchar] (37) NULL ,
	[statut] [char] (1) NOT NULL ,
	[row_cre] [varchar] (25) NOT NULL ,
	[row_mod] [varchar] (25) NOT NULL ,
	[row_lock] [varchar] (25) NULL ,
	[Anonyme] [char] (1) NULL ,
	[flg_vw] [varchar] (1) NULL ,
	[dt_debut_diffusion_web] [datetime] NULL ,
	[dt_fin_diffusion_web] [datetime] NULL 
)

**ylarvor** · 06/08/2008, 12h04

remplacer votre table par une vue qui pointe sur des tables jointes, vous gagnerez de l'espace pour vos blob et vos table seront correctement modelise. double gain.

**zaventem** · 06/08/2008, 12h27

Envoyé par ylarvor

remplacer votre table par une vue qui pointe sur des tables jointes, vous gagnerez de l'espace pour vos blob et vos table seront correctement modelise. double gain.

Merci pour cette réponse mais je crains fortement que cette solution ne soit pas compatible avec l'application existante (non modifiable pour rappel).

D'autre part, celle-ci me limitera toujours à des textes de 8000 caractères (à une couille de mouche près)

Invité · 06/08/2008, 13h05

Je crois qu'une ligne ne peut pas dépasser la taille d'une page de données, soit 8192 octets moins 132 octets d'en-tête de page, soit 8060 octets.

Ok, je ne t'apporte pas de solution, mais juste une information de taille (sans mauvais jeu de mots). Mais je ne vois pas d'autre solution que de modifier la structure de la table.

**ylarvor** · 06/08/2008, 13h08

vous m'étonnez quand même, je croyais que c'était le type VARCHAR qui était limité à 8000 caractères sur SQL Serveur 7 et 2000.

Le type Text dans ma mémoire est un BLOB qui dépasse les capacités de la page.

Par conséquent, votre erreur proviendrait plutôt de vos VARCHAR qui dépasse la capacité d'une page. non ? M'enfin, j'en sais trop rien!

Quand à la modélisation, il suffit de créer les tables, renseigner les données, supprimer l'ancienne table, créé la vue avec le meme nom.

Pour info, votre organisation devrait s'adapter... SQL Serveur 7 a 10 ans au moins. Passez au minimum sur 2000.

**zaventem** · 06/08/2008, 14h10

Envoyé par kuzco

Je crois qu'une ligne ne peut pas dépasser la taille d'une page de données, soit 8192 octets moins 132 octets d'en-tête de page, soit 8060 octets.

Effectivement, c'est le cas néanmoins certains types de données sont stockés en dehors de la row celle-ci ne contenant qu'un lien. Par exemple dans mon cas, un texte de 2Gb (c'est le maximum) ne devrais occuper que 16 octets (edit: 16 octets dans la row, on fait pas de miracle

).

Envoyé par ylarvor

vous m'étonnez quand même, je croyais que c'était le type VARCHAR qui était limité à 8000 caractères sur SQL Serveur 7 et 2000.

Le type Text dans ma mémoire est un BLOB qui dépasse les capacités de la page.

C'est le cas mais il semble que pour des raisons de performances, il soit possible qu'une partie du BLOB soit stocké directement dans la row

Voici ce qu'en dit l'aide de SQL Server 2000

Using text in row
In Microsoft SQL Server 2000, users can enable a text in row option on a table so it could store text, ntext, or image data in its data row.

To enable the option, execute the sp_tableoption stored procedure, specifying text in row as the option name and on as the option value. The default maximum size that can be stored in a row for a BLOB (binary large object: text, ntext, or image data) is 256 bytes, but values may range from 24 through 7000. To specify a maximum size that is not the default, specify an integer within the range as the option value.

text, ntext, or image strings are stored in the data row if the following conditions apply:
text in row is enabled.

The length of the string is shorter than the limit specified in @OptionValue

There is enough space available in the data row.
When BLOB strings are stored in the data row, reading and writing the text, ntext, or image strings can be as fast as reading or writing character and binary strings. SQL Server does not have to access separate pages to read or write the BLOB string.

If a text, ntext, or image string is larger than the specified limit or the available space in the row, pointers are stored in the row instead. The conditions for storing the BLOB strings in the row still apply though: There must be enough space in the data row to hold the pointers.

Ce facteur expliquerait admirablement bien l'origine de mes tourments mais les plus anciennes infos que je trouvent date de SQL 2000. Les joies de travailler avec des vieilles versions plus supportées...

Envoyé par ylarvor

Par conséquent, votre erreur proviendrait plutôt de vos VARCHAR qui dépasse la capacité d'une page. non ?

C'est la première chose que j'ai vérifiée. La taille maximale de la row (hors ces fichus champs textes) est de +/- 3000 octets, je suis bien lion de la limite donc.

Envoyé par ylarvor

Quand à la modélisation, il suffit de créer les tables, renseigner les données, supprimer l'ancienne table, créé la vue avec le meme nom.

Disons que j'ai de très mauvaises expériences de tentatives d'UPDATE sur des vues