I have a very simple data structure with an integer primary key and an "xml" column stored as ntext. How can I update specific nodes of the xml column stored as ntext?
The ntext data type is problematic to say the least.
As marc_s wrote in his comments, this type is deprecated, and even if it wasn't, it's the wrong data type to use for storing XML data.
The XML data type has been around since at least the 2012 version, and you should really consider changing your database structure to use it instead of the deprecated ntext.
If changing the database structure is impossible, then you will have to select the value, try to convert it into a usable type (since ntext doesn't even supports the replace function), manipulate the data, and then convert it back to ntext and update the row.
Related
I have a column of type timestamp which updates every time record updated.
We have some specific logic for syncronizing data and I'd like to store timestamp's value in other table so I can compare to source later. Can't make new column of type timestamp as it's auto-updated.
Which SQL type should I use in TableB for maximum performance and quicker CASTs on comparisons?
Taken from the docs
timestamp is the synonym for the rowversion data type and is subject
to the behavior of data type synonyms. In DDL statements, use
rowversion instead of timestamp wherever possible. For more
information, see Data Type Synonyms (Transact-SQL).
and
The timestamp syntax is deprecated.
and
Is a data type that exposes automatically generated, unique binary
numbers within a database. rowversion is generally used as a mechanism
for version-stamping table rows. The storage size is 8 bytes.
So putting this together: Think of TIMESTAMP (which should be ROWVERSION) as a meaningless 8-byte binary. If you really want to do something with it, you can store it as 8-byte binary or you can convert it to a type with a length of 8 bytes. In this case I'd suggest BIGINT.
First, understand that timestamp is NOT a value of type date and time, but rather a unique identifier based on this type of data.
I suggest you review the documentation Date and Time Data Types and Functions (Transact-SQL) and choose the type of data that best suits your needs. This could be DATETIME2, DATETIMEOFFSET, DATETIME
I came to know that,
ntext, text, and image data types will be removed in a future version of Microsoft SQL Server. (http://msdn.microsoft.com/en-us/library/ms187993%28v=sql.90%29.aspx)
Now I have some tables with Text columns. They contain a lot of text, my concern is does a Varchar(max) can keep our needed length of text instead?
Should I update my table and change the datatype to Varchar(Max)? Will it effect the already existing data?
I am using SQL Server 2008.
VARCHAR(MAX) is the recommended replacement for TEXT, NVARCHAR(MAX) the one for NTEXT. But you cannot simply do an ALTER TABLE and change these fields without reviewing your uses first -- in particular, TEXT and NTEXT have special functions for editing them (READTEXT, WRITETEXT, UPDATETEXT) that don't work for (N)VARCHAR(MAX) (and are partially unnecessary, since the regular string operations just work). Updating very big MAX fields efficiently (as in, megabytes of data that need to be modified somewhere in the middle) is done through UPDATE ... C.WRITE() instead.
If you don't use these functions anywhere and all code simply sets values (which is common), then changing the column types should be no problem, but be aware that this requires rebuilding the entire table and is a potentially expensive operation requiring downtime if your tables are large.
For new work, don't use the TEXT types. For existing software, review your needs. Eventually TEXT and NTEXT support will be removed entirely, but that time has not arrived yet -- as of SQL Server 2014, they are still supported, with no indications as to when they will be finally removed.
Please find the equivalent for text,ntext and image datatypes for forward compatibility.
text -> varchar(max)
ntext -> nvarchar(max)
image -> varbinary(max)
Check for Deprecated Datatypes here.
I am using Jaydata with sqlite.
I am defining database and their tables using Jaydata.
I want to use datatype nvarchar(20) but it generates Jaydata error though it is a sqlite datatype.
Kindly,suggest me the way in which i can use varchar/nvarchar using Jaydata.
SQLite accepts a data type like nvarchar(20) but ignores most of it; the type is handled just as TEXT.
See the data type documentation.
Just use any text data type.
Is there any reason why one would not use ntext and specifying no maximum length for all text entry fields?
One reason for not using ntext is that it will be removed from future versions of SQL Server.
http://msdn.microsoft.com/en-us/library/ms187993.aspx
You should use nvarchar(max) instead of ntext.
I would not use nvarchar(max) for all text fields. I like to have some control over what and how much gets stored. It is for instance a lot easier to build a client that needs to present the information if you know how much text is to be expected. Also users that wants to do bad things can fill a zip code field with all five books of the trilogy Hitch Hikers Guide to the Galaxy. Not that the books are bad but it should not be part of a zip code.
One reason is to do with how it's stored (although this depends on how much you store) and also partly do with restrictions on using some functions with 'text' type datatypes.
In addition, if you are worried about length, the nvarchar(max) is the recommended data type to use these days.
See here for more:
SQL Server Text type vs. varchar data type
http://geekswithblogs.net/johnsperfblog/archive/2008/04/16/ntext-vs-nvarcharmax-in-sql-2005.aspx
Another reason to add to this apart from it being a depreciated type is that ntext cannot be used as an operand to the UNION, INTERSECT or EXCEPT operators.
You will get the following error message
The data type ntext cannot be used as an operand to the UNION,
INTERSECT or EXCEPT operators because it is not comparable.
I suggest to stop using TEXT as it is obsolete and Cast it to NVARCHAR(MAX):
Reference
I have a table that has ntext field. MSDN says that ntext is deprecated and they suggest other data types:
ntext, text, and image data types will be removed in a future version of Microsoft SQL Server. Avoid using these data types in new development work, and plan to modify applications that currently use them. Use nvarchar(max), varchar(max), and varbinary(max) instead.
In my particular case it was decided to switch to varbinary(max). I tried to alter the table definition but that didn't work.
ALTER TABLE MyTable ALTER COLUMN MyColumn VARBINARY(MAX);
What are the possibilities to change the type to varbinary(max)? I tried change the type from ntext -> nvarchar(max) and then from nvarchar(max) -> varbinary(max) but that is not possible (error: Implicit conversion from data type nvarchar(max) to varbinary(max) is not allowed).
The only working solution is to add a new column of type varbinary(max), convert the existing value to the new column and then drop the old column. This takes WAY TOO MUCH time (on my dataset of about 15GB it takes about 30 minutes). That's why I am investigating other possibilities to achieve the same (possibly in-place = without moving data and conversion).
I presume you went with varbinary(max) because your ntext column had non textual data in it? In that case, I think you're going to have to add a separate varbinary(max) column to your table, then run a conversion operation to copy from the ntext to the new column. Then, delete the old column, and rename the new column to the old name.
"Implicit conversion from data type nvarchar(max) to varbinary(max) is not allowed" means that you're going to have to be explicit about the conversion.
It seems like this conversion is going to have to happen at some point. If you search, you'll find many people going from text to varchar(max) and stating it takes 20+ minutes to convert. My two cents after researching for a few minutes, so don't take it as gospel.
If your table just takes inserts, you could convert the existing data in a holding table and then rename the tables so the holding is then production. Then move any newly created data from the old table during your down time.
Handling updates makes things more complex of course.
Adding the extra column is probably the best way to go.
I favour doing this kind of thing in steps to reduce risks
Add the column varbinary(max) as nullable
Modify your insert code to populate both columns
At your leisure, say overnight, run the UPDATE statement with a CAST
Remove all code support for the old column, ensure new column is read
Drop the old column, and change the new column to be non null if needed