[SQL] update in SQL db fout door te grote row

[Verwijderd]

Ha hallo,
ik krijg de volgende melding als ik een item wil wijzigen en ga opslaan in SQL

Microsoft OLE DB Provider for ODBC Drivers error '80040e14'

[Microsoft][ODBC SQL Server Driver][SQL Server]Cannot create a row of size 8282 which is greater than the allowable maximum of 8060.

/input/programm/beheer_programmas.asp, line 415

Het rare vind ik dat ik bekend ben met de limitaties op de verschillende data type velden maar niet op het totaal van een item?

Kan iemand mij dit uitleggen?
Ik weet zeker dat het geen foutmelding is doordat er teveel data in een veld staat. (alle velden varchar 8000)

groet Niek

[Feyd-Rautha]

Zet eens voor alle velden een goed datatype. Op die manier zullen uw rows zo groot niet zijn en zal MSSQL er wel overweg mee kunnen.

Trouwens, volgens mij is die max. rowsize een parameter die je ergens zult moeten kunnen aanpassen. Maar ik betwijfel het of je dit nog zult kunnen na de creatie van uw databank

[DeverauX]

http://msdn.microsoft.com.../tr_reslsyserr_1_20hd.asp
Oorzaak is, zoals de foutmelding zelf al aangeeft, dat je niet meer dan 8060 bytes kan inserten.

[Verwijderd]

Probeer in plaats van varchar(8000) het type text.

[whoami]

Een file in Sql Server waar data in opgeslagen wordt, bestaat uit 'pages'. Zo'n page is 8KB groot, dat wil dus zeggen dat er 128 pages zijn in 1 megabyte.
De eerste 96 bytes van zo'n page zijn gereserveerd voor informatie over die page: het type page, het aantal vrije ruimte op die page, ....
Een rij (record) kan niet over meer dan 1 page opgeslagen zijn. Dat wil dus zeggen dat je record grootte niet groter mag zijn dan 8060 bytes (gegevens die in een text , ntext of image veld zitten, worden zowiezo op een aparte page opgeslagen, en daar wordt dus geen rekening mee gehouden).

Echter, als je tegen die beperking oploopt, dan denk ik dat er toch wat schort aan je datamodel hoor....
slindenau's oplossing (een type text gebruiken ipv varchar(8000)) zal je probleem dus kunnen oplossen, aangezien die text-velden niet op dezelfde page als de rest van je record worden opgeslagen.

[Annie]

whoami schreef op 22 januari 2004 @ 19:19:
aangezien die text-velden niet op dezelfde page als de rest van je record worden opgeslagen.

Tenzij je de 'text in row' optie gebruikt en de data 'past' in de page en/of voldoet aan je ingestelde 'text in row' limiet.

@TS: als je je tables aanmaakt in de QA krijg je een warning wanneer je rowsize te groot is, maar zelf meerekenen in de EM design mode kan natuurlijk ook.

[ Voor 11% gewijzigd door Annie op 22-01-2004 22:19 ]

[whoami]

Annie schreef op 22 januari 2004 @ 22:18:
[...]
Tenzij je de 'text in row' optie gebruikt.

Hmmm, dat zou ook maar gek zijn. Eigenlijk is die optie imo zinloos.

Een text veld ga je normaal gezien gaan gebruiken als je grote hoeveelheden data moet opslaan, en dan loop je toch gegarandeerd tegen die error aan die de TS ook heeft.
Ik snap niet waarom je die 'text in row' zou willen gebruiken, behalve als je weet dat de maximale recordgrootte niet overschreden wordt, echter, als je dat weet, dan kan je evengoed een varchar gebruiken.

[Verwijderd]

Bedankt voor jullie reacties.

Zal morgen eens aan de slag gaan met het aanpassen van de data velden. (text ipv varchar)

Groet Niek

[Annie]

whoami schreef op 22 januari 2004 @ 22:21:
Ik snap niet waarom je die 'text in row' zou willen gebruiken

