显示标签为“row”的博文。显示所有博文
显示标签为“row”的博文。显示所有博文

2012年3月25日星期日

Anyone has any idea on how to insert 2 strings into a row with 2 lines created?

<p>Hi ,

I would like to know anyway to insert two strings into a row with 2 lines created?
My codes are as below

If NodeName = "subProductPrice" Then
If xmlrder.NodeType = Xml.XmlNodeType.Text Then
SubPrPriceList.Add(xmlrder.Value)

For i = 0 To SubPrPriceList.Count - 1
SubPrPrice = CStr(SubPrPriceList.Item(i))
PriceBrkDownStr &= SubPrPrice

Next

PricePerDay = SvcDate & PriceBrkDownStr
dr("dailyPrice") = PricePerDay
End If
End If

Although both the SvcDate and PriceBrkDownStr are inserted into the same row but they are displayed into one line such as below:

<u>dailyPrice </u>
02/03/2007 03/03/2007 120 230

Any idea how to make the date and price separate into two rows in the same table grid row? thanks =)
</p>

store <br> between the lines and let me know if it worked...

|||

Hi, sorry I dont get what you mean. Insert <br> between 2 lines? I am inserting the string into the table grid row. How can I insert the tag <br> ? =P

|||

I mean store them as a single line with <br> between them and when you will diplay them they will be shown like two lines... i understood thats what you want to do... if it is not the case then my mistake :)

2012年3月22日星期四

Any workaround for row size > 8060?

Hi All,
We're converting Oracle databases to SQL Server. In Oracle there's no such limit for row size and SQL has.
We've Centura as front-end (Gupta SQL formerly).
While testing is going on......we are getting row size exceeds max limit of 8060 bytes...and we don't know what exactly we need to do.
In the problem tables, I have one TEXT column and various varchar 4000 and varchar 2000 columns.
The application will insert more than 8060 characters for sure..
Can anybody suggest any workaround for this? or Any pointers?
The table structure is something like this:
CREATE TABLE [Table1] (
[Table_ID] [varchar] (10) NOT NULL ,
[T_NOTES1] [TEXT] NULL ,
[T_NOTES2] [varchar] (4000) NULL ,
[C_NOTES] [varchar] (4000) NULL ,
[P_NOTES] [varchar] (4000) NULL ,
[G_NOTES] [varchar] (256) NULL ,
[F_NOTES] [varchar] (256) NULL ,
[L_NOTES] [varchar] (256) NULL ,
[P_NEEDS] [varchar] (256) NULL ,
[F_NEEDS] [varchar] (256) NULL ,
[O_NOTE] [varchar] (250) NULL ,
[V_SOURCES] [varchar] (2000) NULL ,
[T_PROOFS] [varchar] (250) NULL ,
[V_SKILLS] [varchar] (2000) NULL ,
[R_CREDS] [varchar] (2000) NULL ,
[ROWID] [uniqueidentifier] NOT NULL CONSTRAINT
CONSTRAINT [FK_RO_TES_PROID] FOREIGN KEY
(
[PRO_ID]
) REFERENCES [Table_INFO1] (
[PRO_ID]
) ON DELETE CASCADE
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]
GO
If we split the table, will it help?
Can we have more than one column as TEXT data type?
-----
One more point: I appreciate if somebody can clarify this:
TEXT data type can store lot of data...right?
Then if we're inserting > 8060 (row size limit) into the TEXT column why would it error?
If this is so, what is the point in using TEXT column?
I'm little bit confused........I appreciate if somebody can clarify this..
Thanks much,
John..
John,
You can split the table vertically (and of course carry the PK to each table).
As for TEXT (and NTEXT and IMAGE), yes, in these you can have up to 2GB per row. They are, however, more
involved to program against. At the TSQL level, you use stuff like READTEXT, UPDATETEXT, TEXTPRT etc (think of
reading and writing in a loop, using a pointer). The API/dev tool you are using might abstract this from you,
though.
Yes, you can have several columns of the "BLOB" datatypes.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
"John" <johnfull_2000@.yahoo.com> wrote in message news:C8579948-714C-4CA5-9244-9AC486144518@.microsoft.com...
> Hi All,
> We're converting Oracle databases to SQL Server. In Oracle there's no such limit for row size and SQL has.
> We've Centura as front-end (Gupta SQL formerly).
> While testing is going on......we are getting row size exceeds max limit of 8060 bytes...and we don't know
what exactly we need to do.
> In the problem tables, I have one TEXT column and various varchar 4000 and varchar 2000 columns.
> The application will insert more than 8060 characters for sure..
> Can anybody suggest any workaround for this? or Any pointers?
> The table structure is something like this:
> CREATE TABLE [Table1] (
> [Table_ID] [varchar] (10) NOT NULL ,
> [T_NOTES1] [TEXT] NULL ,
> [T_NOTES2] [varchar] (4000) NULL ,
> [C_NOTES] [varchar] (4000) NULL ,
> [P_NOTES] [varchar] (4000) NULL ,
> [G_NOTES] [varchar] (256) NULL ,
> [F_NOTES] [varchar] (256) NULL ,
> [L_NOTES] [varchar] (256) NULL ,
> [P_NEEDS] [varchar] (256) NULL ,
> [F_NEEDS] [varchar] (256) NULL ,
> [O_NOTE] [varchar] (250) NULL ,
> [V_SOURCES] [varchar] (2000) NULL ,
> [T_PROOFS] [varchar] (250) NULL ,
> [V_SKILLS] [varchar] (2000) NULL ,
> [R_CREDS] [varchar] (2000) NULL ,
> [ROWID] [uniqueidentifier] NOT NULL CONSTRAINT
> CONSTRAINT [FK_RO_TES_PROID] FOREIGN KEY
> (
> [PRO_ID]
> ) REFERENCES [Table_INFO1] (
> [PRO_ID]
> ) ON DELETE CASCADE
> ) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]
> GO
> If we split the table, will it help?
> Can we have more than one column as TEXT data type?
> -----
> One more point: I appreciate if somebody can clarify this:
> TEXT data type can store lot of data...right?
> Then if we're inserting > 8060 (row size limit) into the TEXT column why would it error?
> If this is so, what is the point in using TEXT column?
> I'm little bit confused........I appreciate if somebody can clarify this..
> Thanks much,
> John..
|||John,
Does Centura support SQL Server? Perhaps an engineer from Centura would be
required to do this migration work. The problem you are having is that you
will need to use the text data type if you need to store more than 8060
bytes per row. Application changes may need to be made to accomodate this
data type, either at the stored procedure layer or the data access layer in
dynamic SQL in the application itself.
There are many gotchas with the text datatype and they cannot be treated in
the same way as a varchar due to the nature in the way they are stored. i.e.
if the text cannot be stored in row, as in its greater than 8K, then a
pointer is stored in the row to the data pages where the text data can be
found. There is a lot of information on this data type in Books Online, I
recommend you read it.
Mark Allison, SQL Server MVP
http://www.markallison.co.uk
"John" <johnfull_2000@.yahoo.com> wrote in message
news:C8579948-714C-4CA5-9244-9AC486144518@.microsoft.com...
> Hi All,
> We're converting Oracle databases to SQL Server. In Oracle there's no such
limit for row size and SQL has.
> We've Centura as front-end (Gupta SQL formerly).
> While testing is going on......we are getting row size exceeds max limit
of 8060 bytes...and we don't know what exactly we need to do.
> In the problem tables, I have one TEXT column and various varchar 4000 and
varchar 2000 columns.
> The application will insert more than 8060 characters for sure..
> Can anybody suggest any workaround for this? or Any pointers?
> The table structure is something like this:
> CREATE TABLE [Table1] (
> [Table_ID] [varchar] (10) NOT NULL ,
> [T_NOTES1] [TEXT] NULL ,
> [T_NOTES2] [varchar] (4000) NULL ,
> [C_NOTES] [varchar] (4000) NULL ,
> [P_NOTES] [varchar] (4000) NULL ,
> [G_NOTES] [varchar] (256) NULL ,
> [F_NOTES] [varchar] (256) NULL ,
> [L_NOTES] [varchar] (256) NULL ,
> [P_NEEDS] [varchar] (256) NULL ,
> [F_NEEDS] [varchar] (256) NULL ,
> [O_NOTE] [varchar] (250) NULL ,
> [V_SOURCES] [varchar] (2000) NULL ,
> [T_PROOFS] [varchar] (250) NULL ,
> [V_SKILLS] [varchar] (2000) NULL ,
> [R_CREDS] [varchar] (2000) NULL ,
> [ROWID] [uniqueidentifier] NOT NULL CONSTRAINT
> CONSTRAINT [FK_RO_TES_PROID] FOREIGN KEY
> (
> [PRO_ID]
> ) REFERENCES [Table_INFO1] (
> [PRO_ID]
> ) ON DELETE CASCADE
> ) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]
> GO
> If we split the table, will it help?
> Can we have more than one column as TEXT data type?
> ----
--
> One more point: I appreciate if somebody can clarify this:
> TEXT data type can store lot of data...right?
> Then if we're inserting > 8060 (row size limit) into the TEXT column why
would it error?
> If this is so, what is the point in using TEXT column?
> I'm little bit confused........I appreciate if somebody can clarify
this..
> Thanks much,
> John..
|||For your question, Mark:
Yes. Centura supports SQL Server.
I want to get clear about one more thing:
You mean to say, If I have a TEXT column, it can accommodate more than 8060 bytes..right?
That means excluding the TEXT column, the total row size shouldn't be greater than 8060....
That means, the error is coming bcoz of the total exceeds 8060....
Please clarify..
For you, Tibor:
I changed couple of columns (3 to 4 columns) to TEXT and I started receiving STACK DUMP and EXCEPTION HANDLING ERRORS etc....
and nobody could connect to the server.
Then I had to stop the server and restart the server.
Then I had to change the columns back to varchar(4000)......but the error 'row size cannot be greater than > 8060 is coming'..
Any inputs, please let me know.
Thanks,
John..
|||> You mean to say, If I have a TEXT column, it can accommodate more than 8060 bytes..right?
Correct.

