ASP with SQL database in Unicode and double-byte environment

Dear all:
Would like to consult you with a question that has been bothering us a lot
in the past two weeks.
We recently purchased a software developed with ASP (well, we knew it would
be better with .Net, but could not find one with similar features).
And we are using this application in Windows Server 2003 environment and MS
SQL 2000 (with Collation set to Chinese).
The problem is that we consistently got random characters from those ASP
pages and dynamic web pages using the data from SQL.
We have checked and reset MS SQL many times and are sure that it does
support Chinese characters and data there are fine.
We even put the <% @.CodePage="950" %> on every page but still with the same
problem.
Interestingly enough, if we use MS Access, everything works fine (with the
same CodePage). All Chinese characters can display normally.
Does anyone know what might be the cause? Our application vendor seems
unable to solve the problem.
We don't even know if this is caused by the application or database.
Many thanks.
xfile wrote:
> Does anyone know what might be the cause? Our application vendor
> seems unable to solve the problem.
> We don't even know if this is caused by the application or database.
> Many thanks.
Does your database use UNICODE data types: nchar, nvarchar, ntext?
David Gugick
Quest Software
www.imceda.com
www.quest.com
|||Hi,
We set the entire collation to Windows Collation in Chinese_Taiwan
And I am not sure if that applies to your question?
Kindly tell me who to check if those are true?
Many thanks.
"David Gugick" <david.gugick-nospam@.quest.com> wrote in message
news:OsuFr5bmFHA.3936@.TK2MSFTNGP10.phx.gbl...
> xfile wrote:
> Does your database use UNICODE data types: nchar, nvarchar, ntext?
> --
> David Gugick
> Quest Software
> www.imceda.com
> www.quest.com
|||xfile wrote:[vbcol=seagreen]
> Hi,
> We set the entire collation to Windows Collation in Chinese_Taiwan
> And I am not sure if that applies to your question?
> Kindly tell me who to check if those are true?
> Many thanks.
>
> "David Gugick" <david.gugick-nospam@.quest.com> wrote in message
> news:OsuFr5bmFHA.3936@.TK2MSFTNGP10.phx.gbl...
You need to check the data types used in the tables to see if the vendor
is using unicode data types. You can't store unicode data in non-unicode
data types.
David Gugick
Quest Software
www.imceda.com
www.quest.com
|||Hi,
Got it. We need to change to Unicode.
Many thanks.
"David Gugick" <david.gugick-nospam@.quest.com> wrote in message
news:ubHOFrtmFHA.2860@.TK2MSFTNGP15.phx.gbl...
> xfile wrote:
> You need to check the data types used in the tables to see if the vendor
> is using unicode data types. You can't store unicode data in non-unicode
> data types.
> --
> David Gugick
> Quest Software
> www.imceda.com
> www.quest.com
|||xfile wrote:
> Hi,
> Got it. We need to change to Unicode.
> Many thanks.
It might not be that easy if this is a vendor application since there
might be application support for non-unicode data types.
The best thing to do is check with the vendor and get them to tell you
whether the application supports unicode data.
David Gugick
Quest Software
www.imceda.com
www.quest.com
|||Hi,
Thanks. We've done it for this part.
The vendor claimed it support Unicode with language scripts but it is not
exactly working as they claimed.
We used their scripts to create database and tables and fields and so on,
but it did not even set the data type correctly.
It turned out we had to re-set the data type, and re-adjust length due to
SQL's limitation on 8060.
We are trying to solve another Unicode problem for their e-mail messages,
which I will post later.
Many thanks for your kind help.
"David Gugick" <david.gugick-nospam@.quest.com> wrote in message
news:%23l%23V63BnFHA.3336@.tk2msftngp13.phx.gbl...
> xfile wrote:
> It might not be that easy if this is a vendor application since there
> might be application support for non-unicode data types.
> The best thing to do is check with the vendor and get them to tell you
> whether the application supports unicode data.
>
> --
> David Gugick
> Quest Software
> www.imceda.com
> www.quest.com
|||xfile wrote:
> Hi,
> Thanks. We've done it for this part.
> The vendor claimed it support Unicode with language scripts but it is
> not exactly working as they claimed.
> We used their scripts to create database and tables and fields and so
> on, but it did not even set the data type correctly.
> It turned out we had to re-set the data type, and re-adjust length
> due to SQL's limitation on 8060.
> We are trying to solve another Unicode problem for their e-mail
> messages, which I will post later.
> Many thanks for your kind help.
If you are hitting the 8060 byte row limit, you might have table design
problems. That's an incredibly large row size. Consider using NTEXT
columns for long text to get the data out of the row.
David Gugick
Quest Software
www.imceda.com
www.quest.com
|||Hi,
You are absolutely correct but we were reluctant to say it about the
inappropriate design of the database.
However, we have not time to fix this problem at this stage but would do it
at a later time.
Thanks again for the tips which will be very useful.
"David Gugick" <david.gugick-nospam@.quest.com> wrote in message
news:%23YBwMlOnFHA.4032@.TK2MSFTNGP10.phx.gbl...
> xfile wrote:
> If you are hitting the 8060 byte row limit, you might have table design
> problems. That's an incredibly large row size. Consider using NTEXT
> columns for long text to get the data out of the row.
> --
> David Gugick
> Quest Software
> www.imceda.com
> www.quest.com

