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

ASP COM and database access

Hello All,

I am currently creating a browser interface for our thick client which
was built on Visual Basic using COM ( a three tier environment). We
support environments where the SQL database server is separate from the
application server.

The problem I am facing is this.

When I try to access the database server from the ASP page through the
COM object, I get access denied. This is because the COM is running
under the IWAM account and it does not have access to the database
tables. Since this is a system account I cannot add it to the database
server which is on a different machine possible a different domain too.
When I gave anonymous access to the database server, it worked fine but
this is obvously not a solution I want. The other option is to create a
COM+ wrapper for every objects (possibly 100)which can be run under a
specific account. But this will be a huge task.
Are there any other options? Any ideas are appreciated.
Thanks
SatishHi.I think this id COM fault not Database server.

Try to change access permissions using "dcomcnfg". On the Server where
IIS running.
Add IWAM account to allow access and to launch com objects.
It woks fine in my case. And i had the same situation.

sss wrote:
> Hello All,
>
> I am currently creating a browser interface for our thick client
which
> was built on Visual Basic using COM ( a three tier environment). We
> support environments where the SQL database server is separate from
the
> application server.
>
> The problem I am facing is this.
>
> When I try to access the database server from the ASP page through
the
> COM object, I get access denied. This is because the COM is running
> under the IWAM account and it does not have access to the database
> tables. Since this is a system account I cannot add it to the
database
> server which is on a different machine possible a different domain
too.
> When I gave anonymous access to the database server, it worked fine
but
> this is obvously not a solution I want. The other option is to create
a
> COM+ wrapper for every objects (possibly 100)which can be run under a
> specific account. But this will be a huge task.
> Are there any other options? Any ideas are appreciated.
> Thanks
> Satishsql

Are these the correct steps? Encrypted Connection String and Security

Hi,

Assume I have an asp.net/sql server 2000 web app in a shared hosting
environment. I then encrypt the connection string using
ProtectSection("DataProtectionConfigurationProvider") in the page load
of my default.aspx page.

Am I understanding the following concepts then correctly?

1. I upload the site to the shared hosting server.
2. The first time I run the app eg. www.whatever.com/default.aspx,
the ProtectSection method above is executed.
3. Now the conn string area of my web.config is encrypted, and
asp.net will decrypt as needed.

4. If someone were to hack the server and view the web.config --
whether via getting into the server or via ftp, they would see an
encrypted connection string.

Thanks very much!If the hosting server is shared then there is a risk, if not you have to rely upon the ISP.

Are rpts created w/ SQL 2005 CTP compatible with RS 2000?

We have been developing reports for an application using SQL 2005 CTP
version. Turned out that we cannot install it in the production
environment. We can however install SQL 2000 RS. Does anyone know if
reports developed in SQL 2005 CTP can be deployed to SQL 2000 RS? I was
going to try it today but after SP2 to the SQL 2000 RS. The RS 2000 SP2
doesn't run because of the different version in the databases used by RS.
I'd like to know if the reports would work on 2000 or not before spending
more time trying to figure out how to make RS 2000 SP2 work. Thanks a lot
for any help.No, you can do this the other way. RS 2000 reports in RS 2005 but not the
other way.
Bruce Loehle-Conger
MVP SQL Server Reporting Services
"Bob" <bobatkpmg@.yahoo.com> wrote in message
news:ej%233sQ5pFHA.3104@.TK2MSFTNGP12.phx.gbl...
> We have been developing reports for an application using SQL 2005 CTP
> version. Turned out that we cannot install it in the production
> environment. We can however install SQL 2000 RS. Does anyone know if
> reports developed in SQL 2005 CTP can be deployed to SQL 2000 RS? I was
> going to try it today but after SP2 to the SQL 2000 RS. The RS 2000 SP2
> doesn't run because of the different version in the databases used by RS.
> I'd like to know if the reports would work on 2000 or not before spending
> more time trying to figure out how to make RS 2000 SP2 work. Thanks a lot
> for any help.
>|||I wonder if a bit of XSLT could remedy this problem.|||Yes, you could use an XSLT to change the namespace in the RDL files from
2005/01 to 2003/10. In addition, you need to make sure that you remove all
RS 2005 specific additions to the XSD. Specifically, you have to remove the
InteractiveWidth and InteractiveHeight elements. Furthermore, you cannot use
any new RS 2005 RDL features (e.g. Fixed headers).
-- Robert
This posting is provided "AS IS" with no warranties, and confers no rights.
"Lance" <lancehunt@.gmail.com> wrote in message
news:1124810278.462665.127660@.g43g2000cwa.googlegroups.com...
>I wonder if a bit of XSLT could remedy this problem.
>