> That means excluding the TEXT column, the total row size shouldn't be greater than 8060....
Correct.

> That means, the error is coming bcoz of the total exceeds 8060....
Correct.

> I changed couple of columns (3 to 4 columns) to TEXT and I started receiving STACK DUMP and EXCEPTION
HANDLING ERRORS etc....
> and nobody could connect to the server.
Then you had the unfortunate to (most likely) hit some bug in SQL Server. You can make sure you are updated on
service packs, search KB for resolution or possibly open a case with MS on this.
Important to understand it that it takes special programming to work with these datatypes. It is not only a
matter of changing the table structure. As I mentioned in my earlier post, the dev tool/API might abstract you
from that, but that is up to each dev tool/API vendor.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
"John" <johnfull_2000@.yahoo.com> wrote in message news:A06EB4C0-2FA1-48F8-B0E3-692EA32246B3@.microsoft.com...
> For your question, Mark:
> Yes. Centura supports SQL Server.
> I want to get clear about one more thing:
> You mean to say, If I have a TEXT column, it can accommodate more than 8060 bytes..right?
> That means excluding the TEXT column, the total row size shouldn't be greater than 8060....
> That means, the error is coming bcoz of the total exceeds 8060....
> Please clarify..
> For you, Tibor:
> I changed couple of columns (3 to 4 columns) to TEXT and I started receiving STACK DUMP and EXCEPTION
HANDLING ERRORS etc....
> and nobody could connect to the server.
> Then I had to stop the server and restart the server.
> Then I had to change the columns back to varchar(4000)......but the error 'row size cannot be greater than
> 8060 is coming'..
> Any inputs, please let me know.
> Thanks,
> John..
>
|||THANK YOU.....for the info
John.
sql

Any workaround for row size > 8060?

