New Posts New Posts RSS Feed: Cannot create a row of size 8190
  FAQ FAQ  Forum Search   Calendar   Register Register  Login Login

Cannot create a row of size 8190
 Post Reply Post Reply
Author
  Share Topic Share Topic  Topic Search Topic Search  Topic Options Topic Options
Customer View Drop Down
Senior Member
Senior Member
Avatar
User Submitted Questions to Support

Joined: 30-May-2007
Location: United States
Posts: 260 		Post Options Post Options   Quote Customer Quote  Post ReplyReply Direct Link To This Post Topic: Cannot create a row of size 8190
    Posted: 16-Jul-2007 at 12:10pm

We have a situation where we have a nvarchar field which is 4000 characters long. In our program we enter exactly 4000 characters into this field than when we go to save it we get a persistence save error stating "Cannot create a row of size 8190 which is greater than the allowable maximum of 8060". The field being entered into is a MemoEdit (could it be the extra line delimiter characters it would be putting in?).
Back to Top
IdeaBlade View Drop Down
Moderator Group
Moderator Group
Avatar

Joined: 30-May-2007
Location: United States
Posts: 353 		Post Options Post Options   Quote IdeaBlade Quote  Post ReplyReply Direct Link To This Post Posted: 16-Jul-2007 at 12:15pm
That would seem reasonable.
 
Why don't you enter a value that doesn't exceed the limit?  Then look at how many characters get stored in the database.
Back to Top
Customer View Drop Down
Senior Member
Senior Member
Avatar
User Submitted Questions to Support

Joined: 30-May-2007
Location: United States
Posts: 260 		Post Options Post Options   Quote Customer Quote  Post ReplyReply Direct Link To This Post Posted: 16-Jul-2007 at 12:18pm
I have done some more research into this situation. I have checked the length of the field going in before i perform the savechanges and i have found anything that has a length greater than 3935 going into a field of nvarchar with a length of 4000 will error. It doesnt seem to have anything to do with the memoedit control because i basically checked the length of entity row field being saved and everything looks above board (stating it has the length which i place into the memoedit).
Back to Top
IdeaBlade View Drop Down
Moderator Group
Moderator Group
Avatar

Joined: 30-May-2007
Location: United States
Posts: 353 		Post Options Post Options   Quote IdeaBlade Quote  Post ReplyReply Direct Link To This Post Posted: 16-Jul-2007 at 12:25pm
Actually, have you checked what happens in T-SQL? There is overhead. 70+ bytes seems like a lot but there is going to be something.
 
Also did you look to see what is actually being written in the SQL we generate?
 
I don't think it has anything to do with the controls at all.
 
Make sure you Trim() too.
Back to Top
Customer View Drop Down
Senior Member
Senior Member
Avatar
User Submitted Questions to Support

Joined: 30-May-2007
Location: United States
Posts: 260 		Post Options Post Options   Quote Customer Quote  Post ReplyReply Direct Link To This Post Posted: 16-Jul-2007 at 12:26pm
It does seem to be the SQL problem. Because if we are too add 3935 characters into 1 or a combination of textboxes(e.g. Add 2000 chars into one textbox and 2000 into another) then it throws the error.
Back to Top
IdeaBlade View Drop Down
Moderator Group
Moderator Group
Avatar

Joined: 30-May-2007
Location: United States
Posts: 353 		Post Options Post Options   Quote IdeaBlade Quote  Post ReplyReply Direct Link To This Post Posted: 16-Jul-2007 at 12:30pm
The problem is SQL Server which has an 8K max for a record. A single field of nvarchar(4000), at 2 bytes per char, is 8k right there.
 
It has NOTHING to do with the limit for a textbox (which is much larger than 8k) nor with DevForce which could care less about how big any string is. SQL Server imposes the limit.
 
In Sql Server, if you want anything that is larger than 8k, you have to declare the field as nvarchar(max) [Sql Server 2005] or I-forget-what for Sql Server 2000. Behind the scenes, SQL Server moves this data into a special "large object page".
 
You DO NOT WANT this in your business object because the perf of these large objects is not good. In fact, you never want a Sql record to get anywhere close to 8k because that screws up Sql Server's paging and makes storage and retrieval less efficient.
 
You really want record sizes that are nice and compact. Anything large should be shunted off to the side.
 
 
Back to Top
 Post Reply Post Reply

Forum Jump Forum Permissions View Drop Down