Showing posts with label software. Show all posts
Showing posts with label software. Show all posts

Monday, March 12, 2012

Problem Displaying Japanese Characters

We are a software developer here and ran into a problem trying to get SQL Server to display Japanese Characters through a linked server properly. Does anybody have any similar experiences?

The following configurations were able to display Japanese characters properly:
===============================================================================
1. Write a C# application to get Japanese characters from an AS400 table containing Japanese texts. The Japanese text was displayed on the DataGrid. The provider used was HiT OLEDB Server/400. A 30 day eval copy can be obtained from the following link:
http://www.hitsw.com/products_services/register/register_oledb_svr_400.html

2. Create a table containing Japanese text on SQL Server A and create a linked server on SQL Server B linking to SQL Server A. Change the font type of SQL Server B's query analyzer to a font that is compatible with Japanese character. (See code sample one at the bottom of this message for the code used)

3. On a new PC, install Japanese edition of Windows 2000 plus Japanese Edition of SQL Server 2000. Create a linked server pointing to a Japanes table on the AS400 using the HiT OLEDB provider.

The following configurations were not able to display Japanese characters properly:
===================================================================================
i. On a PC with English version of Windows 2000 Professional and English version of SQL Server, change the query analyzer font to a font that is compitable with Japanese text and then use the HiT OLEDB provider to create a linked server pointing to the Japanese table on the AS400.

ii. On the same PC above, install IBM Client Access and make a new linked server pointing to the same Japanese table on the AS400 using Client Access. A Japanese compitable font was selected in the query anaylzer.

The odd thing is that in configuration (1), we were able to see the Japanese characters correctly which suggests that the HiT OLEDB provider has passed the information back to the PC correctly. And in configuration (2) and (3), we were able to show that SQL Server has no problem displaying Japanese characters regardless of its language edition.

We are not sure why it is behaving this way. Does anybody have any thought?

Here is the code used:

Code Sample One
===============
The following code was used on an English version of SQL Server 2000 running on an English version of Windows

2000 professional

if exists (select * from dbo.sysobjects where id = object_id(N'[dbo].[tblJap]') and OBJECTPROPERTY(id,

N'IsUserTable') = 1)
drop table [dbo].[tblJap]
GO

CREATE TABLE [dbo].[tblJap] (
[CID] [int] IDENTITY (1, 1) NOT NULL ,
[Jap] [nchar] (30) NOT NULL ,
[Eng] [char] (30) NOT NULL
) ON [PRIMARY]
GO

INSERT INTO tblJap (Jap, Eng) VALUES ('織田信長','Oda Nobunaga')
INSERT INTO tblJap (Jap, Eng) VALUES ('豊臣秀吉','Toyotomi Hideyoshi')
INSERT INTO tblJap (Jap, Eng) VALUES ('徳川家康','Tokugawa Ieyasu')
--See note below
GO

SELECT * FROM tblJap

Note
====
Another odd thing was that if I run the code
INSERT INTO tblJap (Jap, Eng) VALUES ('織田信長','Oda Nobunaga')
from query analyzer, the Japanese characters showed up as ? in Enterprise Manager. But if I edit the information again from Enterprise Manager, it shows up properly in both Enterprise Manager and Query Analyzer.

Results you are seeing might be due to the fact that you are inserting characters as regular chars and not as Unicode chars, and their translation (effectively truncation) is affected by Query Analyzer.

Instead of

INSERT INTO tblJap (Jap, Eng) VALUES ('...(Japanese chars)...','Oda Nobunaga')

try

INSERT INTO tblJap (Jap, Eng) VALUES (N'...(Japanese chars)...','Oda Nobunaga')

and see if that fixes your problem.

Regards,
Boris.|||Your solution is working fine.

Problem Displaying Japanese Characters

We are a software developer here and ran into a problem trying to get SQL Server to display Japanese Characters through a linked server properly. Does anybody have any similar experiences?

The following configurations were able to display Japanese characters properly:
===============================================================================
1. Write a C# application to get Japanese characters from an AS400 table containing Japanese texts. The Japanese text was displayed on the DataGrid. The provider used was HiT OLEDB Server/400. A 30 day eval copy can be obtained from the following link:
http://www.hitsw.com/products_services/register/register_oledb_svr_400.html

