Adding a new field to an existing table with image field

Hi,
I have a concern about adding a new field to an existing table with image
field - which is huge.
Will there be a problem with some databases, where they have a hard time
locating data correctly after such a large field? I was advised to put all
the big fields at the end of the table.
Thanks> I was advised to put all
> the big fields at the end of the table.
I don't know why you were given this advice. The position of columns within
a row does not affect performance.
Unless you specify the 'test in row' option, a row contains only a pointer
to a separate area containing the image.
--
Hope this helps.
Dan Guzman
SQL Server MVP
"eeyore21" <u25822@.uwe> wrote in message news:6566a618c09ff@.uwe...
> Hi,
> I have a concern about adding a new field to an existing table with image
> field - which is huge.
> Will there be a problem with some databases, where they have a hard time
> locating data correctly after such a large field? I was advised to put
> all
> the big fields at the end of the table.
> Thanks
>|||Thanks. I was given this advice as this problem seem to occur before.
Hmm.. what is this "test in row" option?
Dan Guzman wrote:
>> I was advised to put all
>> the big fields at the end of the table.
>I don't know why you were given this advice. The position of columns within
>a row does not affect performance.
>Unless you specify the 'test in row' option, a row contains only a pointer
>to a separate area containing the image.
>> Hi,
>[quoted text clipped - 7 lines]
>> Thanks|||> Thanks. I was given this advice as this problem seem to occur before.
I would ask the person who gave you this advise the underlying rationale.
> Hmm.. what is this "test in row" option?
That's a typo :-) I meant to say 'text in row'.
With the 'text in row' table option, values smaller than the specified size
are stored in the data row itself rather than in separate text/image pages.
This can help performance when your images are small enough to fit on the
data page and are most often selected along with the other data. I doubt
this appropriate in your case since you mentioned that the values are large.
See the Books Online for a complete description of the 'text in row' table
option.
--
Hope this helps.
Dan Guzman
SQL Server MVP
"eeyore21" <u25822@.uwe> wrote in message news:6566ff6f0d4fc@.uwe...
> Thanks. I was given this advice as this problem seem to occur before.
> Hmm.. what is this "test in row" option?
> Dan Guzman wrote:
>> I was advised to put all
>> the big fields at the end of the table.
>>I don't know why you were given this advice. The position of columns
>>within
>>a row does not affect performance.
>>Unless you specify the 'test in row' option, a row contains only a pointer
>>to a separate area containing the image.
>> Hi,
>>[quoted text clipped - 7 lines]
>> Thanks
>|||The concern to put all big fields at the end of the table wasn't about
performance - but rather the pointers in the db getting 'lost' when they have
to find a column's data that was located after a very, very big column.
Even though i not sure if this really happens
Dan Guzman wrote:
>> Thanks. I was given this advice as this problem seem to occur before.
>I would ask the person who gave you this advise the underlying rationale.
>> Hmm.. what is this "test in row" option?
>That's a typo :-) I meant to say 'text in row'.
>With the 'text in row' table option, values smaller than the specified size
>are stored in the data row itself rather than in separate text/image pages.
>This can help performance when your images are small enough to fit on the
>data page and are most often selected along with the other data. I doubt
>this appropriate in your case since you mentioned that the values are large.
>See the Books Online for a complete description of the 'text in row' table
>option.
>> Thanks. I was given this advice as this problem seem to occur before.
>[quoted text clipped - 15 lines]
>> Thanks
--
Message posted via SQLMonster.com
http://www.sqlmonster.com/Uwe/Forums.aspx/sql-server/200608/1|||> Even though i not sure if this really happens
Perhaps the person experienced some sort of corruption and attributed the
cause to the position of large columns. As far as I know, this concern is
not warranted. There is no reason to place large columns (text or
otherwise) at the end of the row.
--
Hope this helps.
Dan Guzman
SQL Server MVP
"eeyore21 via SQLMonster.com" <u25822@.uwe> wrote in message
news:6578e9948dd22@.uwe...
> The concern to put all big fields at the end of the table wasn't about
> performance - but rather the pointers in the db getting 'lost' when they
> have
> to find a column's data that was located after a very, very big column.
> Even though i not sure if this really happens
>
> Dan Guzman wrote:
>> Thanks. I was given this advice as this problem seem to occur before.
>>I would ask the person who gave you this advise the underlying rationale.
>> Hmm.. what is this "test in row" option?
>>That's a typo :-) I meant to say 'text in row'.
>>With the 'text in row' table option, values smaller than the specified
>>size
>>are stored in the data row itself rather than in separate text/image
>>pages.
>>This can help performance when your images are small enough to fit on the
>>data page and are most often selected along with the other data. I doubt
>>this appropriate in your case since you mentioned that the values are
>>large.
>>See the Books Online for a complete description of the 'text in row' table
>>option.
>> Thanks. I was given this advice as this problem seem to occur before.
>>[quoted text clipped - 15 lines]
>> Thanks
> --
> Message posted via SQLMonster.com
> http://www.sqlmonster.com/Uwe/Forums.aspx/sql-server/200608/1
>|||eeyore21 via SQLMonster.com wrote:
> The concern to put all big fields at the end of the table wasn't about
> performance - but rather the pointers in the db getting 'lost' when they have
> to find a column's data that was located after a very, very big column.
> Even though i not sure if this really happens
>
Sounds like old advice from a dBase or Foxpro person... Doesn't apply
to SQL Server...
Tracy McKibben
MCDBA
http://www.realsqlguy.com