Hi All,
We're converting Oracle databases to SQL Server. In Oracle there's no such l
imit for row size and SQL has.
We've Centura as front-end (Gupta SQL formerly).
While testing is going on......we are getting row size exceeds max limit o
f 8060 bytes...and we don't know what exactly we need to do.
In the problem tables, I have one TEXT column and various varchar 4000 and v
archar 2000 columns.
The application will insert more than 8060 characters for sure..
Can anybody suggest any workaround for this? or Any pointers?
The table structure is something like this:
---
CREATE TABLE [Table1] (
[Table_ID] [varchar] (10) NOT NULL ,
[T_NOTES1] [TEXT] NULL ,
[T_NOTES2] [varchar] (4000) NULL ,
[C_NOTES] [varchar] (4000) NULL ,
[P_NOTES] [varchar] (4000) NULL ,
[G_NOTES] [varchar] (256) NULL ,
[F_NOTES] [varchar] (256) NULL ,
[L_NOTES] [varchar] (256) NULL ,
[P_NEEDS] [varchar] (256) NULL ,
[F_NEEDS] [varchar] (256) NULL ,
[O_NOTE] [varchar] (250) NULL ,
[V_SOURCES] [varchar] (2000) NULL ,
[T_PROOFS] [varchar] (250) NULL ,
[V_SKILLS] [varchar] (2000) NULL ,
[R_CREDS] [varchar] (2000) NULL ,
[ROWID] [uniqueidentifier] NOT NULL CONSTRAINT
CONSTRAINT [FK_RO_TES_PROID] FOREIGN KEY
(
[PRO_ID]
) REFERENCES [Table_INFO1] (
[PRO_ID]
) ON DELETE CASCADE
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]
GO
If we split the table, will it help?
Can we have more than one column as TEXT data type?
----
--
One more point: I appreciate if somebody can clarify this:
TEXT data type can store lot of data...right?
Then if we're inserting > 8060 (row size limit) into the TEXT column why wou
ld it error?
If this is so, what is the point in using TEXT column?
I'm little bit confused........I appreciate if somebody can clarify this..
Thanks much,
John..John,
You can split the table vertically (and of course carry the PK to each table
).
As for TEXT (and NTEXT and IMAGE), yes, in these you can have up to 2GB per
row. They are, however, more
involved to program against. At the TSQL level, you use stuff like READTEXT,
UPDATETEXT, TEXTPRT etc (think of
reading and writing in a loop, using a pointer). The API/dev tool you are us
ing might abstract this from you,
though.
Yes, you can have several columns of the "BLOB" datatypes.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
"John" <johnfull_2000@.yahoo.com> wrote in message news:C8579948-714C-4CA5-9244-9AC486144518@.
microsoft.com...
> Hi All,
> We're converting Oracle databases to SQL Server. In Oracle there's no such
limit for row size and SQL has.
> We've Centura as front-end (Gupta SQL formerly).
> While testing is going on......we are getting row size exceeds max limit of 8060
bytes...and we don't know
what exactly we need to do.
> In the problem tables, I have one TEXT column and various varchar 4000 and
varchar 2000 columns.
> The application will insert more than 8060 characters for sure..
> Can anybody suggest any workaround for this? or Any pointers?
> The table structure is something like this:
> ---
> CREATE TABLE [Table1] (
> [Table_ID] [varchar] (10) NOT NULL ,
> [T_NOTES1] [TEXT] NULL ,
> [T_NOTES2] [varchar] (4000) NULL ,
> [C_NOTES] [varchar] (4000) NULL ,
> [P_NOTES] [varchar] (4000) NULL ,
> [G_NOTES] [varchar] (256) NULL ,
> [F_NOTES] [varchar] (256) NULL ,
> [L_NOTES] [varchar] (256) NULL ,
> [P_NEEDS] [varchar] (256) NULL ,
> [F_NEEDS] [varchar] (256) NULL ,
> [O_NOTE] [varchar] (250) NULL ,
> [V_SOURCES] [varchar] (2000) NULL ,
> [T_PROOFS] [varchar] (250) NULL ,
> [V_SKILLS] [varchar] (2000) NULL ,
> [R_CREDS] [varchar] (2000) NULL ,
> [ROWID] [uniqueidentifier] NOT NULL CONSTRAINT
> CONSTRAINT [FK_RO_TES_PROID] FOREIGN KEY
> (
> [PRO_ID]
> ) REFERENCES [Table_INFO1] (
> [PRO_ID]
> ) ON DELETE CASCADE
> ) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]
> GO
> If we split the table, will it help?
> Can we have more than one column as TEXT data type?
> ----
--
> One more point: I appreciate if somebody can clarify this:
> TEXT data type can store lot of data...right?
> Then if we're inserting > 8060 (row size limit) into the TEXT column why w
ould it error?
> If this is so, what is the point in using TEXT column?
> I'm little bit confused........I appreciate if somebody can clarify this
.
> Thanks much,
> John..|||John,
Does Centura support SQL Server? Perhaps an engineer from Centura would be
required to do this migration work. The problem you are having is that you
will need to use the text data type if you need to store more than 8060
bytes per row. Application changes may need to be made to accomodate this
data type, either at the stored procedure layer or the data access layer in
dynamic SQL in the application itself.
There are many gotchas with the text datatype and they cannot be treated in
the same way as a varchar due to the nature in the way they are stored. i.e.
if the text cannot be stored in row, as in its greater than 8K, then a
pointer is stored in the row to the data pages where the text data can be
found. There is a lot of information on this data type in Books Online, I
recommend you read it.
Mark Allison, SQL Server MVP
http://www.markallison.co.uk
"John" <johnfull_2000@.yahoo.com> wrote in message
news:C8579948-714C-4CA5-9244-9AC486144518@.microsoft.com...
> Hi All,
> We're converting Oracle databases to SQL Server. In Oracle there's no such
limit for row size and SQL has.
> We've Centura as front-end (Gupta SQL formerly).
> While testing is going on......we are getting row size exceeds max limit
of 8060 bytes...and we don't know what exactly we need to do.
> In the problem tables, I have one TEXT column and various varchar 4000 and
varchar 2000 columns.
> The application will insert more than 8060 characters for sure..
> Can anybody suggest any workaround for this? or Any pointers?
> The table structure is something like this:
> ---
> CREATE TABLE [Table1] (
> [Table_ID] [varchar] (10) NOT NULL ,
> [T_NOTES1] [TEXT] NULL ,
> [T_NOTES2] [varchar] (4000) NULL ,
> [C_NOTES] [varchar] (4000) NULL ,
> [P_NOTES] [varchar] (4000) NULL ,
> [G_NOTES] [varchar] (256) NULL ,
> [F_NOTES] [varchar] (256) NULL ,
> [L_NOTES] [varchar] (256) NULL ,
> [P_NEEDS] [varchar] (256) NULL ,
> [F_NEEDS] [varchar] (256) NULL ,
> [O_NOTE] [varchar] (250) NULL ,
> [V_SOURCES] [varchar] (2000) NULL ,
> [T_PROOFS] [varchar] (250) NULL ,
> [V_SKILLS] [varchar] (2000) NULL ,
> [R_CREDS] [varchar] (2000) NULL ,
> [ROWID] [uniqueidentifier] NOT NULL CONSTRAINT
> CONSTRAINT [FK_RO_TES_PROID] FOREIGN KEY
> (
> [PRO_ID]
> ) REFERENCES [Table_INFO1] (
> [PRO_ID]
> ) ON DELETE CASCADE
> ) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]
> GO
> If we split the table, will it help?
> Can we have more than one column as TEXT data type?
> ----
--
> One more point: I appreciate if somebody can clarify this:
> TEXT data type can store lot of data...right?
> Then if we're inserting > 8060 (row size limit) into the TEXT column why
would it error?
> If this is so, what is the point in using TEXT column?
> I'm little bit confused........I appreciate if somebody can clarify
this..
> Thanks much,
> John..|||For your question, Mark:
Yes. Centura supports SQL Server.
I want to get clear about one more thing:
You mean to say, If I have a TEXT column, it can accommodate more than 8060
bytes..right?
That means excluding the TEXT column, the total row size shouldn't be greate
r than 8060....
That means, the error is coming bcoz of the total exceeds 8060....
Please clarify..
For you, Tibor:
I changed couple of columns (3 to 4 columns) to TEXT and I started receiving
STACK DUMP and EXCEPTION HANDLING ERRORS etc....
and nobody could connect to the server.
Then I had to stop the server and restart the server.
Then I had to change the columns back to varchar(4000)......but the error '
row size cannot be greater than > 8060 is coming'..
Any inputs, please let me know.
Thanks,
John..|||> You mean to say, If I have a TEXT column, it can accommodate more than 806
0 bytes..right?
Correct.

> That means excluding the TEXT column, the total row size shouldn't be greater than
8060....
Correct.

> That means, the error is coming bcoz of the total exceeds 8060....
Correct.

> I changed couple of columns (3 to 4 columns) to TEXT and I started receiving STACK
DUMP and EXCEPTION
HANDLING ERRORS etc....
> and nobody could connect to the server.
Then you had the unfortunate to (most likely) hit some bug in SQL Server. Yo
u can make sure you are updated on
service packs, search KB for resolution or possibly open a case with MS on t
his.
Important to understand it that it takes special programming to work with th
ese datatypes. It is not only a
matter of changing the table structure. As I mentioned in my earlier post, t
he dev tool/API might abstract you
from that, but that is up to each dev tool/API vendor.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
"John" <johnfull_2000@.yahoo.com> wrote in message news:A06EB4C0-2FA1-48F8-B0E3-692EA32246B3@.
microsoft.com...
> For your question, Mark:
> Yes. Centura supports SQL Server.
> I want to get clear about one more thing:
> You mean to say, If I have a TEXT column, it can accommodate more than 806
0 bytes..right?
> That means excluding the TEXT column, the total row size shouldn't be grea
ter than 8060....
> That means, the error is coming bcoz of the total exceeds 8060....
> Please clarify..
> For you, Tibor:
> I changed couple of columns (3 to 4 columns) to TEXT and I started receiving STACK
DUMP and EXCEPTION
HANDLING ERRORS etc....
> and nobody could connect to the server.
> Then I had to stop the server and restart the server.
> Then I had to change the columns back to varchar(4000)......but the error
'row size cannot be greater than
> 8060 is coming'..
> Any inputs, please let me know.
> Thanks,
> John..
>|||THANK YOU.....for the info
John.

