Erreur 1701 : taille maximale autorisée 8060*octets [Résolu]

[kritopal]

Bonjour à tous,

Je conçoit une nouvelle base de données, jusqu'ici tout va bien...
Sauf qu'en voulant modifier le type de donnée d'une colonne j'ai l'erreur suivante :

Msg*1701, Niveau*16, État*1, Ligne*1
Échec de création ou de modification de la table 'tbl_clients' parce que la taille minimale des lignes serait de 8064, 9 octets d'espace réservé interne compris. Cela dépasse la taille maximale autorisée pour les lignes de la table de 8060*octets.

Dans cette j'avais 5 colonnes nchar(1000) et 2 nvarchar(MAX), ce qui à priori ne doit pas poser de problème.
J'ai donc déporté ces colonnes sur une autre table et j'ai toujours le même problème.

Voici le script de création :

Code :

1
2
3
4
5
6
7
8
9
10
CREATE TABLE [dbo].[tbl_clients](
    [id_personne] [int] NOT NULL,
    [client_date_creation] [date] NULL,
    [client_nom_jeune_fille] [nvarchar](50) NULL,
    [client_num_ss] [nchar](14) NULL,
    [id_medecin] [int] NULL,
    [id_referent] [int] NULL,
    [date_ordonnance] [date] NULL,
    [id_mode_rappel] [tinyint] NULL,
 CONSTRAINT [PK_tbl_clients] PRIMARY KEY CLUSTERED

Mes recherches n'ont rien donné, je fais donc appel à vos connaissances.
D'avance merci pour vos réponses.

Bonne journée,
Pierre-Yves

[aieeeuuuuu]

Bonjour,

5 colonnes nchar(1000) et 2 nvarchar(MAX), ce qui à priori ne doit pas poser de problème.

Si justement 5 nchar(1000) = 5 X 2 X 1000 = 10 000 octets !

que stockez vous dans ces colonnes ?

vous pouvez passer en varchar(1000) ou nvarchar(1000).

[SQLpro]

De plus, utiliser du NVARCHAR pour des données latines c'est doubler le volume de la base pour rien !

A +

[kritopal]

Bonjour et merci pour vos réponses.
Même en supprimant les colonnes nchar(1000) j'ai le même problème ?

Dois-je supprimer et recréer la table ?

SQlpro>Merci pour la remarque

[elsuket]

Bonjour,

Code :

Je ne vois pas où sont les 5 colonnes nchar(1000) ...
Et le script est incomplet puisque les colonnes qui participent à la clé primaire ne sont pas spécifiées.

Sauf qu'en voulant modifier le type de donnée d'une colonne j'ai l'erreur suivante :

Quelle est l'instruction qui a provoqué cette erreur ?

Et pourquoi nchar(1000) ?

- en n[var]char, vous utilisez Unicode, donc deux octets par caractère, contrairement à [var]char qui lui utilise ASCII et donc un seul octet par caractère

- en utilisant du [n]char(1000), quelle que soit la longueur réelle des valeurs de chaîne de caractère que vous stockez dans une colonne de ce type, celles-ci occuperont de toute façon [2000] 1000 octets.
Est-ce bien nécessaire ? Passez en n[var]char !

N'utilisez Unicode que si vous allez stocker des chaînes dont les caractères peuvent être non-latins (provenant des langues asiatiques, de l'arabe, et bien d'autres, ...)

@++

[kritopal]

Merci pour la remarque sur la différence de stockage nvarchar et varchar.

Mais malgré l'absence de ces colonnes "gargantuesques" l'erreur est toujours là...

[aieeeuuuuu]

Postez le DDL de la table et le script de modification que vous tentez d'executer

[kritopal]

Bonsoir,

Je n'ai pas eu le temps de répondre avant mais voici les infos.
Script de création de la table :

Code :

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
CREATE TABLE [dbo].[tbl_clients](
    [id_personne] [int] NOT NULL,
    [client_date_creation] [date] NULL,
    [client_nom_jeune_fille] [nvarchar](50) NULL,
    [client_num_ss] [nchar](14) NULL,
    [id_medecin] [int] NULL,
    [id_referent] [smallint] NULL,
    [date_ordonnance] [date] NULL,
    [id_mode_rappel] [tinyint] NULL,
 CONSTRAINT [PK_tbl_clients] PRIMARY KEY CLUSTERED 
(
    [id_personne] ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]
) ON [PRIMARY]
 
GO
 
ALTER TABLE [dbo].[tbl_clients]  WITH CHECK ADD  CONSTRAINT [FK_tbl_clients_tbl_clients_modes_rappel] FOREIGN KEY([id_mode_rappel])
REFERENCES [dbo].[tbl_clients_modes_rappel] ([id_mode_rappel])
GO
 
ALTER TABLE [dbo].[tbl_clients] CHECK CONSTRAINT [FK_tbl_clients_tbl_clients_modes_rappel]
GO
 
ALTER TABLE [dbo].[tbl_clients]  WITH CHECK ADD  CONSTRAINT [FK_tbl_clients_tbl_personnes] FOREIGN KEY([id_personne])
REFERENCES [dbo].[tbl_personnes] ([id_personne])
GO
 
ALTER TABLE [dbo].[tbl_clients] CHECK CONSTRAINT [FK_tbl_clients_tbl_personnes]
GO

Et enfin en faisant :

Code :

ALTER TABLE tbl_clients ALTER COLUMN id_referent int

J'ai l'erreur suivante :

Msg*1701, Niveau*16, État*1, Ligne*1
Échec de création ou de modification de la table 'tbl_clients' parce que la taille minimale des lignes serait de 8064, 9 octets d'espace réservé interne compris. Cela dépasse la taille maximale autorisée pour les lignes de la table de 8060*octets.

Je vous remercie pour l'aide déjà apportée et pour celle que vous pourrez me fournir.
Bonne soirée,
Kri

[elsuket]

Enfin quelque chose de précis !
Vous remarquerez que si vous aviez respecté la charte de postage du forum, nous aurions tous été plus vite

Maintenant si je prends ce qui nous intéresse dans votre script, j'ai un peu de mal à y croire :

- la colonne id_personne est de type int, donc toute valeur y occupe 4 octets
- la colonne client_date_creation est de type date, donc toute valeur y occupe 3 octets
- la colonne client_nom_jeune_fille est de type nvarchar(50), donc dans le pire des cas toute valeur y occupe au maximum 100 octets
- client_num_ss est de type nchar(14), donc toute valeur occupe 28 octets
- id_medecin est de type int, donc toute valeur y occupe 4 octets
- id_referent est de type smallint, donc toute valeur y occupe 2 octets
- date_ordonnance est de type date, donc toute valeur y occupe 3 octets
- id_mode_rappel est de type tinyint, donc toute valeur y occupe 1 octet

Si nous faisons maintenant la somme des tailles des colonnes, nous sommes au maximum à 145 octets ...

Si j'exécute le lot suivant :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
CREATE TABLE [dbo].[tbl_clients](
[id_personne] [int] NOT NULL,
[client_date_creation] [date] NULL,
[client_nom_jeune_fille] [nvarchar](50) NULL,
[client_num_ss] [nchar](14) NULL,
[id_medecin] [int] NULL,
[id_referent] [smallint] NULL,
[date_ordonnance] [date] NULL,
[id_mode_rappel] [tinyint] NULL,
CONSTRAINT [PK_tbl_clients] PRIMARY KEY CLUSTERED
(
[id_personne] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]
 
GO
 
ALTER TABLE tbl_clients ALTER COLUMN id_referent int

J'obtiens :

Command(s) completed successfully.

Il est donc impossible que cette erreur se produise pour cette table, et les clés étrangères que j'ai du omettre pour que le script s'exécute n'y sont absolument pour rien.

Pour la colonne client_nom_jeune_fille, prévoyez-vous de stocker des caractères non-latins (provenant des alphabets asiatiques, arabe, hébreux, russe, sanscrit, ...) ? Si non, passez en varchar.

Pour la colonne client_num_ss, s'agit-il du numéro de sécurité sociale ?
Si tel est le cas, et si j'en crois ce que j'ai lu sur Wikipédia :

- il peut comprendre 15 caractères
- dans la mesure où ce sont uniquement des chiffres et que le premier chiffre ne peut pas être un zéro, pourquoi ne les avez-vous pas stocké dans une colonne de type entier ?
Avec un bigint vous seriez à 8 octets, sans compter la vitesse de recherche d'un bigint comparée à une chaîne de caractères.
Comme il est en plus probable que vous indexiez cette colonne, l'index sera plus petit, donc son parcours sera plus rapide

@++

[kritopal]

Bonjour et merci pour votre réponse (promis je relis la charte ).

Finalement j'ai résolu le problème en supprimant et re-créant la table.

J'ai l'impression que SQL-server avait "gardé en mémoire" les colonnes nvarchar créées précédemment

En tout les cas merci à tous pour vos conseils sur l'utilisation des types de données, je suis autodidacte et je suis friand d'avis sur mon travail.

Bonne journée à tous

[elsuket]

J'ai l'impression que SQL-server avait "gardé en mémoire" les colonnes nvarchar créées précédemment

La table a une certaine définition ou elle ne l'a pas.
SQL Server ne versionne pas les tables

Vous vous être peut-être fié aux colonnes que vous voyez dans l'explorateur d'objets, mais elle ne sont pas maintenues en tant réel (ce qui est normal, sinon imaginez le coût que cela pourrait avoir !)

@++