Capacités des champs dans la base SQL Server

a taille des champs ne peut exéder 8000 caractéres...

C'est normal.
C'est une limite interne de SQL Server: un enregistrement ne peut pas dépasser 8000 octets (et des brouettes).

Il t'autorisera à créer une table qui peut potentiellement dépasser les 8 ko par enregistrement, et te laissera insérer des donnée dedans.

Mais si par malheur un des enregistrement dépasse 8 ko, l'INSERT ou l'UPDATE échouera lamentablement.

Il faut donc éviter de créer de telles tables.

Bon alors admettons que j'ai une table de 6,7 champs...
Dans 1 ou 2 d'entre eux j'aurais à mettre environ 3000 caractères et les autres beaucoup moins (pas plus de 1000 au grand maximum)....
Est-ce possible? Que me conseillerais-tu?

Est-ce possible?

C'est possible.
Mais certains INSERT ou UDPATE peuvent éventuellement échouer.
ça dépend de la taille maximale théorique d'une ligne de ta table.

Lorsque tu exécute l'ordre CREATE TABLE, si tu as un warning du genre:
"Warning: The table 'XXXX' has been created but its maximum row size (24027) exceeds the maximum number of bytes per row (8060). INSERT or UPDATE of a row in this table will fail if the resulting row length exceeds 8060 bytes."

Une insertion dans une telle table fonctionnera dans la plupart des cas, mais pourra éventuellement échouer si tes données dépassent les 8 ko.

Si tu as besoin de stocker de grandes quantité de données (et que tu n'a pas besoin d'utiliser ces données dans les clauses WHERE), il faut souvent mieux utiliser des champs de type TEXT ou IMAGE.

Par exemple, sur plusieurs appli sur lesquelles j'ai bossé, on stock des fichiers XML et des fichiers ZIP dans des champs de type TEXT et IMAGE.
(qui peuvent contenir jusqu'à 2 Go.)

Salut,
quoi que je fasse (type et longueur), je ne peux pas mettre plus de 1023 caractères par champs...
Je ne comprend pas, j'ai essayé sous Mysql et aucun problème, je met la taille que je veux et mes champs se remplissent très bien...
Je ne comprends pas....

quoi que je fasse (type et longueur), je ne peux pas mettre plus de 1023 caractères par champs..

Il y a un problème alors.
Quelle version de SQL Server utilises-tu ?

Quand tu dis que tu n'arrive pas à dépasser 1023 caractères, quel message d'erreur s'affiche quand tu fais ton INSERT ?
(Ou alors tu as vu ces 1024 dans le Query Analyzer ?)

Salut, heureusement que t'es la...
J'ai la vesrion 7.0. Pour le nombre de caractères je chope le contenu du champs, je le colle dans Word et après outils/stat
Voila...
Et au niveau des champs image, la base me réponds que je peux pas insérer de texte dedans ce qui me parait assez logique...

Pour le nombre de caractères je chope le contenu du champs, je le colle dans Word et après outils/stat

Si tu fais un copier-coller d'un champ à partir du Query Analyzer ou de l'Enterprise Manager, c'est normal qu'il soit coupé puisque ces logiciels n'affichent pas la totalité du contenu des champs.

Dans le Query Analyze:
Menu Tools > Options > onglet Results > "Maximum characters per column" > change la valeur.

Accesoirement, évite le copier-coller: ce n'est pas fiable.

Utilise un vrai client SQL (par exemple, une connexion ODBC sur ta base à partir de Excel).

J'y comprends rien, je viens d'essayer ce que tu m'as dis mais...

Qu'est-ce que tu ne comprend pas ?

Ben je comprends pas que se soit autant le merdier avec SQL Server alors qu'avec Mysql tout marche très bien...
Ca me fout le démon de me prendre la tête pour une simple taille de champs...

C'est pas le merdier du tout
Enfin pas trop

ça marche très bien, SQL Server.
(quand on ne dépasse pas les 8 ko par enregistrement ;-)

Ton problème de taille de champs, ce n'est pas un problème SQL server, c'est un problème avec ton client SQL qui tronque les champs.

Corrige le programme qui va interroger la base SQL.

Je manipule régulièrement des champs qui font plus de 3000 caractères sans problème.

Corrige le programme qui va interroger la base SQL.

Tu peux être un peu plus précis?
Car la en fait je suis en stage et c'est la première fois que je vois une base SQL server donc c'est un peu un ovni pour moi... Lol
Merci!

Avec quoi tu interroge le serveur SQL ?

Enterprise Manager ?
Query Analyzer ?
Un programme en C#, en C++, en Java ?
A partir d'Excel ?
autre ?

Je l'interroge avec Enterprise Manager...

ok... donc c'est normal:
Enterprise Manager coupe les champs au copier-coller.

Si un champ contient 3728 caractères, il ne te donnera que les 1023 premiers.

Ce n'est pas SQL Server qui pose problème, c'est Enterprise Manager.

Il faut prendre un autre moyen d'interroger la base SQL.
(un programme que tu créé toi-même, Excel ou encore le Query Analyzer)

Tu as appris à "programmer" en SQL ?

Je travaille en PHP mais j'ai query analyser d'installé sur mon poste aussi...

Je suis passé par Query Analyser et ça a marché, mes champs sont entièrement remplis...
Par contre, par la suite, je fais un affichage par l'intermédiaire de PHP et tout les caractères qui ont des accents ne ressortent pas correctement!!!!
Exemple :
texte original : Essai matière
texte à l'affichage : Essai matiŠre

Un autre mystère????

texte original : Essai matière
texte à l'affichage : Essai matiŠre

Un autre mystère????

Là c'est un problème avec le navigateur.

Quel jeu de caractères utilises-tu quand tu envoie les pages HTML ?
ascii seul, ISO-8859-1, UTF-8 ?

Si le caractère s'affiche mal, c'est que le navigateur n'a pas été capable de sélectionner le bon jeu de caractères.
Il faut l'aider en indiquant le jeu de caractères dans la page.

(Regarde par exemple dans les pages de CCM:

<META HTTP-EQUIV="Content-Type" content="text/html; charset=iso-8859-1">

Salut , merci d'avoir répondu...
J'ai essayé ce que tu m'as dis mais ça ne change rien...
Certaines personnes m'ont conseillé d'écrire les accents en html.
Exemple :
è >>> è

Et après en effet lors de l'affichage ça marche...
Une autre idée?

Il faut juste que tu fasse attention au jeu de caractères utilisé.

Soit tu utilise & agrave; et autres entités HTML pour être sûr que c'est bon, soit tu utilise directement le caractère retourné par la base de données dans la page HTML, mais en précisent le jeu de caractères (ce n'est peut-être pas iso-8859-1, c'est peut-être un autre).