• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 755
  • Last Modified:

Using sp_tableoption and getting an error.


I am creating an SQL Script which will create a database.

The database is a conversion from a non SQL database.

A part of the script is ...

/****** Object:  Table [dbo].[AcceptCode]    Script Date: 09/08/2004 10:31:28 AM ******/
if exists (select * from dbo.sysobjects where id = object_id(N'[dbo].[AcceptCode]') and OBJECTPROPERTY(id, N'IsUserTable') = 1)
drop table [dbo].[AcceptCode]

/****** Object:  Table [dbo].[AcceptCode]    Script Date: 09/08/2004 10:31:28 AM ******/
CREATE TABLE [dbo].[AcceptCode] (
      [UniqueID] [int] IDENTITY (1, 1) NOT NULL  ,
      [AcceptCode] nchar(3) ,
      [Description] nchar(40) ,
      [SummaryCode] nchar(3) ,
      [SpareText] nchar(17)

 CREATE  UNIQUE  INDEX [PK_AcceptCode] ON [dbo].[AcceptCode]([UniqueID]) WITH  IGNORE_DUP_KEY  ON [PRIMARY]

exec sp_tableoption 'AcceptCode', 'text in row', 'ON'

(I am cloning the script style that MS uses when you use Create Script on a database, so hopefully, my script will look the same as the one MS produces when I have finished).

When I run this script, the tables are produced as required.
The index is produced too.

But I get an error on the exec sp_tableoption line.

The error is ...

Server: Msg 2591, Level 16, State 90, Procedure sp_tableoption, Line 79
Could not find row in sysindexes with index ID 255 for table 'AcceptCode'.

This comes from the sp_tableoption procedure.

Line 79 is ...

            BEGIN TRAN
            DBCC LOCKOBJECTSCHEMA(@TableNamePattern)
            dbcc no_textptr(@TabId, @intOptionValue) <<<<<<<<<<<<<<<< Line 79
            COMMIT TRAN

I've just started with MS SQL Server, so I am not sure what I should be doing next.



Thank you.

Richard Quadling.
Richard Quadling
Richard Quadling
  • 4
  • 2
2 Solutions
Hi Qualding,

Sets option values for user-defined tables. sp_tableoption may be used to turn on the text in row feature on tables with text, ntext, or image columns.

You table has no such field.

Text is a datatype
ALthough nchar can be used to store "text" - a string - , it's not TEXT datatype
The TEXT IN ROW option is only for text datatypes. You don't have any columns which are text, they are all nchar, so you don't need the option. Infact, as is happening, you get an error if you try to set the option on a table which has no text columns.

BTW, you might consider using nvarchar(), particularly if your description is not always a full 40 chars in length.
Richard QuadlingSenior Software DeveloperAuthor Commented:
Oh stupid me.

I've been reading and reading the "text in row" page in the Books Online.

I saw it said ...

"You enable the text in row option for a table by using sp_tableoption. With the text in row option set to ON, Microsoft® SQL Server™ 2000 stores text, ntext, or image strings directly in the data row if:..."

And I STILL went ahead and used nchar as the "text" type!


Just re-testing script.

Build your data science skills into a career

Are you ready to take your data science career to the next step, or break into data science? With Springboard’s Data Science Career Track, you’ll master data science topics, have personalized career guidance, weekly calls with a data science expert, and a job guarantee.

Richard QuadlingSenior Software DeveloperAuthor Commented:

Changed nchar to ntext and dropped the length part, and all is now working.

But BillAn1 raises a good question.

My existing database has text strings upto 255 characters in length and is NOT unicode.

I am converting the app to SQL and making it web based.

The app does need to allow for non ascii letters (european mainly). Do I need national format or not.

And would varchar be better/same as using "text in row" with ntext?

Richard QuadlingSenior Software DeveloperAuthor Commented:
Increased points for the additional question.
(var)char is always better for text < 8000 chars. There are a lot of limitations on what you can do with a text datafield. Generally, you should think of it as a 'blob' of data, that you can't parse very well.
regards the languages, depends a bit on what amount of flexibility you want. the standard Latin colation does have most of the normally used characters in european languages, but unicode is more 'robust', and more flexible, so you might be safer to use nvarchar rather than varchar.
Richard QuadlingSenior Software DeveloperAuthor Commented:
Thanks for that.
I've dropped the "text in row" and moved to nvarchar().


Richard Quadling.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Free Tool: IP Lookup

Get more info about an IP address or domain name, such as organization, abuse contacts and geolocation.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

  • 4
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now