Showing posts with label ntext. Show all posts
Showing posts with label ntext. Show all posts

Wednesday, March 28, 2012

Problem in Displaying NTEXT field from database?

Hello,

I have around 7 ntext fields in my data base table and I am getting data from the data base table through executing stored procedure, But when I am displaying data using record set, few of the ntext fields in recored set are empty .Iam sure that these are having data in table.

I am not sure why recordset is lossing that ntext field data?Because of this I am unable to display that data in web form.

any ideas really appriciated.

Thanks

Ram

text and ntext fields should always be either the only data returned or the last item in a select statement.

For example:

SELECT ntextField FROM myTable WHERE something = true

or

SELECT myFirstField, myOtherField, ntextField FROM myTable WHERE something = true

This is a limitation of MSSQL server and (some versions) of MySQL. If you are using MSSQL Server 2005, I would suggest changing the database column to a nvarchar(MAX) as this will store the same number of characters as an ntext column. (I believe they intended to remove text and ntext from the next release of MSSQL Server in favor of varchar(MAX) and nvarchar(MAX), but don't quote me on that.)

|||

I am using SQLserver 2000, What will be the possible solutions for this problem.

Thanks

|||

You will have to select each ntext field individually. So you will need 7 select statements each time.

However, I would recommend changing the database to use a different type of column. If you know the data will never be larger than 8K you can still use nvarchar(8000) on SQL Server 2000. Or you could combine some of the columns and then use delimiters so that you have one huge column with something like ||| between entries (but this may cause other problems.)

In general text, ntext and blob fields should be used as rarely as possible, it is usually easier to put that much data into a file and then store the files name and location in SQL Server.

Let me know if this doesn't really answer your question.

|||

Hi,

Its working for me now..What I did is ...

I have got all ntext fields from the recordset first into some varialbles before acesing non ntext fields and mapped to the form controls.

thats it.

thanks

Wednesday, March 21, 2012

Problem importing data from an Access memo field into a SQL Server ntext field.

I'm using DTS to import data from an Access memo field into a SQL Server ntext field. DTS is only importing the first 255 characters of the memo field and truncating the rest.
I'd appreciate any insights into what may be causing this problem, and what I can do about it.
Thanks in advance for any help!
255 is the default change the settings to accept more than 255, Access memo must be either image to store the file in Word or Text both can grow to 2gigs because Varchar 8000, Char 8000, NVarchar 4000 and NChar 4000 maybe too small for Access memo column. Hope this helps.|||

Thank you for your reply.
If you don't mind, what "settings" are you referring to and how do I change them? For example, are you talking about settings in Access, SQL Server and/or DTS? If I have to change settings via DTS, I've been using the DTS Wizard. Can I change the settings you're referring to with this Wizard?
I haven't been able to find any information on this problem, so I could use all the details you're able to provide.
Thanks again!

|||Try this link for a fix because it is a bug and keep the link because the site is run by a DTS expert. Hope this helps.
http://www.sqldts.com/?297|||

I finally was able to find the cause of my problem, and thought I'd put it out there for somebody who might suffer the same confusion one day. It turns out that Microsoft Query Analyzer will only display the first first 255 (or 256) characters of a field (this may be common knowledge - but I didn't know that). I had assumed that, since I couldn't see the entire result, DTS had truncated the data when importing from Microsoft Access. That wasn't the case. Everything was always fine.
Thanks again for the feedback!