Any workaround for row size > 8060?

Hi All
We're converting Oracle databases to SQL Server. In Oracle there's no such limit for row size and SQL has
We've Centura as front-end (Gupta SQL formerly).
While testing is going on......we are getting row size exceeds max limit of 8060 bytes...and we don't know what exactly we need to do
In the problem tables, I have one TEXT column and various varchar 4000 and varchar 2000 columns
The application will insert more than 8060 characters for sure.
Can anybody suggest any workaround for this? or Any pointers
The table structure is something like this
----
CREATE TABLE [Table1]
[Table_ID] [varchar] (10) NOT NULL
[T_NOTES1] [TEXT] NULL
[T_NOTES2] [varchar] (4000) NULL
[C_NOTES] [varchar] (4000) NULL
[P_NOTES] [varchar] (4000) NULL
[G_NOTES] [varchar] (256) NULL
[F_NOTES] [varchar] (256) NULL
[L_NOTES] [varchar] (256) NULL
[P_NEEDS] [varchar] (256) NULL
[F_NEEDS] [varchar] (256) NULL
[O_NOTE] [varchar] (250) NULL
[V_SOURCES] [varchar] (2000) NULL
[T_PROOFS] [varchar] (250) NULL
[V_SKILLS] [varchar] (2000) NULL
[R_CREDS] [varchar] (2000) NULL
[ROWID] [uniqueidentifier] NOT NULL CONSTRAINT
CONSTRAINT [FK_RO_TES_PROID] FOREIGN KEY
[PRO_ID
) REFERENCES [Table_INFO1]
[PRO_ID
) ON DELETE CASCADE
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY
G
If we split the table, will it help
Can we have more than one column as TEXT data type
----
One more point: I appreciate if somebody can clarify this
TEXT data type can store lot of data...right
Then if we're inserting > 8060 (row size limit) into the TEXT column why would it error
If this is so, what is the point in using TEXT column
I'm little bit confused........I appreciate if somebody can clarify this.
Thanks much
John..John,
You can split the table vertically (and of course carry the PK to each table).
As for TEXT (and NTEXT and IMAGE), yes, in these you can have up to 2GB per row. They are, however, more
involved to program against. At the TSQL level, you use stuff like READTEXT, UPDATETEXT, TEXTPRT etc (think of
reading and writing in a loop, using a pointer). The API/dev tool you are using might abstract this from you,
though.
Yes, you can have several columns of the "BLOB" datatypes.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
"John" <johnfull_2000@.yahoo.com> wrote in message news:C8579948-714C-4CA5-9244-9AC486144518@.microsoft.com...
> Hi All,
> We're converting Oracle databases to SQL Server. In Oracle there's no such limit for row size and SQL has.
> We've Centura as front-end (Gupta SQL formerly).
> While testing is going on......we are getting row size exceeds max limit of 8060 bytes...and we don't know
what exactly we need to do.
> In the problem tables, I have one TEXT column and various varchar 4000 and varchar 2000 columns.
> The application will insert more than 8060 characters for sure..
> Can anybody suggest any workaround for this? or Any pointers?
> The table structure is something like this:
> ---
> CREATE TABLE [Table1] (
> [Table_ID] [varchar] (10) NOT NULL ,
> [T_NOTES1] [TEXT] NULL ,
> [T_NOTES2] [varchar] (4000) NULL ,
> [C_NOTES] [varchar] (4000) NULL ,
> [P_NOTES] [varchar] (4000) NULL ,
> [G_NOTES] [varchar] (256) NULL ,
> [F_NOTES] [varchar] (256) NULL ,
> [L_NOTES] [varchar] (256) NULL ,
> [P_NEEDS] [varchar] (256) NULL ,
> [F_NEEDS] [varchar] (256) NULL ,
> [O_NOTE] [varchar] (250) NULL ,
> [V_SOURCES] [varchar] (2000) NULL ,
> [T_PROOFS] [varchar] (250) NULL ,
> [V_SKILLS] [varchar] (2000) NULL ,
> [R_CREDS] [varchar] (2000) NULL ,
> [ROWID] [uniqueidentifier] NOT NULL CONSTRAINT
> CONSTRAINT [FK_RO_TES_PROID] FOREIGN KEY
> (
> [PRO_ID]
> ) REFERENCES [Table_INFO1] (
> [PRO_ID]
> ) ON DELETE CASCADE
> ) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]
> GO
> If we split the table, will it help?
> Can we have more than one column as TEXT data type?
> -----
> One more point: I appreciate if somebody can clarify this:
> TEXT data type can store lot of data...right?
> Then if we're inserting > 8060 (row size limit) into the TEXT column why would it error?
> If this is so, what is the point in using TEXT column?
> I'm little bit confused........I appreciate if somebody can clarify this..
> Thanks much,
> John..|||John,
Does Centura support SQL Server? Perhaps an engineer from Centura would be
required to do this migration work. The problem you are having is that you
will need to use the text data type if you need to store more than 8060
bytes per row. Application changes may need to be made to accomodate this
data type, either at the stored procedure layer or the data access layer in
dynamic SQL in the application itself.
There are many gotchas with the text datatype and they cannot be treated in
the same way as a varchar due to the nature in the way they are stored. i.e.
if the text cannot be stored in row, as in its greater than 8K, then a
pointer is stored in the row to the data pages where the text data can be
found. There is a lot of information on this data type in Books Online, I
recommend you read it.
--
Mark Allison, SQL Server MVP
http://www.markallison.co.uk
"John" <johnfull_2000@.yahoo.com> wrote in message
news:C8579948-714C-4CA5-9244-9AC486144518@.microsoft.com...
> Hi All,
> We're converting Oracle databases to SQL Server. In Oracle there's no such
limit for row size and SQL has.
> We've Centura as front-end (Gupta SQL formerly).
> While testing is going on......we are getting row size exceeds max limit
of 8060 bytes...and we don't know what exactly we need to do.
> In the problem tables, I have one TEXT column and various varchar 4000 and
varchar 2000 columns.
> The application will insert more than 8060 characters for sure..
> Can anybody suggest any workaround for this? or Any pointers?
> The table structure is something like this:
> ---
> CREATE TABLE [Table1] (
> [Table_ID] [varchar] (10) NOT NULL ,
> [T_NOTES1] [TEXT] NULL ,
> [T_NOTES2] [varchar] (4000) NULL ,
> [C_NOTES] [varchar] (4000) NULL ,
> [P_NOTES] [varchar] (4000) NULL ,
> [G_NOTES] [varchar] (256) NULL ,
> [F_NOTES] [varchar] (256) NULL ,
> [L_NOTES] [varchar] (256) NULL ,
> [P_NEEDS] [varchar] (256) NULL ,
> [F_NEEDS] [varchar] (256) NULL ,
> [O_NOTE] [varchar] (250) NULL ,
> [V_SOURCES] [varchar] (2000) NULL ,
> [T_PROOFS] [varchar] (250) NULL ,
> [V_SKILLS] [varchar] (2000) NULL ,
> [R_CREDS] [varchar] (2000) NULL ,
> [ROWID] [uniqueidentifier] NOT NULL CONSTRAINT
> CONSTRAINT [FK_RO_TES_PROID] FOREIGN KEY
> (
> [PRO_ID]
> ) REFERENCES [Table_INFO1] (
> [PRO_ID]
> ) ON DELETE CASCADE
> ) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]
> GO
> If we split the table, will it help?
> Can we have more than one column as TEXT data type?
> ----
--
> One more point: I appreciate if somebody can clarify this:
> TEXT data type can store lot of data...right?
> Then if we're inserting > 8060 (row size limit) into the TEXT column why
would it error?
> If this is so, what is the point in using TEXT column?
> I'm little bit confused........I appreciate if somebody can clarify
this..
> Thanks much,
> John..|||For your question, Mark
Yes. Centura supports SQL Server
I want to get clear about one more thing
You mean to say, If I have a TEXT column, it can accommodate more than 8060 bytes..right
That means excluding the TEXT column, the total row size shouldn't be greater than 8060...
That means, the error is coming bcoz of the total exceeds 8060...
Please clarify.
For you, Tibor
I changed couple of columns (3 to 4 columns) to TEXT and I started receiving STACK DUMP and EXCEPTION HANDLING ERRORS etc...
and nobody could connect to the server
Then I had to stop the server and restart the server
Then I had to change the columns back to varchar(4000)......but the error 'row size cannot be greater than > 8060 is coming'.
Any inputs, please let me know
Thanks
John.|||> You mean to say, If I have a TEXT column, it can accommodate more than 8060 bytes..right?
Correct.
> That means excluding the TEXT column, the total row size shouldn't be greater than 8060....
Correct.
> That means, the error is coming bcoz of the total exceeds 8060....
Correct.
> I changed couple of columns (3 to 4 columns) to TEXT and I started receiving STACK DUMP and EXCEPTION
HANDLING ERRORS etc....
> and nobody could connect to the server.
Then you had the unfortunate to (most likely) hit some bug in SQL Server. You can make sure you are updated on
service packs, search KB for resolution or possibly open a case with MS on this.
Important to understand it that it takes special programming to work with these datatypes. It is not only a
matter of changing the table structure. As I mentioned in my earlier post, the dev tool/API might abstract you
from that, but that is up to each dev tool/API vendor.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
"John" <johnfull_2000@.yahoo.com> wrote in message news:A06EB4C0-2FA1-48F8-B0E3-692EA32246B3@.microsoft.com...
> For your question, Mark:
> Yes. Centura supports SQL Server.
> I want to get clear about one more thing:
> You mean to say, If I have a TEXT column, it can accommodate more than 8060 bytes..right?
> That means excluding the TEXT column, the total row size shouldn't be greater than 8060....
> That means, the error is coming bcoz of the total exceeds 8060....
> Please clarify..
> For you, Tibor:
> I changed couple of columns (3 to 4 columns) to TEXT and I started receiving STACK DUMP and EXCEPTION
HANDLING ERRORS etc....
> and nobody could connect to the server.
> Then I had to stop the server and restart the server.
> Then I had to change the columns back to varchar(4000)......but the error 'row size cannot be greater than
> 8060 is coming'..
> Any inputs, please let me know.
> Thanks,
> John..
>|||THANK YOU.....for the inf
John.

