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 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 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|||xfile wrote:
> 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 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
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:
>> 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 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
> 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:
>> 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|||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:
>> 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

Asking the user a question

Hello all,

I have a client with an application that they have purchased, it
stores its data on SQL server 2000 and so I am able to do reports and
some small VB apps that use the data. I can't however make any
significant changes to the app itself, just what it allows you to
configure.

The system records jobs, when a job is closed the client want a prompt
to pop-up asking if they want to record that the job is closed in a
special log file. I suggested that we use a checkbox (We can add
custom fields to the app) to record this, then I could write a trigger
that checks that field and adds it to the log file if it's 1, but no
they want a yes/no message box type thing popping up.

Is it possible to display (on the users screen) and get input back
from a yes/no message box in a SQL Server trigger? As far as I can
tell it isn't but it would be great if I were wrong.

Any help/suggestions greatly appreciated!!!

Thanks,

Bob.SQL Server can't invoke anything in your UI. That's something you have to do
in client-side code.

--
David Portas
SQL Server MVP
--|||Robert Hogan (busrhogan@.hotmail.com) writes:
> Is it possible to display (on the users screen) and get input back
> from a yes/no message box in a SQL Server trigger? As far as I can
> tell it isn't but it would be great if I were wrong.

In theory, yes. But for crying out loud, don't do it!

You could use sp_OAmethod and friends to run a remote OLE object
that would wait for the reponse.

But while waiting for user input - which could take several hours or
days - you are in the middle of a transaction, data will be uncommitted
and locks will be held. Could have sever impact on the situation.

A variant would be to have the OLE thing asynchronous, so that the
trigger does not wait for input, and the OLE thing would then update
the database itself.

--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techin.../2000/books.asp|||
"Robert Hogan" <busrhogan@.hotmail.com> wrote in message
news:eb62f112.0501171614.cb68c36@.posting.google.co m...
> Hello all,
> I have a client with an application that they have purchased, it
> stores its data on SQL server 2000 and so I am able to do reports and
> some small VB apps that use the data. I can't however make any
> significant changes to the app itself, just what it allows you to
> configure.
> The system records jobs, when a job is closed the client want a prompt
> to pop-up asking if they want to record that the job is closed in a
> special log file.

Well...
This is the problem with buying a package.
They do what the people wrote them guessed you wanted.
How close that is to what you do depends on how good he guessed.

> I suggested that we use a checkbox (We can add
> custom fields to the app) to record this, then I could write a trigger
> that checks that field and adds it to the log file if it's 1, but no
> they want a yes/no message box type thing popping up.

No chance.
You/They have 4 practical options:

1) Bung the field on and use a trigger to write the stuff as you suggest.

2) Contact the people wrote the package and pay them to make a custom
change.
If they're happy to do this then remember upgrades and expect to pay
through the nose for that confirmation box.

3) Re-write the package from scratch.
Probably financially unattractive unless they have a lot of reports and
customisation in mind.

4) Work out what that screen does and write one yourself that replaces it.
Some packages allow you to have custom screens, I'd guess maybe this
isn't one so maybe not so practical.
If that one screen and your other additions is all whoever closes jobs
uses then maybe it is a go-er.
> Is it possible to display (on the users screen) and get input back
> from a yes/no message box in a SQL Server trigger? As far as I can
> tell it isn't but it would be great if I were wrong.
> Any help/suggestions greatly appreciated!!!

Next time they buy a package..
Remember the hidden costs.
It's can be far cheaper to go for a bespoke app in the long run.

> Thanks,
> Bob.

--
Regards,
Andy O'Neillsql