ASP with SQL database in Unicode and double-byte environment

Dear all:
Would like to consult you with a question that has been bothering us a lot
in the past two weeks.
We recently purchased a software developed with ASP (well, we knew it would
be better with .Net, but could not find one with similar features).
And we are using this application in Windows Server 2003 environment and MS
SQL 2000 (with Collation set to Chinese).
The problem is that we consistently got random characters from those ASP
pages and dynamic web pages using the data from SQL.
We have checked and reset MS SQL many times and are sure that it does
support Chinese characters and data there are fine.
We even put the <% @.CodePage="950" %> on every page but still with the same
problem.
Interestingly enough, if we use MS Access, everything works fine (with the
same CodePage). All Chinese characters can display normally.
Does anyone know what might be the cause? Our application vendor seems
unable to solve the problem.
We don't even know if this is caused by the application or database.
Many thanks.xfile wrote:
> Does anyone know what might be the cause? Our application vendor
> seems unable to solve the problem.
> We don't even know if this is caused by the application or database.
> Many thanks.
Does your database use UNICODE data types: nchar, nvarchar, ntext?
David Gugick
Quest Software
www.imceda.com
www.quest.com|||Hi,
We set the entire collation to Windows Collation in Chinese_Taiwan
And I am not sure if that applies to your question?
Kindly tell me who to check if those are true?
Many thanks.
"David Gugick" <david.gugick-nospam@.quest.com> wrote in message
news:OsuFr5bmFHA.3936@.TK2MSFTNGP10.phx.gbl...
> xfile wrote:
> Does your database use UNICODE data types: nchar, nvarchar, ntext?
> --
> David Gugick
> Quest Software
> www.imceda.com
> www.quest.com|||xfile wrote:[vbcol=seagreen]
> Hi,
> We set the entire collation to Windows Collation in Chinese_Taiwan
> And I am not sure if that applies to your question?
> Kindly tell me who to check if those are true?
> Many thanks.
>
> "David Gugick" <david.gugick-nospam@.quest.com> wrote in message
> news:OsuFr5bmFHA.3936@.TK2MSFTNGP10.phx.gbl...
You need to check the data types used in the tables to see if the vendor
is using unicode data types. You can't store unicode data in non-unicode
data types.
David Gugick
Quest Software
www.imceda.com
www.quest.com|||Hi,
Got it. We need to change to Unicode.
Many thanks.
"David Gugick" <david.gugick-nospam@.quest.com> wrote in message
news:ubHOFrtmFHA.2860@.TK2MSFTNGP15.phx.gbl...
> xfile wrote:
> You need to check the data types used in the tables to see if the vendor
> is using unicode data types. You can't store unicode data in non-unicode
> data types.
> --
> David Gugick
> Quest Software
> www.imceda.com
> www.quest.com|||xfile wrote:
> Hi,
> Got it. We need to change to Unicode.
> Many thanks.
It might not be that easy if this is a vendor application since there
might be application support for non-unicode data types.
The best thing to do is check with the vendor and get them to tell you
whether the application supports unicode data.
David Gugick
Quest Software
www.imceda.com
www.quest.com|||Hi,
Thanks. We've done it for this part.
The vendor claimed it support Unicode with language scripts but it is not
exactly working as they claimed.
We used their scripts to create database and tables and fields and so on,
but it did not even set the data type correctly.
It turned out we had to re-set the data type, and re-adjust length due to
SQL's limitation on 8060.
We are trying to solve another Unicode problem for their e-mail messages,
which I will post later.
Many thanks for your kind help.
"David Gugick" <david.gugick-nospam@.quest.com> wrote in message
news:%23l%23V63BnFHA.3336@.tk2msftngp13.phx.gbl...
> xfile wrote:
> It might not be that easy if this is a vendor application since there
> might be application support for non-unicode data types.
> The best thing to do is check with the vendor and get them to tell you
> whether the application supports unicode data.
>
> --
> David Gugick
> Quest Software
> www.imceda.com
> www.quest.com|||xfile wrote:
> Hi,
> Thanks. We've done it for this part.
> The vendor claimed it support Unicode with language scripts but it is
> not exactly working as they claimed.
> We used their scripts to create database and tables and fields and so
> on, but it did not even set the data type correctly.
> It turned out we had to re-set the data type, and re-adjust length
> due to SQL's limitation on 8060.
> We are trying to solve another Unicode problem for their e-mail
> messages, which I will post later.
> Many thanks for your kind help.
If you are hitting the 8060 byte row limit, you might have table design
problems. That's an incredibly large row size. Consider using NTEXT
columns for long text to get the data out of the row.
David Gugick
Quest Software
www.imceda.com
www.quest.com|||Hi,
You are absolutely correct but we were reluctant to say it about the
inappropriate design of the database.
However, we have not time to fix this problem at this stage but would do it
at a later time.
Thanks again for the tips which will be very useful.
"David Gugick" <david.gugick-nospam@.quest.com> wrote in message
news:%23YBwMlOnFHA.4032@.TK2MSFTNGP10.phx.gbl...
> xfile wrote:
> If you are hitting the 8060 byte row limit, you might have table design
> problems. That's an incredibly large row size. Consider using NTEXT
> columns for long text to get the data out of the row.
> --
> David Gugick
> Quest Software
> www.imceda.com
> www.quest.com