2012年3月20日星期二

Any way to tell when a particular row was last changed?

Does anyone know of a way to tell when a particular row in
a table was last changed. We're doing some trouble
shooting and the info would sure come in handy.
Thanks,
jrJim,
There's no built in way to do this. You need to create triggers on your tabl
e or
you will have to build this
functionality into your application. For instance, you can have a column on
the
table UPDDATE and within the
application/trigger you will update this column with getdate() whenever you
fire
an update statement.
Refer to following url.
Audit insert/udpate/delete with triggers
http://www.devx.com/dbzone/Article/7939/0/page/1
- Vishalsql

2012年2月11日星期六

ANSI_PADDING woes !

I've got a table that I've added a computed column to. That column is part
of an index. As soon as I attempt to insert a row I get the infamous:
INSERT failed because the following SET options have incorrect settings:
'ANSI_PADDING'. Verify that SET options are correct for use with indexed
views and/or indexes on computed columns and/or query notifications and/or
xml data type methods
I've tried creating the table with ansi_padding on and off... and with the
session doing the insert on and off...nothing seems to work...what is
causing this?
Thanks for any insight...really stuck and need to get through this to lock
down some input issues...
Hi Tim
I think that the connection that you are trying to insert does not have the
correct ANSI_PADDING setting rather than anything else.
If Ansi_Padding is on when you create the index and insert everything is ok.
create database TESTDB
go
use TESTDB
gO
SET ANSI_PADDING ON
go
create table TST1 ( ID1 INT NOT NULL, ID2 INT NOT NULL, IDPRODUCT as id1 *
ID2 )
go
crEate index TST1_iDpRODUCT ON tst1 ( IDPRODUCT )
go
insert into tST1 ( ID1, ID2 )
select 1, 3
go
select * from TST1
go
If it is off when you try to insert but on otherwise, you get your error
message
SET ANSI_PADDING Off
go
insert into tST1 ( ID1, ID2 )
select 2, 3
go
/*
Msg 1934, Level 16, State 1, Line 1
INSERT failed because the following SET options have incorrect settings:
'ANSI_PADDING'. Verify that SET options are correct for use with indexed
views and/or indexes on computed columns and/or query notifications and/or
xml data type methods.
*/
If it was off when you create the table and index it will give an error
creating the index
use master
go
drop database TESTDB
go
create database TESTDB
go
use TESTDB
gO
SET ANSI_PADDING Off
go
create table TST1 ( ID1 INT NOT NULL, ID2 INT NOT NULL, IDPRODUCT as id1 *
ID2 )
go
crEate index TST1_iDpRODUCT ON tst1 ( IDPRODUCT )
go
/*
Msg 1934, Level 16, State 1, Line 1
CREATE INDEX failed because the following SET options have incorrect
settings: 'ANSI_PADDING'. Verify that SET options are correct for use with
indexed views and/or indexes on computed columns and/or query notifications
and/or xml data type methods.
*/
If it is on when creating the index you can insert if ANSI_PADDING is on:
SET ANSI_PADDING On
go
crEate index TST1_iDpRODUCT ON tst1 ( IDPRODUCT )
go
insert into tST1 ( ID1, ID2 )
select 3, 3
go
But not if it is off
SET ANSI_PADDING Off
go
insert into tST1 ( ID1, ID2 )
select 4, 3
go
/*
Msg 1934, Level 16, State 1, Line 1
INSERT failed because the following SET options have incorrect settings:
'ANSI_PADDING'. Verify that SET options are correct for use with indexed
views and/or indexes on computed columns and/or query notifications and/or
xml data type methods.
*/
-- Checking the user options when off and on
-- When off
SELECT @.@.OPTIONS
-- 5480
SET ANSI_PADDING ON
go
SELECT @.@.OPTIONS
-- 5496
-- 16 is the USER_OPTION value to set!!
HTH
John
"Tim Greenwood" wrote:

