Access Memo field to SQL Server Text field

Hi,

I'm importing an Access database to SQL Server 2000.
The issue I ran into is pretty frustrating... All Memo fields that get copied over (as Text fields) appear to be fine and visible in SQL Server Enterprise Manager... except when I display them on the web via ASP - everything is blank (no content at all).

I didn't have that problem with Access, so I ruled out the possibility that there's something wrong with the original data.

Is this some sort of an encoding problem that arose during database import?
I would appreciate any pointers.If the data is visible within SQL Server, but not from your ASP page, then the problem is with your ASP page and the way it is pulling the text data.
Do you really need this to be a text field? The varchar datatype will handle up to 8000 bytes.|||That's a good point - I might be able to get away with varchar. It's something I'll look into, but I'm still curious as to why the data behaves this way (I ran into similar problems in the past while trying to import Access data to SQL server).

My ASP page is functioning properly. I use a simple "SELECT *" statement to pull the data and display it on the page. With an Access DSN it encounters no problems and shows all the data as intended. When I import the data into SQL Server and swap the DSN to point to the newly-created database (while not modifying the ASP page itself in any way) the text fields display no content.|||A text field in SQL Server is not stored within the record. The record actually only stores a pointer to the location of the actual data. This may be why your page is not handling it properly, but I don't know the work-around. You could try posting your question on the ASP forum.|||Interesting... I was aware that Text fields are stored differently and separately from the regular data in the database, but I didn't think it would affect the way they're displayed through the recordset...

Maybe there's something that can be done on the ASP side - I'll ask some ASP guys.

Thanks.|||Interesting... I was aware that Text fields are stored differently and separately from the regular data in the database, but I didn't think it would affect the way they're displayed through the recordset...I wouldn't have thought so either, but it is my best guess.
What happens in your ASP code if you enumerate the column names rather than using "select *" (which is a bad practice anyway)?|||I use a simple "SELECT *" statement to pull the data and display it on the page.

ahhhhhhhhhhhhhhhhhhhhhhhhhhh

http://weblogs.sqlteam.com/brettk/archive/2004/04/22/1272.aspx|||I try to do it properly with larger systems and database, but, yeah, for me it's laziness that makes me use "Select *"...|||I try to do it properly with larger systems and database, but, yeah, for me it's laziness that makes me use "Select *"...

Hey! No one's lazier than me....

SELECT ', ' + COLUMN_NAME FROM INFORMATION_SCHEMA.Columns
WHERE TABLE_NAME = 'xxx'
ORDER BY ORDINAL_POSITION

SELECT * can buy you a boatload of trouble...so it's amatter how you want to spend your laziness...you have no choice when you have exploding code|||I wouldn't have thought so either, but it is my best guess.
What happens in your ASP code if you enumerate the column names rather than using "select *" (which is a bad practice anyway)?

Well, that's an interesting question, mostly because it gives me some sort of a deja vu feeling - as if I encountered something like this several years ago...
It's possible that I did something like this in the past and fixed the problem that way.
I'll check into this on Thursday when I'm back at work.

Thanks.|||You are off UNTIL Thursday?

Okay, but this Thursday is Turkey Day for us Yanks, so you'll have to depend upon the Pootle Flumps and Cannucks of the world to help you out.|||Hey! No one's lazier than me....

SELECT ', ' + COLUMN_NAME FROM INFORMATION_SCHEMA.Columns
WHERE TABLE_NAME = 'xxx'
ORDER BY ORDINAL_POSITION

SELECT * can buy you a boatload of trouble...so it's amatter how you want to spend your laziness...you have no choice when you have exploding code

That's an interesting way to structure a query - I've never done it this way before.

Dare to dream... Sorry, you think that you're the laziness champ, but you're not. Your laziness doesn't compare to mine - not even close.|||You are off UNTIL Thursday?

Okay, but this Thursday is Turkey Day for us Yanks, so you'll have to depend upon the Pootle Flumps and Cannucks of the world to help you out.

Yes, it sounds a bit odd. I'm actually at work as we speak, but I also have another part time job as a contractor with my previous employer. Thanksgiving will be a good time to come in and get a bunch of work out of the way.|||See but here's the rub, my laziness is born out of economy of effort..the smarter you work, the less you have to

some laziness makes your life more simple, other types make your life much more difficult, you have to decide|||See but here's the rub, my laziness is born out of economy of effort..the smarter you work, the less you have to

some laziness makes your life more simple, other types make your life much more difficult, you have to decide

Agree. Mine usually gets me in trouble somewhere down the line.

... but it still feels good to be the "Champ" :)

Access managment in SQL

Hi,
I have just imported my old access database into my new
SQL database and have come over a few problems.
All memo fields have been changed to "ntext" fields. This
is no good for me as I have lots of text in the fields.
When I try and change one of the fileds I get this error:
'creek_products' table
- Unable to modify table.
ADO error: Cannot create a row of size 8129 which is
greater than the allowable maximum of 8060.
The statement has been terminated.
I'm only trying to change one field to nchar because then
it will let me have a lenght of 4000.
Can anyone help me with this?
I need to get the max lenght field type working.
Thakns
I hope you got answer to your question but if not:
In SQL Server every row has a limit in size.
Consider when converting, creating tables first and then pouring data into it.
I am still puzzled what's wrong with ntext data type?
"Luca" wrote:

> Hi,
> I have just imported my old access database into my new
> SQL database and have come over a few problems.
> All memo fields have been changed to "ntext" fields. This
> is no good for me as I have lots of text in the fields.
> When I try and change one of the fileds I get this error:
> 'creek_products' table
> - Unable to modify table.
> ADO error: Cannot create a row of size 8129 which is
> greater than the allowable maximum of 8060.
> The statement has been terminated.
> I'm only trying to change one field to nchar because then
> it will let me have a lenght of 4000.
> Can anyone help me with this?
> I need to get the max lenght field type working.
> Thakns
>
|||Luca wrote:
> Hi,
> I have just imported my old access database into my new
> SQL database and have come over a few problems.
> All memo fields have been changed to "ntext" fields. This
> is no good for me as I have lots of text in the fields.
> When I try and change one of the fileds I get this error:
> 'creek_products' table
> - Unable to modify table.
> ADO error: Cannot create a row of size 8129 which is
> greater than the allowable maximum of 8060.
> The statement has been terminated.
> I'm only trying to change one field to nchar because then
> it will let me have a lenght of 4000.
> Can anyone help me with this?
> I need to get the max lenght field type working.
> Thakns
Why is ntext no good for you? If you have lots of text, as you
mentioned, then ntext or text is what you want. ntext is unicode and
requires twice the storage of text. If you don't require unicode
support, use text.
The nchar(4000) requires SQL Server reserve 4000 bytes for each row.
That will give you terrible performance because only a couple rows will
fit on each SQL Server page (same as nvarchar(4000) would do). There's a
limit of about 8060 total bytes stored within a row (excluding the text
in text and ntext columns). Using text or ntext fixes this by only
requiring a 16 byte pointer in the table. The text is stored elsewhere,
on a different filegroup if you prefer.
Can you explain what problem you feel you are having using ntext?
David G.