"David Thielen" <thielen@nospam.nospam> wrote in message
news:C224EC5E-439E-4BF2-B8D0-0D9133187045@microsoft.com...
> I'm creating a database with osql and getting the message:
> 1> 2> 3> 4> 5> 6> 7> 8> 9> 10> 11> 12> 13> 14> 15> Warning: The table
> 'TemplateM
> ap' has been created but its maximum row size
> (11038) 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.
>
> Any idea what this means?
>
> --
> thanks - dave
> david_at_windward_dot_net
> http://www.windwardreports.com
>
> Cubicle Wars - http://www.windwardreports.com/film.htm
>
>

"Hari Prasad" wrote:

> Hello,
>
> This is a warning message and the  reason for the warning is that maximum
> size of a row on your table
> exeecds 8kb. This restriction is by SQL 2000 design. SQL Server engine
> stores it's data on 8kb pages & a single
> record must fit in a single page and cannot be spanned to multiple pages.
>
> Try to reduce no of fields on your table.
>
>
> Thanks
> Hari
>
>
> "David Thielen" <thielen@nospam.nospam> wrote in message
> news:C224EC5E-439E-4BF2-B8D0-0D9133187045@microsoft.com...
> > I'm creating a database with osql and getting the message:
> > 1> 2> 3> 4> 5> 6> 7> 8> 9> 10> 11> 12> 13> 14> 15> Warning: The table
> > 'TemplateM
> > ap' has been created but its maximum row size
> > (11038) 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.
> >
> > Any idea what this means?
> >
> > --
> > thanks - dave
> > david_at_windward_dot_net
> > http://www.windwardreports.com
> >
> > Cubicle Wars - http://www.windwardreports.com/film.htm
> >
> >
>
>
>

"David Thielen" <thielen@nospam.nospam> wrote in message
news:D1A9C6AC-86D2-4763-A4D4-6935F94B7B92@microsoft.com...
> does this include the IMAGE type? Because we have records where that one
> column will be over 8K.
>
> The rest I can reduce.
>
> --
> thanks - dave
> david_at_windward_dot_net
> http://www.windwardreports.com
>
> Cubicle Wars - http://www.windwardreports.com/film.htm
>
>
>
>
> "Hari Prasad" wrote:
>
>> Hello,
>>
>> This is a warning message and the  reason for the warning is that maximum
>> size of a row on your table
>> exeecds 8kb. This restriction is by SQL 2000 design. SQL Server engine
>> stores it's data on 8kb pages & a single
>> record must fit in a single page and cannot be spanned to multiple pages.
>>
>> Try to reduce no of fields on your table.
>>
>>
>> Thanks
>> Hari
>>
>>
>> "David Thielen" <thielen@nospam.nospam> wrote in message
>> news:C224EC5E-439E-4BF2-B8D0-0D9133187045@microsoft.com...
>> > I'm creating a database with osql and getting the message:
>> > 1> 2> 3> 4> 5> 6> 7> 8> 9> 10> 11> 12> 13> 14> 15> Warning: The table
>> > 'TemplateM
>> > ap' has been created but its maximum row size
>> > (11038) 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.
>> >
>> > Any idea what this means?
>> >
>> > --
>> > thanks - dave
>> > david_at_windward_dot_net
>> > http://www.windwardreports.com
>> >
>> > Cubicle Wars - http://www.windwardreports.com/film.htm
>> >
>> >
>>
>>
>>

"Peter Yang [MSFT]" wrote:

> Hello David,
>
> As Hari mentioned, in SQL Server 7.0 and SQL Server 2000 we allow to create
> a table that contains variable columns with a total length GT. 8060 (the
> total sum of fixed length columns must be LT 8060 as well as the length of
> an individual column ).
>
> However when exacting an inset or update we fail the statement if the
> actual length is GT 8K. In SQL 2005 this execution will succeed
>
> For example
>
>   Create table foo (a int, b varchar(5000), c varchar(5000))
>
>   If both varchars contain 5000 bytes the insert will succeed in 2000 and
> it will fail in the previous releases.
>
> The 8060 limit for individual varchar/varbinary columns is still in place.
>
> Surpassing the 8,060 row size limit may impact performance. This is because
> SQL Server still maintains a limit of 8 KB per page. When a combination of
> varchar, nvarchar, varbinary, or sql_variant columns exceeds this limit,
> SQL Server moves the record column with the largest width to another page,
> while maintaining a 24-byte pointer on the original page. Moving large
> records to another page happens dynamically as records are lengthened based
> on update operations. Update operations that shorten records may result in
> records moved back to the original page. In addition, querying and
> performing other select operations such as sorts or joins on large records
> that contain row-overflow data slows processing time.
> 
> To fetch a column values that has been pushed off the main row requires an
> extra I/O. Besides, having wide rows also reduces the scan density -
> because fewer rows fit on a page.
> 
> If you find the table has many rows with overflow data then you should
> seriously consider normalizing the table.
>
> In SQL 2005, VarChar(MAX), NVarChar(MAX) and VarBinary(MAX) allow storage
> of data up to 2 gigabytes. Image/Text datatype in SQL 2000/2005 is also
> stored seperately and will not be covered in 8KB size.
>
> If anything is unclear, please feel free to let's know. Thank you.
>
> Best Regards,
>
> Peter Yang
> MCSE2000/2003, MCSA, MCDBA
> Microsoft Online Community Support
> ==================================================
> Get notification to my posts through email? Please refer to
> http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
> ications
> <http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx>.
> Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
> where an initial response from the community or a Microsoft Support
> Engineer within 1 business day is acceptable. Please note that each follow
> up response may take approximately 2 business days as the support
> professional working with you may need further investigation to reach the
> most efficient resolution. The offering is not appropriate for situations
> that require urgent, real-time or phone-based interactions or complex
> project analysis and dump analysis issues. Issues of this nature are best
> handled working with a dedicated Microsoft Support Engineer by contacting
> Microsoft Customer Support Services (CSS) at
> <http://msdn.microsoft.com/subscriptions/support/default.aspx>.
> ==================================================
> This posting is provided "AS IS" with no warranties, and confers no rights.
>
>