> I've got a table that I've added a computed column to. That column is part
> of an index. As soon as I attempt to insert a row I get the infamous:
> INSERT failed because the following SET options have incorrect settings:
> 'ANSI_PADDING'. Verify that SET options are correct for use with indexed
> views and/or indexes on computed columns and/or query notifications and/or
> xml data type methods
> I've tried creating the table with ansi_padding on and off... and with the
> session doing the insert on and off...nothing seems to work...what is
> causing this?
> Thanks for any insight...really stuck and need to get through this to lock
> down some input issues...
>
>
|||"Tim Greenwood" <tim_greenwood AT yahoo DOT com> wrote in message
news:u2M3gnihIHA.3788@.TK2MSFTNGP04.phx.gbl...
> I've got a table that I've added a computed column to. That column is
> part of an index. As soon as I attempt to insert a row I get the
> infamous:
> INSERT failed because the following SET options have incorrect settings:
> 'ANSI_PADDING'. Verify that SET options are correct for use with indexed
> views and/or indexes on computed columns and/or query notifications and/or
> xml data type methods
> I've tried creating the table with ansi_padding on and off... and with the
> session doing the insert on and off...nothing seems to work...what is
> causing this?
> Thanks for any insight...really stuck and need to get through this to lock
> down some input issues...
What was the ANSI_PADDING setting when you created the table and when you
later created the computed column?
|||I stated in the original message I have created the table both ways...and
in each instance tried with it on /off for the session doing the insert.
"Mike C#" <xyz@.xyz.com> wrote in message
news:Ozq7VKxhIHA.5900@.TK2MSFTNGP02.phx.gbl...
> "Tim Greenwood" <tim_greenwood AT yahoo DOT com> wrote in message
> news:u2M3gnihIHA.3788@.TK2MSFTNGP04.phx.gbl...
> What was the ANSI_PADDING setting when you created the table and when you
> later created the computed column?
>
|||Hi
If you check my script out in the other reply it seems to be the session
where you do the insert.
John
"Tim Greenwood" <tim_greenwood AT yahoo DOT com> wrote in message
news:%239lAvkDiIHA.2416@.TK2MSFTNGP04.phx.gbl...
>I stated in the original message I have created the table both ways...and
>in each instance tried with it on /off for the session doing the insert.
> "Mike C#" <xyz@.xyz.com> wrote in message
> news:Ozq7VKxhIHA.5900@.TK2MSFTNGP02.phx.gbl...
>
|||"Tim Greenwood" <tim_greenwood AT yahoo DOT com> wrote in message
news:%239lAvkDiIHA.2416@.TK2MSFTNGP04.phx.gbl...
>I stated in the original message I have created the table both ways...and
>in each instance tried with it on /off for the session doing the insert.
Ahh missed that part. So change it in your session/connection where you're
trying to perform the INSERT.
|||Yes the connection was it...thank you!! I wasn't aware that the connection
had properties different from the session itself...I mean if my connection
did not have ANSI_PADDING enabled and I entered SET ANSI_PADDING ON I would
have thought that would change everything for the existing
session/connection both.
"John Bell" <jbellnewsposts@.hotmail.com> wrote in message
news:5B951B45-CAEE-4FAB-90AB-4CC90BB024DB@.microsoft.com...[vbcol=seagreen]
> Hi Tim
> I think that the connection that you are trying to insert does not have
> the
> correct ANSI_PADDING setting rather than anything else.
> If Ansi_Padding is on when you create the index and insert everything is
> ok.
> create database TESTDB
> go
> use TESTDB
> gO
> SET ANSI_PADDING ON
> go
> create table TST1 ( ID1 INT NOT NULL, ID2 INT NOT NULL, IDPRODUCT as id1 *
> ID2 )
> go
> crEate index TST1_iDpRODUCT ON tst1 ( IDPRODUCT )
> go
> insert into tST1 ( ID1, ID2 )
> select 1, 3
> go
> select * from TST1
> go
> If it is off when you try to insert but on otherwise, you get your error
> message
> SET ANSI_PADDING Off
> go
> insert into tST1 ( ID1, ID2 )
> select 2, 3
> go
> /*
> Msg 1934, Level 16, State 1, Line 1
> INSERT failed because the following SET options have incorrect settings:
> 'ANSI_PADDING'. Verify that SET options are correct for use with indexed
> views and/or indexes on computed columns and/or query notifications and/or
> xml data type methods.
> */
> If it was off when you create the table and index it will give an error
> creating the index
> use master
> go
> drop database TESTDB
> go
> create database TESTDB
> go
> use TESTDB
> gO
> SET ANSI_PADDING Off
> go
> create table TST1 ( ID1 INT NOT NULL, ID2 INT NOT NULL, IDPRODUCT as id1 *
> ID2 )
> go
> crEate index TST1_iDpRODUCT ON tst1 ( IDPRODUCT )
> go
> /*
> Msg 1934, Level 16, State 1, Line 1
> CREATE INDEX failed because the following SET options have incorrect
> settings: 'ANSI_PADDING'. Verify that SET options are correct for use with
> indexed views and/or indexes on computed columns and/or query
> notifications
> and/or xml data type methods.
> */
> If it is on when creating the index you can insert if ANSI_PADDING is on:
> SET ANSI_PADDING On
> go
> crEate index TST1_iDpRODUCT ON tst1 ( IDPRODUCT )
> go
> insert into tST1 ( ID1, ID2 )
> select 3, 3
> go
> But not if it is off
> SET ANSI_PADDING Off
> go
> insert into tST1 ( ID1, ID2 )
> select 4, 3
> go
> /*
> Msg 1934, Level 16, State 1, Line 1
> INSERT failed because the following SET options have incorrect settings:
> 'ANSI_PADDING'. Verify that SET options are correct for use with indexed
> views and/or indexes on computed columns and/or query notifications and/or
> xml data type methods.
> */
> -- Checking the user options when off and on
> -- When off
> SELECT @.@.OPTIONS
> -- 5480
> SET ANSI_PADDING ON
> go
> SELECT @.@.OPTIONS
> -- 5496
> -- 16 is the USER_OPTION value to set!!
> HTH
> John
> "Tim Greenwood" wrote:
|||Hi Tim
The SET command would only set the ANSI_PADDING for the current connection
you would need to use sp_configure to set the USER_OPTIONS value, which will
change the properties for any subsequent new connection.
John
"Tim Greenwood" <tim_greenwood AT yahoo DOT com> wrote in message
news:u7mcB1HiIHA.1164@.TK2MSFTNGP02.phx.gbl...
> Yes the connection was it...thank you!! I wasn't aware that the
> connection had properties different from the session itself...I mean if my
> connection did not have ANSI_PADDING enabled and I entered SET
> ANSI_PADDING ON I would have thought that would change everything for the
> existing session/connection both.
> "John Bell" <jbellnewsposts@.hotmail.com> wrote in message
> news:5B951B45-CAEE-4FAB-90AB-4CC90BB024DB@.microsoft.com...
>

ANSI_PADDING woes !