2. Create a table containing Japanese text on SQL Server A and create a linked server on SQL Server B linking to SQL Server A. Change the font type of SQL Server B's query analyzer to a font that is compatible with Japanese character. (See code sample one at the bottom of this message for the code used)

3. On a new PC, install Japanese edition of Windows 2000 plus Japanese Edition of SQL Server 2000. Create a linked server pointing to a Japanes table on the AS400 using the HiT OLEDB provider.

The following configurations were not able to display Japanese characters properly:
===================================================================================
i. On a PC with English version of Windows 2000 Professional and English version of SQL Server, change the query analyzer font to a font that is compitable with Japanese text and then use the HiT OLEDB provider to create a linked server pointing to the Japanese table on the AS400.

ii. On the same PC above, install IBM Client Access and make a new linked server pointing to the same Japanese table on the AS400 using Client Access. A Japanese compitable font was selected in the query anaylzer.

The odd thing is that in configuration (1), we were able to see the Japanese characters correctly which suggests that the HiT OLEDB provider has passed the information back to the PC correctly. And in configuration (2) and (3), we were able to show that SQL Server has no problem displaying Japanese characters regardless of its language edition.

We are not sure why it is behaving this way. Does anybody have any thought?

Here is the code used:

Code Sample One
===============
The following code was used on an English version of SQL Server 2000 running on an English version of Windows

2000 professional

if exists (select * from dbo.sysobjects where id = object_id(N'[dbo].[tblJap]') and OBJECTPROPERTY(id,

N'IsUserTable') = 1)
drop table [dbo].[tblJap]
GO

CREATE TABLE [dbo].[tblJap] (
[CID] [int] IDENTITY (1, 1) NOT NULL ,
[Jap] [nchar] (30) NOT NULL ,
[Eng] [char] (30) NOT NULL
) ON [PRIMARY]
GO

INSERT INTO tblJap (Jap, Eng) VALUES ('織田信長','Oda Nobunaga')
INSERT INTO tblJap (Jap, Eng) VALUES ('豊臣秀吉','Toyotomi Hideyoshi')
INSERT INTO tblJap (Jap, Eng) VALUES ('徳川家康','Tokugawa Ieyasu')
--See note below
GO

SELECT * FROM tblJap

Note
====
Another odd thing was that if I run the code
INSERT INTO tblJap (Jap, Eng) VALUES ('織田信長','Oda Nobunaga')
from query analyzer, the Japanese characters showed up as ? in Enterprise Manager. But if I edit the information again from Enterprise Manager, it shows up properly in both Enterprise Manager and Query Analyzer.

Results you are seeing might be due to the fact that you are inserting characters as regular chars and not as Unicode chars, and their translation (effectively truncation) is affected by Query Analyzer.

Instead of

INSERT INTO tblJap (Jap, Eng) VALUES ('...(Japanese chars)...','Oda Nobunaga')

try

INSERT INTO tblJap (Jap, Eng) VALUES (N'...(Japanese chars)...','Oda Nobunaga')

and see if that fixes your problem.

Regards,
Boris.

|||Your solution is working fine.

Problem Displaying Japanese Characters