Ik ben zelf ook nog geen situatie tegengekomen waarin ik dit zou willen gebruiken (als ik die uberhaupt al ooit tegen ga komen), maar een voordeel van de data in de row is dat er geen extra page access nodig is bij het ophalen van de data wat dus performance-wise beter uit zou moeten pakken. Ik heb alleen geen voorbeelden of benchdata dus of het ook _echt_ wat uitmaakt durf ik niet te zeggen.

Om mezelf meteen maar weer tegen te spreken heb je natuurlijk het probleem dat hoe groter je text in de row is des te minder rows er in je page passen wat dus weer een (mogelijk) negatief effect heeft op je performance.

note-to-self: niet al te veel nadenken na 11 uur 's avonds
* Annie gaat er eens een nachtje over slapen

[P_de_B]

@Niek: hou er wel rekening mee dat TEXT/NTEXT niet zo eenvoudig in de omgang zijn als 'gewone' velden. Indien er een mogelijkheid is dit te vermijden moet je dit zeker doen.

Als ik je goed begrijp ga je meerdere TEXT velden in 1 tabel toepassen?

[Verwijderd]

Daar ben ik achter gekomen dat het geen gewoon veld is, krijg meteen allerlei foutmeldingen in de asp pagina's.

Ik werk toch nu al een tijd met sql databases maar ik meot zeggen dat ik het toch wel raar vind.

Afgezien van enkele bit en varchar (50) velden zitten er 5 velden van varchar (was 8000) 4000. Er staat ook behoorlijk wat teskt in. Nu ik deze vijf velden van 8000 naar 4000 heb gezet kan ik nog steeds niet meer dan twee woorden toevoegen (ongeacht welk veld ik uitbreid).

Hoe kan ik dit nu oplossen!!??

[whoami]

Je krijgt nog steeds dezelfde fout?
Als je 5 velden hebt van varchar(4000), en die 5 velden zijn elk voor de helft gevuld, dan zit je nog aan je limiet van 8060 bytes.

Gebruik -als je niet anders kan- een text veld, maar dan moet je idd waarschijnlijk ook wat aanpassingen in je ASP pagina's gaan doen.

[Verwijderd]

De vijf velden waren eerst elk 8000 >> nu 4000.
Ik heb nog steeds dezelfde fout.
IK heb geprobeerd een veld naar een text veld om te zetten maar kreeg toen erg vage foutmeldingen (op andere punten in de pagina).
Als ik het goed begrijp gaat het niet om de opgegeven waarde (varchar 8000, of 4000 of minder) maar meer de informatie die er reeds instaat. Toch?

[P_de_B]

5 * 4000 = 20000

20000 > 8060

[whoami]

Verwijderd schreef op 23 januari 2004 @ 11:49:
Als ik het goed begrijp gaat het niet om de opgegeven waarde (varchar 8000, of 4000 of minder) maar meer de informatie die er reeds instaat. Toch?

Inderdaad, maar als jouw 5 velden al allemaal 2000 tekens bevaten, zit je al over de limit van 8060 bytes.

[Verwijderd]

daarom krijg ik nu ook de foutmelding
Om heel eerlijk te zijn vind ik dit toch behoorlijk
Ga maar eens kijken wat precies het effect is van text velden ipv varchar

bedankt voor alle reacties

[whoami]

Verwijderd schreef op 23 januari 2004 @ 17:10:
daarom krijg ik nu ook de foutmelding
Om heel eerlijk te zijn vind ik dit toch behoorlijk

Hoezo het is
Het is -imo- toch al voldoende uitgelegd hoe het komt dat je die fout krijgt?

Ga maar eens kijken wat precies het effect is van text velden ipv varchar

Een Text veld wordt -tenzij je het expliciet specifieert- niet in dezelfde page van het record opgeslagen, maar er worden aparte pages voor gereserveerd.