I've got a table that I've added a computed column to. That column is part
of an index. As soon as I attempt to insert a row I get the infamous:
INSERT failed because the following SET options have incorrect settings:
'ANSI_PADDING'. Verify that SET options are correct for use with indexed
views and/or indexes on computed columns and/or query notifications and/or
xml data type methods
I've tried creating the table with ansi_padding on and off... and with the
session doing the insert on and off...nothing seems to work...what is
causing this?
Thanks for any insight...really stuck and need to get through this to lock
down some input issues...Hi Tim
I think that the connection that you are trying to insert does not have the
correct ANSI_PADDING setting rather than anything else.
If Ansi_Padding is on when you create the index and insert everything is ok.
create database TESTDB
go
use TESTDB
gO
SET ANSI_PADDING ON
go
create table TST1 ( ID1 INT NOT NULL, ID2 INT NOT NULL, IDPRODUCT as id1 *
ID2 )
go
crEate index TST1_iDpRODUCT ON tst1 ( IDPRODUCT )
go
insert into tST1 ( ID1, ID2 )
select 1, 3
go
select * from TST1
go
If it is off when you try to insert but on otherwise, you get your error
message
SET ANSI_PADDING Off
go
insert into tST1 ( ID1, ID2 )
select 2, 3
go
/*
Msg 1934, Level 16, State 1, Line 1
INSERT failed because the following SET options have incorrect settings:
'ANSI_PADDING'. Verify that SET options are correct for use with indexed
views and/or indexes on computed columns and/or query notifications and/or
xml data type methods.
*/
If it was off when you create the table and index it will give an error
creating the index
use master
go
drop database TESTDB
go
create database TESTDB
go
use TESTDB
gO
SET ANSI_PADDING Off
go
create table TST1 ( ID1 INT NOT NULL, ID2 INT NOT NULL, IDPRODUCT as id1 *
ID2 )
go
crEate index TST1_iDpRODUCT ON tst1 ( IDPRODUCT )
go
/*
Msg 1934, Level 16, State 1, Line 1
CREATE INDEX failed because the following SET options have incorrect
settings: 'ANSI_PADDING'. Verify that SET options are correct for use with
indexed views and/or indexes on computed columns and/or query notifications
and/or xml data type methods.
*/
If it is on when creating the index you can insert if ANSI_PADDING is on:
SET ANSI_PADDING On
go
crEate index TST1_iDpRODUCT ON tst1 ( IDPRODUCT )
go
insert into tST1 ( ID1, ID2 )
select 3, 3
go
But not if it is off
SET ANSI_PADDING Off
go
insert into tST1 ( ID1, ID2 )
select 4, 3
go
/*
Msg 1934, Level 16, State 1, Line 1
INSERT failed because the following SET options have incorrect settings:
'ANSI_PADDING'. Verify that SET options are correct for use with indexed
views and/or indexes on computed columns and/or query notifications and/or
xml data type methods.
*/
-- Checking the user options when off and on
-- When off
SELECT @.@.OPTIONS
-- 5480
SET ANSI_PADDING ON
go
SELECT @.@.OPTIONS
-- 5496
-- 16 is the USER_OPTION value to set!!
HTH
John
"Tim Greenwood" wrote:
> I've got a table that I've added a computed column to. That column is part
> of an index. As soon as I attempt to insert a row I get the infamous:
> INSERT failed because the following SET options have incorrect settings:
> 'ANSI_PADDING'. Verify that SET options are correct for use with indexed
> views and/or indexes on computed columns and/or query notifications and/or
> xml data type methods
> I've tried creating the table with ansi_padding on and off... and with the
> session doing the insert on and off...nothing seems to work...what is
> causing this?
> Thanks for any insight...really stuck and need to get through this to lock
> down some input issues...
>
>|||"Tim Greenwood" <tim_greenwood AT yahoo DOT com> wrote in message
news:u2M3gnihIHA.3788@.TK2MSFTNGP04.phx.gbl...
> I've got a table that I've added a computed column to. That column is
> part of an index. As soon as I attempt to insert a row I get the
> infamous:
> INSERT failed because the following SET options have incorrect settings:
> 'ANSI_PADDING'. Verify that SET options are correct for use with indexed
> views and/or indexes on computed columns and/or query notifications and/or
> xml data type methods
> I've tried creating the table with ansi_padding on and off... and with the
> session doing the insert on and off...nothing seems to work...what is
> causing this?
> Thanks for any insight...really stuck and need to get through this to lock
> down some input issues...
What was the ANSI_PADDING setting when you created the table and when you
later created the computed column?|||I stated in the original message I have created the table both ways...and
in each instance tried with it on /off for the session doing the insert.
"Mike C#" <xyz@.xyz.com> wrote in message
news:Ozq7VKxhIHA.5900@.TK2MSFTNGP02.phx.gbl...
> "Tim Greenwood" <tim_greenwood AT yahoo DOT com> wrote in message
> news:u2M3gnihIHA.3788@.TK2MSFTNGP04.phx.gbl...
>> I've got a table that I've added a computed column to. That column is
>> part of an index. As soon as I attempt to insert a row I get the
>> infamous:
>> INSERT failed because the following SET options have incorrect settings:
>> 'ANSI_PADDING'. Verify that SET options are correct for use with indexed
>> views and/or indexes on computed columns and/or query notifications
>> and/or xml data type methods
>> I've tried creating the table with ansi_padding on and off... and with
>> the session doing the insert on and off...nothing seems to work...what
>> is causing this?
>> Thanks for any insight...really stuck and need to get through this to
>> lock down some input issues...
> What was the ANSI_PADDING setting when you created the table and when you
> later created the computed column?
>|||Hi
If you check my script out in the other reply it seems to be the session
where you do the insert.
John
"Tim Greenwood" <tim_greenwood AT yahoo DOT com> wrote in message
news:%239lAvkDiIHA.2416@.TK2MSFTNGP04.phx.gbl...
>I stated in the original message I have created the table both ways...and
>in each instance tried with it on /off for the session doing the insert.
> "Mike C#" <xyz@.xyz.com> wrote in message
> news:Ozq7VKxhIHA.5900@.TK2MSFTNGP02.phx.gbl...
>> "Tim Greenwood" <tim_greenwood AT yahoo DOT com> wrote in message
>> news:u2M3gnihIHA.3788@.TK2MSFTNGP04.phx.gbl...
>> I've got a table that I've added a computed column to. That column is
>> part of an index. As soon as I attempt to insert a row I get the
>> infamous:
>> INSERT failed because the following SET options have incorrect settings:
>> 'ANSI_PADDING'. Verify that SET options are correct for use with indexed
>> views and/or indexes on computed columns and/or query notifications
>> and/or xml data type methods
>> I've tried creating the table with ansi_padding on and off... and with
>> the session doing the insert on and off...nothing seems to work...what
>> is causing this?
>> Thanks for any insight...really stuck and need to get through this to
>> lock down some input issues...
>> What was the ANSI_PADDING setting when you created the table and when you
>> later created the computed column?
>|||"Tim Greenwood" <tim_greenwood AT yahoo DOT com> wrote in message
news:%239lAvkDiIHA.2416@.TK2MSFTNGP04.phx.gbl...
>I stated in the original message I have created the table both ways...and
>in each instance tried with it on /off for the session doing the insert.
Ahh missed that part. So change it in your session/connection where you're
trying to perform the INSERT.|||Yes the connection was it...thank you!! I wasn't aware that the connection
had properties different from the session itself...I mean if my connection
did not have ANSI_PADDING enabled and I entered SET ANSI_PADDING ON I would
have thought that would change everything for the existing
session/connection both.
"John Bell" <jbellnewsposts@.hotmail.com> wrote in message
news:5B951B45-CAEE-4FAB-90AB-4CC90BB024DB@.microsoft.com...
> Hi Tim
> I think that the connection that you are trying to insert does not have
> the
> correct ANSI_PADDING setting rather than anything else.
> If Ansi_Padding is on when you create the index and insert everything is
> ok.
> create database TESTDB
> go
> use TESTDB
> gO
> SET ANSI_PADDING ON
> go
> create table TST1 ( ID1 INT NOT NULL, ID2 INT NOT NULL, IDPRODUCT as id1 *
> ID2 )
> go
> crEate index TST1_iDpRODUCT ON tst1 ( IDPRODUCT )
> go
> insert into tST1 ( ID1, ID2 )
> select 1, 3
> go
> select * from TST1
> go
> If it is off when you try to insert but on otherwise, you get your error
> message
> SET ANSI_PADDING Off
> go
> insert into tST1 ( ID1, ID2 )
> select 2, 3
> go
> /*
> Msg 1934, Level 16, State 1, Line 1
> INSERT failed because the following SET options have incorrect settings:
> 'ANSI_PADDING'. Verify that SET options are correct for use with indexed
> views and/or indexes on computed columns and/or query notifications and/or
> xml data type methods.
> */
> If it was off when you create the table and index it will give an error
> creating the index
> use master
> go
> drop database TESTDB
> go
> create database TESTDB
> go
> use TESTDB
> gO
> SET ANSI_PADDING Off
> go
> create table TST1 ( ID1 INT NOT NULL, ID2 INT NOT NULL, IDPRODUCT as id1 *
> ID2 )
> go
> crEate index TST1_iDpRODUCT ON tst1 ( IDPRODUCT )
> go
> /*
> Msg 1934, Level 16, State 1, Line 1
> CREATE INDEX failed because the following SET options have incorrect
> settings: 'ANSI_PADDING'. Verify that SET options are correct for use with
> indexed views and/or indexes on computed columns and/or query
> notifications
> and/or xml data type methods.
> */
> If it is on when creating the index you can insert if ANSI_PADDING is on:
> SET ANSI_PADDING On
> go
> crEate index TST1_iDpRODUCT ON tst1 ( IDPRODUCT )
> go
> insert into tST1 ( ID1, ID2 )
> select 3, 3
> go
> But not if it is off
> SET ANSI_PADDING Off
> go
> insert into tST1 ( ID1, ID2 )
> select 4, 3
> go
> /*
> Msg 1934, Level 16, State 1, Line 1
> INSERT failed because the following SET options have incorrect settings:
> 'ANSI_PADDING'. Verify that SET options are correct for use with indexed
> views and/or indexes on computed columns and/or query notifications and/or
> xml data type methods.
> */
> -- Checking the user options when off and on
> -- When off
> SELECT @.@.OPTIONS
> -- 5480
> SET ANSI_PADDING ON
> go
> SELECT @.@.OPTIONS
> -- 5496
> -- 16 is the USER_OPTION value to set!!
> HTH
> John
> "Tim Greenwood" wrote:
>> I've got a table that I've added a computed column to. That column is
>> part
>> of an index. As soon as I attempt to insert a row I get the infamous:
>> INSERT failed because the following SET options have incorrect settings:
>> 'ANSI_PADDING'. Verify that SET options are correct for use with indexed
>> views and/or indexes on computed columns and/or query notifications
>> and/or
>> xml data type methods
>> I've tried creating the table with ansi_padding on and off... and with
>> the
>> session doing the insert on and off...nothing seems to work...what is
>> causing this?
>> Thanks for any insight...really stuck and need to get through this to
>> lock
>> down some input issues...
>>|||Hi Tim
The SET command would only set the ANSI_PADDING for the current connection
you would need to use sp_configure to set the USER_OPTIONS value, which will
change the properties for any subsequent new connection.
John
"Tim Greenwood" <tim_greenwood AT yahoo DOT com> wrote in message
news:u7mcB1HiIHA.1164@.TK2MSFTNGP02.phx.gbl...
> Yes the connection was it...thank you!! I wasn't aware that the
> connection had properties different from the session itself...I mean if my
> connection did not have ANSI_PADDING enabled and I entered SET
> ANSI_PADDING ON I would have thought that would change everything for the
> existing session/connection both.
> "John Bell" <jbellnewsposts@.hotmail.com> wrote in message
> news:5B951B45-CAEE-4FAB-90AB-4CC90BB024DB@.microsoft.com...
>> Hi Tim
>> I think that the connection that you are trying to insert does not have
>> the
>> correct ANSI_PADDING setting rather than anything else.
>> If Ansi_Padding is on when you create the index and insert everything is
>> ok.
>> create database TESTDB
>> go
>> use TESTDB
>> gO
>> SET ANSI_PADDING ON
>> go
>> create table TST1 ( ID1 INT NOT NULL, ID2 INT NOT NULL, IDPRODUCT as id1
>> *
>> ID2 )
>> go
>> crEate index TST1_iDpRODUCT ON tst1 ( IDPRODUCT )
>> go
>> insert into tST1 ( ID1, ID2 )
>> select 1, 3
>> go
>> select * from TST1
>> go
>> If it is off when you try to insert but on otherwise, you get your error
>> message
>> SET ANSI_PADDING Off
>> go
>> insert into tST1 ( ID1, ID2 )
>> select 2, 3
>> go
>> /*
>> Msg 1934, Level 16, State 1, Line 1
>> INSERT failed because the following SET options have incorrect settings:
>> 'ANSI_PADDING'. Verify that SET options are correct for use with indexed
>> views and/or indexes on computed columns and/or query notifications
>> and/or
>> xml data type methods.
>> */
>> If it was off when you create the table and index it will give an error
>> creating the index
>> use master
>> go
>> drop database TESTDB
>> go
>> create database TESTDB
>> go
>> use TESTDB
>> gO
>> SET ANSI_PADDING Off
>> go
>> create table TST1 ( ID1 INT NOT NULL, ID2 INT NOT NULL, IDPRODUCT as id1
>> *
>> ID2 )
>> go
>> crEate index TST1_iDpRODUCT ON tst1 ( IDPRODUCT )
>> go
>> /*
>> Msg 1934, Level 16, State 1, Line 1
>> CREATE INDEX failed because the following SET options have incorrect
>> settings: 'ANSI_PADDING'. Verify that SET options are correct for use
>> with
>> indexed views and/or indexes on computed columns and/or query
>> notifications
>> and/or xml data type methods.
>> */
>> If it is on when creating the index you can insert if ANSI_PADDING is on:
>> SET ANSI_PADDING On
>> go
>> crEate index TST1_iDpRODUCT ON tst1 ( IDPRODUCT )
>> go
>> insert into tST1 ( ID1, ID2 )
>> select 3, 3
>> go
>> But not if it is off
>> SET ANSI_PADDING Off
>> go
>> insert into tST1 ( ID1, ID2 )
>> select 4, 3
>> go
>> /*
>> Msg 1934, Level 16, State 1, Line 1
>> INSERT failed because the following SET options have incorrect settings:
>> 'ANSI_PADDING'. Verify that SET options are correct for use with indexed
>> views and/or indexes on computed columns and/or query notifications
>> and/or
>> xml data type methods.
>> */
>> -- Checking the user options when off and on
>> -- When off
>> SELECT @.@.OPTIONS
>> -- 5480
>> SET ANSI_PADDING ON
>> go
>> SELECT @.@.OPTIONS
>> -- 5496
>> -- 16 is the USER_OPTION value to set!!
>> HTH
>> John
>> "Tim Greenwood" wrote:
>>
>> I've got a table that I've added a computed column to. That column is
>> part
>> of an index. As soon as I attempt to insert a row I get the infamous:
>> INSERT failed because the following SET options have incorrect settings:
>> 'ANSI_PADDING'. Verify that SET options are correct for use with indexed
>> views and/or indexes on computed columns and/or query notifications
>> and/or
>> xml data type methods
>> I've tried creating the table with ansi_padding on and off... and with
>> the
>> session doing the insert on and off...nothing seems to work...what is
>> causing this?
>> Thanks for any insight...really stuck and need to get through this to
>> lock
>> down some input issues...
>>
>