ASP- Db Connection problem

Hi there,
I have a web application developed in ASP and SQL-server. One of my clients wanted the SQL DB to reisde in a separate machine than the IIS box. Also he doesn't want the SQL - DB box to be protected from public access. So only the IIS box is assiged a public IP, and the SQL box is in the same network(LAN) as of the IIS box. Now using TCP/IP can I connect to the SQL server from my ASP? or should I have to use Named pipes?

Here is the Connection string that I used:
constr="Provider=SQLOLEDB;Network Library=DBMSSOCN;SERVER=xxx;Initial Catalog=mydb;User Id=user;Password=xxxxxx;"

When I use the above, I don't know what is happening.. but my IE animated picture at the top right corner is moving(i.e its talking to the server) without any response. Can anyone of you give me a clue why this is happening?
Also I am NOT receiving any error, like 'Connection timed out' , or Script Timed out. That makes me nervous.Try creating a dsn and test the connection and/or write a vb app that uses the ado data control and use the automated connection string creator and test the connection. If that works, copy the connection string from your ado data control to your asp page.|||I like to use TCP/IP to connect, even though you hear that Name Pipe is faster. The simplest thing to do to see if you can use TCP/IP from your IIS machine is to physically logon to your IIS machine and go to DOS and enter the PING command to your SQL Server machine. Make sure you PING by hostname and not by IP address. If you get a response, perfect use TCP/IP to connect. If you don't get a response and your SQL Server machine has a static IP address, then PING by IP Address. If that is fine then I would enter my SQL Server machine into an LMHost file.

asdb - what is it? Shold I back it up?

We developed a DB for our customer using MS Access and upsized it to
SQL Server. Our customer does daily back up of his DB and he asked me
whether or not 'asdb' should be backed up as well.

My question is: what is 'asdb' and whether or not it should be
backed up. Any information or web links will be appreciated.

Thanks,
Mark.mfine@.array.ca wrote:

Quote:

Originally Posted by

We developed a DB for our customer using MS Access and upsized it to
SQL Server. Our customer does daily back up of his DB and he asked me
whether or not 'asdb' should be backed up as well.
>
My question is: what is 'asdb' and whether or not it should be
backed up. Any information or web links will be appreciated.

Google turns up nothing obviously relevant. Ask the customer to
show you 'asdb' - maybe it's the name of another SQL or Access DB,
or maybe they meant something else but botched the name.|||Thaks.

Ed Murphy wrote:

Quote:

Originally Posted by

mfine@.array.ca wrote:
>

Quote:

Originally Posted by

We developed a DB for our customer using MS Access and upsized it to
SQL Server. Our customer does daily back up of his DB and he asked me
whether or not 'asdb' should be backed up as well.

My question is: what is 'asdb' and whether or not it should be
backed up. Any information or web links will be appreciated.

>
Google turns up nothing obviously relevant. Ask the customer to
show you 'asdb' - maybe it's the name of another SQL or Access DB,
or maybe they meant something else but botched the name.

|||mfine@.array.ca wrote:

Quote:

Originally Posted by

We developed a DB for our customer using MS Access and upsized it to
SQL Server. Our customer does daily back up of his DB and he asked me
whether or not 'asdb' should be backed up as well.
>
My question is: what is 'asdb' and whether or not it should be
backed up. Any information or web links will be appreciated.

Is it perhaps "msdb"? "The msdb database is used by SQL Server, SQL
Server Enterprise Manager, and SQL Server Agent to store data,
including scheduling information and backup and restore history
information." (SQL Server 2000)

If that sounds like something you will make use of, then Books Online
has tips on backing it up. If that information isn't useful in your
disaster recovery plan, don't bother - you can use this database to
manage backups and automated maintenance, but you can do without it,
restore your customer's data onto a newly installed server.

We presume your customer's data is in a specially created database and
not in one of the built-in ones.

I suppose database creation date also is likely to reflect whether the
database was created during installation of SQL Server, or when you
started using it. But if the database was yours, then you'd know,
surely?

Is someone else keeping data on the same server?|||I believe this is the database that Arcserve backup for windows uses.
Its a product by Computer Associates.
HTH
Rob
(open it up. if you see tables like asfilename, ashost, asjob,
asjobmap,
then this is what it is)

mfine@.array.ca wrote:

Quote:

Originally Posted by

We developed a DB for our customer using MS Access and upsized it to
SQL Server. Our customer does daily back up of his DB and he asked me
whether or not 'asdb' should be backed up as well.
>
My question is: what is 'asdb' and whether or not it should be
backed up. Any information or web links will be appreciated.
>
Thanks,
Mark.