Capacités des champs dans la base SQL Server
Imer
-
micma -
micma -
Bonjour à tous,
j'ai une base de données SQL Server, lorsque je créé une table avec des champs de type char, la base me précise que la taille des champs ne peut exéder 8000 caractéres...
Mais lorsque je remplis ma table, les champs ont une capacités de tout au plus 2000 caractères...
Comment cela se fait-il???
Merci d'avance...
j'ai une base de données SQL Server, lorsque je créé une table avec des champs de type char, la base me précise que la taille des champs ne peut exéder 8000 caractéres...
Mais lorsque je remplis ma table, les champs ont une capacités de tout au plus 2000 caractères...
Comment cela se fait-il???
Merci d'avance...
A voir également:
- Capacités des champs dans la base SQL Server
- Base de registre - Guide
- Cybera server - Télécharger - Divers Réseau & Wi-Fi
- Ps3 media server - Télécharger - Divers Réseau & Wi-Fi
- Filezilla server - Télécharger - Téléchargement & Transfert
- Formules mathématiques de base - Télécharger - Études & Formations
23 réponses
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.)
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.)
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.
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.
Argleu !
les variable $objectifs et autres proviennent d'un formulaire ?
Si c'est le cas, alors ton serveur possède une faille de sécurité (SQL-Injection).
Démonstration:
Dans ton formulaire, je tape dans le champ $objectifs:
Et ton code va exécuter la requête suivante:
INSERT INTO projet VALUES('6', 'blabla', 'blabla', '','','',''); DELETE projet ; SELECT ('', 'blabla', 'blabla', 'blabla')
Et voilà !
Simplement en tapant un peu de texte dans un de tes formulaires, j'ai vidé une de tes tables SQL !
L'erreur de syntaxe qu'il te rapport vient sûrement du fait que tu as tapé une apostrophe (') dans un de tes champs.
Pour se protéger contre ce genre d'attaque, il est impératif de doubler les apostrophes dans tous les champs
("l'autre" devient "l''autre")
les variable $objectifs et autres proviennent d'un formulaire ?
Si c'est le cas, alors ton serveur possède une faille de sécurité (SQL-Injection).
Démonstration:
Dans ton formulaire, je tape dans le champ $objectifs:
','','',''); DELETE projet ; SELECT ('
Et ton code va exécuter la requête suivante:
INSERT INTO projet VALUES('6', 'blabla', 'blabla', '','','',''); DELETE projet ; SELECT ('', 'blabla', 'blabla', 'blabla')
Et voilà !
Simplement en tapant un peu de texte dans un de tes formulaires, j'ai vidé une de tes tables SQL !
L'erreur de syntaxe qu'il te rapport vient sûrement du fait que tu as tapé une apostrophe (') dans un de tes champs.
Pour se protéger contre ce genre d'attaque, il est impératif de doubler les apostrophes dans tous les champs
("l'autre" devient "l''autre")
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.
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.
Par contre est-ce que tu trouve normal que je ne puisse même pas stocker 3000 caractère par champs...
C'est possible:
- si les données dépassent la taille du champs.
ou
- si la taille total des données à insérer dépasse 8000 octets.
N'oublie pas qu'en nvarchar ou nchar, un caractères occupe 2 octets.
C'est possible:
- si les données dépassent la taille du champs.
ou
- si la taille total des données à insérer dépasse 8000 octets.
N'oublie pas qu'en nvarchar ou nchar, un caractères occupe 2 octets.
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
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?
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?
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...
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 ?)
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...
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).
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).
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...
Ca me fout le démon de me prendre la tête pour une simple taille de champs...
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!
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 ?
Enterprise Manager ?
Query Analyzer ?
Un programme en C#, en C++, en Java ?
A partir d'Excel ?
autre ?
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 ?
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 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????
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:
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">