We are a software developer here and ran into a problem trying to get SQL
Server Query Analyzer to display Japanese Characters fetched through a linked
server properly. Can someone comment on the situation?
The following configurations were able to display Japanese characters
properly:
================================================== ===
1. Write a C# application to get Japanese characters from an AS400 table
containing Japanese texts. The Japanese text was displayed on the DataGrid.
The provider used was HiT OLEDB Server/400. A 30 day eval copy can be
obtained from the following link:
http://www.hitsw.com/products_servic...b_svr_400.html
2. Create a table containing Japanese text on SQL Server A and create a
linked server on SQL Server B linking to SQL Server A. Change the font type
of SQL Server B's query analyzer to a font that is compatible with Japanese
character. (See the bottom of this message for the code used to create the
table on SQL Sever A)
3. On a new PC, install Japanese edition of Windows 2000 plus Japanese
Edition of SQL Server 2000. Create a linked server pointing to a Japanes
table on the AS400 using the HiT OLEDB provider.
The following configurations were not able to display Japanese characters
properly:
================================================== ===
i. On a PC with English version of Windows 2000 Professional and English
version of SQL Server, change the query analyzer font to a font that is
compitable with Japanese text and then use the HiT OLEDB provider to create a
linked server pointing to the Japanese table on the AS400.
ii. On the same PC above, install IBM Client Access and make a new linked
server pointing to the same Japanese table on the AS400 using Client Access.
A Japanese compitable font was selected in the query anaylzer.
The odd thing is that in configuration (1), we were able to see the Japanese
characters correctly which suggests that the HiT OLEDB provider has passed
the information back to the PC correctly. And in configuration (2) and (3),
we were able to show that SQL Server Query Analyzer has no problem displaying
Japanese characters regardless of its language edition.
We are not sure why it is behaving this way. Does anybody have any thought?
Here is the code used to generate the table on SQL Server:
Code Sample One
===============
The following code was used on an English version of SQL Server 2000 running
on an English version of Windows
2000 professional
if exists (select * from dbo.sysobjects where id =
object_id(N'[dbo].[tblJap]') and OBJECTPROPERTY(id,
N'IsUserTable') = 1)
drop table [dbo].[tblJap]
GO
CREATE TABLE [dbo].[tblJap] (
[CID] [int] IDENTITY (1, 1) NOT NULL ,
[Jap] [nchar] (30) NOT NULL ,
[Eng] [char] (30) NOT NULL
) ON [PRIMARY]
GO
INSERT INTO tblJap (Jap, Eng) VALUES ('織田信長','Oda Nobunaga')
INSERT INTO tblJap (Jap, Eng) VALUES ('豊臣秀吉','Toyotomi Hideyoshi')
INSERT INTO tblJap (Jap, Eng) VALUES ('徳川家康','Tokugawa Ieyasu')
--See note below
GO
SELECT * FROM tblJap
Note
====
Another odd thing was that if I run the code
INSERT INTO tblJap (Jap, Eng) VALUES ('織田信長','Oda Nobunaga')
from query analyzer, the Japanese characters showed up as ? in Enterprise
Manager. But if I edit the information again from Enterprise Manager, it
shows up properly in both Enterprise Manager and Query Analyzer.
Fabio,
Probably a problem with the way the HiT driver handles DBCS characters.
I suggest you try with StarSQL (www.starquest.com), it is another quite
reliable driver for DB2 and the support is pretty good.
Good luck,
Bob
Fabio Boscaini a =C3=A9crit :
> We are a software developer here and ran into a problem trying to get SQL
> Server Query Analyzer to display Japanese Characters fetched through a li=
nked
> server properly. Can someone comment on the situation?
> The following configurations were able to display Japanese characters
> properly:
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3 D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3 D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D
> 1. Write a C# application to get Japanese characters from an AS400 table
> containing Japanese texts. The Japanese text was displayed on the DataGri=
d=2E
> The provider used was HiT OLEDB Server/400. A 30 day eval copy can be
> obtained from the following link:
> http://www.hitsw.com/products_servic...db_svr_400.ht=
ml
> 2. Create a table containing Japanese text on SQL Server A and create a
> linked server on SQL Server B linking to SQL Server A. Change the font ty=
pe
> of SQL Server B's query analyzer to a font that is compatible with Japane=
se
> character. (See the bottom of this message for the code used to create the
> table on SQL Sever A)
> 3. On a new PC, install Japanese edition of Windows 2000 plus Japanese
> Edition of SQL Server 2000. Create a linked server pointing to a Japanes
> table on the AS400 using the HiT OLEDB provider.
> The following configurations were not able to display Japanese characters
> properly:
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3 D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3 D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D
> i. On a PC with English version of Windows 2000 Professional and English
> version of SQL Server, change the query analyzer font to a font that is
> compitable with Japanese text and then use the HiT OLEDB provider to crea=
te a
> linked server pointing to the Japanese table on the AS400.
> ii. On the same PC above, install IBM Client Access and make a new linked
> server pointing to the same Japanese table on the AS400 using Client Acce=
ss.
> A Japanese compitable font was selected in the query anaylzer.
> The odd thing is that in configuration (1), we were able to see the Japan=
ese
> characters correctly which suggests that the HiT OLEDB provider has passed
> the information back to the PC correctly. And in configuration (2) and (3=
),
> we were able to show that SQL Server Query Analyzer has no problem displa=
ying
> Japanese characters regardless of its language edition.
> We are not sure why it is behaving this way. Does anybody have any though=
t?
> Here is the code used to generate the table on SQL Server:
> Code Sample One
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> The following code was used on an English version of SQL Server 2000 runn=
ing
> on an English version of Windows
> 2000 professional
> if exists (select * from dbo.sysobjects where id =3D
> object_id(N'[dbo].[tblJap]') and OBJECTPROPERTY(id,
> N'IsUserTable') =3D 1)
> drop table [dbo].[tblJap]
> GO
> CREATE TABLE [dbo].[tblJap] (
> [CID] [int] IDENTITY (1, 1) NOT NULL ,
> [Jap] [nchar] (30) NOT NULL ,
> [Eng] [char] (30) NOT NULL
> ) ON [PRIMARY]
> GO
> INSERT INTO tblJap (Jap, Eng) VALUES ('=E7=B9=94=E7=94=B0=E4=BF=A1=E9=95=
=B7','Oda Nobunaga')
> INSERT INTO tblJap (Jap, Eng) VALUES ('=E8=B1=8A=E8=87=A3=E7=A7=80=E5=90=
=89','Toyotomi Hideyoshi')
> INSERT INTO tblJap (Jap, Eng) VALUES ('=E5=BE=B3=E5=B7=9D=E5=AE=B6=E5=BA=
=B7','Tokugawa Ieyasu')
> --See note below
> GO
> SELECT * FROM tblJap
> Note
> =3D=3D=3D=3D
> Another odd thing was that if I run the code
> INSERT INTO tblJap (Jap, Eng) VALUES ('=E7=B9=94=E7=94=B0=E4=BF=A1=E9=95=
=B7','Oda Nobunaga')
> from query analyzer, the Japanese characters showed up as ? in Enterpr=
ise
> Manager. But if I edit the information again from Enterprise Manager, it
> shows up properly in both Enterprise Manager and Query Analyzer.

Monday, February 20, 2012

Problem connecting to SQL Server over the internet

I have opened ports 1433 and 1434 on a SQL Server on our network to allow
our customers to receive a monthly subscription "key" for the software they
lease from us. Within an encrypted Stored Procedure I am using the
OPENDATASOURCE method with a connect string containing our IP address. It is
working on 90% of the sites. However some of the sites are receiving an
error:
Server: Msg 17, Level 16, State 1, Procedure PLSPSYS_ALTER_KEYSP_REMOTE,
Line 37
SQL Server does not exist or access denied.
On most of the servers where the procedure is WORKING, a peek at the
firewall configuration using Shields-Up service from Gibson Research shows
that ports 1433 and 1434 are in Stealth mode. But, as I said, the connection
is still operating just fine. All sites, including the ones that don't work,
have the TCP/IP protocol enabled in the Client Network Utility on Port 1433.
So I am at a loss to figure out why the Internet connection is not working
at some sites. Any ideas?
Also, is there another way that I can distribute the "key" without user
intervention using "back-end" programs or procedures? Is there a way to
connect and retieve data via port 80 which is usually left open for outbound
requests? Thanks in advance...
I would make network traces at the problem site and either review the
firewall logs or
make simulataneous traces on the server. This sounds like a tcp issue not
a SQL issue.
Verify that the 3 way tcp handshake is completing. The login packet isn't
sent until this completes.
Thanks,
Kevin McDonnell
Microsoft Corporation
This posting is provided AS IS with no warranties, and confers no rights.
|||Thank you both for your replies. I will make sure that the TCP issues are
resolved at the client sites before looking any further.
"John Kotuby" <jkotuby@.snet.net> wrote in message
news:undiWF%23TEHA.2028@.TK2MSFTNGP11.phx.gbl...
> I have opened ports 1433 and 1434 on a SQL Server on our network to allow
> our customers to receive a monthly subscription "key" for the software
they
> lease from us. Within an encrypted Stored Procedure I am using the
> OPENDATASOURCE method with a connect string containing our IP address. It
is
> working on 90% of the sites. However some of the sites are receiving an
> error:
> Server: Msg 17, Level 16, State 1, Procedure PLSPSYS_ALTER_KEYSP_REMOTE,
> Line 37
> SQL Server does not exist or access denied.
> On most of the servers where the procedure is WORKING, a peek at the
> firewall configuration using Shields-Up service from Gibson Research shows
> that ports 1433 and 1434 are in Stealth mode. But, as I said, the
connection
> is still operating just fine. All sites, including the ones that don't
work,
> have the TCP/IP protocol enabled in the Client Network Utility on Port
1433.
> So I am at a loss to figure out why the Internet connection is not working
> at some sites. Any ideas?
> Also, is there another way that I can distribute the "key" without user
> intervention using "back-end" programs or procedures? Is there a way to
> connect and retieve data via port 80 which is usually left open for
outbound
> requests? Thanks in advance...
>

Problem connecting to SQL Server over the internet

I have opened ports 1433 and 1434 on a SQL Server on our network to allow
our customers to receive a monthly subscription "key" for the software they
lease from us. Within an encrypted Stored Procedure I am using the
OPENDATASOURCE method with a connect string containing our IP address. It is
working on 90% of the sites. However some of the sites are receiving an
error:
Server: Msg 17, Level 16, State 1, Procedure PLSPSYS_ALTER_KEYSP_REMOTE,
Line 37
SQL Server does not exist or access denied.
On most of the servers where the procedure is WORKING, a peek at the
firewall configuration using Shields-Up service from Gibson Research shows
that ports 1433 and 1434 are in Stealth mode. But, as I said, the connection
is still operating just fine. All sites, including the ones that don't work,
have the TCP/IP protocol enabled in the Client Network Utility on Port 1433.
So I am at a loss to figure out why the Internet connection is not working
at some sites. Any ideas?
Also, is there another way that I can distribute the "key" without user
intervention using "back-end" programs or procedures? Is there a way to
connect and retieve data via port 80 which is usually left open for outbound
requests? Thanks in advance...I would make network traces at the problem site and either review the
firewall logs or
make simulataneous traces on the server. This sounds like a tcp issue not
a SQL issue.
Verify that the 3 way tcp handshake is completing. The login packet isn't
sent until this completes.
Thanks,
Kevin McDonnell
Microsoft Corporation
This posting is provided AS IS with no warranties, and confers no rights.|||Thank you both for your replies. I will make sure that the TCP issues are
resolved at the client sites before looking any further.
"John Kotuby" <jkotuby@.snet.net> wrote in message
news:undiWF%23TEHA.2028@.TK2MSFTNGP11.phx.gbl...
> I have opened ports 1433 and 1434 on a SQL Server on our network to allow
> our customers to receive a monthly subscription "key" for the software
they
> lease from us. Within an encrypted Stored Procedure I am using the
> OPENDATASOURCE method with a connect string containing our IP address. It
is
> working on 90% of the sites. However some of the sites are receiving an
> error:
> Server: Msg 17, Level 16, State 1, Procedure PLSPSYS_ALTER_KEYSP_REMOTE,
> Line 37
> SQL Server does not exist or access denied.
> On most of the servers where the procedure is WORKING, a peek at the
> firewall configuration using Shields-Up service from Gibson Research shows
> that ports 1433 and 1434 are in Stealth mode. But, as I said, the
connection
> is still operating just fine. All sites, including the ones that don't
work,
> have the TCP/IP protocol enabled in the Client Network Utility on Port
1433.
> So I am at a loss to figure out why the Internet connection is not working
> at some sites. Any ideas?
> Also, is there another way that I can distribute the "key" without user
> intervention using "back-end" programs or procedures? Is there a way to
> connect and retieve data via port 80 which is usually left open for
outbound
> requests? Thanks in advance...
>