changing column type

Hi I have transactional replication and I need a tables column data type
changed from char(30) to varchar(40). What would be the best way and least
dangerous to edit this column and get it to replicate the changes succesfully.
thanks for any advice
Sammy
Sammy,
please check out these articles:
http://www.replicationanswers.com/AddColumn.asp
and
http://www.replicationanswers.com/AlterSchema2005.asp
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)

Changing char length in stored procedures

Hello all, I'm using SQL Server 2000 and have about 250 stored procedures that use an EMPLID parameter or variable of type varchar with a length of 4. I need to change the length to 10 instead and would like to do so without having to open every sp for editing. Is there a way to do this through SQL Server 2000? Does anyone have a script to do this? Any help would be appreciated.I'd use SQL Enterprise Mangler to script all of the stored procedures, then a text editor to make the changes. It should be a simple replace operation, possibly using a regexp if you aren't careful about how you format your declarations.

-PatP

Changed from char to varchar

i changed my state table from char 20 to varchar 20 and it still fills it with empty space at the end of the statename
I tried entering it with the trim command still no good
i looked a the sql command made in vs and it says that the variables are varchar
is there something i am missing with varchar
does it only work properly if it is over 50 or does it not change completely when you change from char to varcharIt shouldn't be padding the fields if using varchar. Your existng values would have to be trimmed. I don't think changing the datatype would automatically do that for you.

Check the ANSI_PADDING database option, also.|||alright i will look into it

Change user type from char to vchar

We have a requirement to change a user defined type from char(4) to vchar(4).
I was wondering whether there's a easier(quickest) method to do this as opposed to:
- Drop dependent storedprocs and views
- rename type
- add type with new def
- reattach table columns
- drop old type
- recreate storedprocs,views
Yes, we have quite a few tables, storedproc and views that reference this type.
Thanks,
Manod
ALTER TABLE ...
ALTER COLUMN
The stored procedure, view, and function dependencies should not matter;
however, you probably will have to drop and recreate any PKC, UC, FKC, CC,
and Defaults that may be created on this field.
If you use the database designer tool, EM will usually script out a new
table with all of the dependency drops and recreates, move all of the data,
and drop and rename the tables for you.
This is usually not the best way to do this, especially for very large
tables, but you can "SAVE AS SCRIPT" instead of executing it. This is a
good way to learn at least the details if not a poorer solution.
Sincerely,
Anthony Thomas

"sandiyan" <sandiyan@.yahoo.co.uk> wrote in message
news:69e9c64b.0503090211.3552c797@.posting.google.c om...
We have a requirement to change a user defined type from char(4) to
vchar(4).
I was wondering whether there's a easier(quickest) method to do this as
opposed to:
- Drop dependent storedprocs and views
- rename type
- add type with new def
- reattach table columns
- drop old type
- recreate storedprocs,views
Yes, we have quite a few tables, storedproc and views that reference this
type.
Thanks,
Manod
|||Thanks Anthony...I was hoping that there would be an easier option than going
through and sorting out dependencies and etc...
I hope this will be addressed in sql2005 - my bet is not!
regards,
Sandiyan.
"Anthony Thomas" wrote:

> ALTER TABLE ...
> ALTER COLUMN
> The stored procedure, view, and function dependencies should not matter;
> however, you probably will have to drop and recreate any PKC, UC, FKC, CC,
> and Defaults that may be created on this field.
> If you use the database designer tool, EM will usually script out a new
> table with all of the dependency drops and recreates, move all of the data,
> and drop and rename the tables for you.
> This is usually not the best way to do this, especially for very large
> tables, but you can "SAVE AS SCRIPT" instead of executing it. This is a
> good way to learn at least the details if not a poorer solution.
> Sincerely,
>
> Anthony Thomas
|||Well, there is. As I stated before, if you use the Table Designer through
the EM, it will handle all of the scripting for you. It usually will just
do the creat, copy, drop, replace method, which can work, but it will take a
lot of resources to pull off on larger tables. The same could be done, just
do the same thing except save as script instead save. Keep the drop and
create dependencies, just replace the create, copy, and rename table pieces
with a single ALTER TABLE ... ALTER COLUMN statement. At leas this way, you
would have to parse the dependencies.
There is a caveat to this, however; the EM uses the sysdependencies to
script out all the drops and creates. If you have ever renamed an object
without dropping and recreating the dependencies, and have gotten that
little error message, this means the records in this system table have not
been updated to reflect the name change. So, the little wizard inside the
EM scripter will not catch everything...but your errors will.
Good luck.
Anthony Thomas

"Sandiyan" <sandiyan@.yahoo.co.uk> wrote in message
news:15EEA5C6-8281-41FB-8287-085E1193F84F@.microsoft.com...
Thanks Anthony...I was hoping that there would be an easier option than
going
through and sorting out dependencies and etc...
I hope this will be addressed in sql2005 - my bet is not!
regards,
Sandiyan.
"Anthony Thomas" wrote:

> ALTER TABLE ...
> ALTER COLUMN
> The stored procedure, view, and function dependencies should not matter;
> however, you probably will have to drop and recreate any PKC, UC, FKC, CC,
> and Defaults that may be created on this field.
> If you use the database designer tool, EM will usually script out a new
> table with all of the dependency drops and recreates, move all of the
data,
> and drop and rename the tables for you.
> This is usually not the best way to do this, especially for very large
> tables, but you can "SAVE AS SCRIPT" instead of executing it. This is a
> good way to learn at least the details if not a poorer solution.
> Sincerely,
>
> Anthony Thomas

Change user type from char to vchar

We have a requirement to change a user defined type from char(4) to vchar(4)
.
I was wondering whether there's a easier(quickest) method to do this as oppo
sed to:
- Drop dependent storedprocs and views
- rename type
- add type with new def
- reattach table columns
- drop old type
- recreate storedprocs,views
Yes, we have quite a few tables, storedproc and views that reference this ty
pe.
Thanks,
ManodALTER TABLE ...
ALTER COLUMN
The stored procedure, view, and function dependencies should not matter;
however, you probably will have to drop and recreate any PKC, UC, FKC, CC,
and Defaults that may be created on this field.
If you use the database designer tool, EM will usually script out a new
table with all of the dependency drops and recreates, move all of the data,
and drop and rename the tables for you.
This is usually not the best way to do this, especially for very large
tables, but you can "SAVE AS SCRIPT" instead of executing it. This is a
good way to learn at least the details if not a poorer solution.
Sincerely,
Anthony Thomas
"sandiyan" <sandiyan@.yahoo.co.uk> wrote in message
news:69e9c64b.0503090211.3552c797@.posting.google.com...
We have a requirement to change a user defined type from char(4) to
vchar(4).
I was wondering whether there's a easier(quickest) method to do this as
opposed to:
- Drop dependent storedprocs and views
- rename type
- add type with new def
- reattach table columns
- drop old type
- recreate storedprocs,views
Yes, we have quite a few tables, storedproc and views that reference this
type.
Thanks,
Manod|||Thanks Anthony...I was hoping that there would be an easier option than goin
g
through and sorting out dependencies and etc...
I hope this will be addressed in sql2005 - my bet is not!
regards,
Sandiyan.
"Anthony Thomas" wrote:

> ALTER TABLE ...
> ALTER COLUMN
> The stored procedure, view, and function dependencies should not matter;
> however, you probably will have to drop and recreate any PKC, UC, FKC, CC,
> and Defaults that may be created on this field.
> If you use the database designer tool, EM will usually script out a new
> table with all of the dependency drops and recreates, move all of the data
,
> and drop and rename the tables for you.
> This is usually not the best way to do this, especially for very large
> tables, but you can "SAVE AS SCRIPT" instead of executing it. This is a
> good way to learn at least the details if not a poorer solution.
> Sincerely,
>
> Anthony Thomas|||Well, there is. As I stated before, if you use the Table Designer through
the EM, it will handle all of the scripting for you. It usually will just
do the creat, copy, drop, replace method, which can work, but it will take a
lot of resources to pull off on larger tables. The same could be done, just
do the same thing except save as script instead save. Keep the drop and
create dependencies, just replace the create, copy, and rename table pieces
with a single ALTER TABLE ... ALTER COLUMN statement. At leas this way, you
would have to parse the dependencies.
There is a caveat to this, however; the EM uses the sysdependencies to
script out all the drops and creates. If you have ever renamed an object
without dropping and recreating the dependencies, and have gotten that
little error message, this means the records in this system table have not
been updated to reflect the name change. So, the little wizard inside the
EM scripter will not catch everything...but your errors will.
Good luck.
Anthony Thomas
"Sandiyan" <sandiyan@.yahoo.co.uk> wrote in message
news:15EEA5C6-8281-41FB-8287-085E1193F84F@.microsoft.com...
Thanks Anthony...I was hoping that there would be an easier option than
going
through and sorting out dependencies and etc...
I hope this will be addressed in sql2005 - my bet is not!
regards,
Sandiyan.
"Anthony Thomas" wrote:

> ALTER TABLE ...
> ALTER COLUMN
> The stored procedure, view, and function dependencies should not matter;
> however, you probably will have to drop and recreate any PKC, UC, FKC, CC,
> and Defaults that may be created on this field.
> If you use the database designer tool, EM will usually script out a new
> table with all of the dependency drops and recreates, move all of the
data,
> and drop and rename the tables for you.
> This is usually not the best way to do this, especially for very large
> tables, but you can "SAVE AS SCRIPT" instead of executing it. This is a
> good way to learn at least the details if not a poorer solution.
> Sincerely,
>
> Anthony Thomas

Change user type from char to vchar

We have a requirement to change a user defined type from char(4) to vchar(4)
.
I was wondering whether there's a easier(quickest) method to do this as oppo
sed to:
- Drop dependent storedprocs and views
- rename type
- add type with new def
- reattach table columns
- drop old type
- recreate storedprocs,views
Yes, we have quite a few tables, storedproc and views that reference this ty
pe.
Thanks,
ManodALTER TABLE ...
ALTER COLUMN
The stored procedure, view, and function dependencies should not matter;
however, you probably will have to drop and recreate any PKC, UC, FKC, CC,
and Defaults that may be created on this field.
If you use the database designer tool, EM will usually script out a new
table with all of the dependency drops and recreates, move all of the data,
and drop and rename the tables for you.
This is usually not the best way to do this, especially for very large
tables, but you can "SAVE AS SCRIPT" instead of executing it. This is a
good way to learn at least the details if not a poorer solution.
Sincerely,
Anthony Thomas
"sandiyan" <sandiyan@.yahoo.co.uk> wrote in message
news:69e9c64b.0503090211.3552c797@.posting.google.com...
We have a requirement to change a user defined type from char(4) to
vchar(4).
I was wondering whether there's a easier(quickest) method to do this as
opposed to:
- Drop dependent storedprocs and views
- rename type
- add type with new def
- reattach table columns
- drop old type
- recreate storedprocs,views
Yes, we have quite a few tables, storedproc and views that reference this
type.
Thanks,
Manod|||Thanks Anthony...I was hoping that there would be an easier option than goin
g
through and sorting out dependencies and etc...
I hope this will be addressed in sql2005 - my bet is not!
regards,
Sandiyan.
"Anthony Thomas" wrote:

> ALTER TABLE ...
> ALTER COLUMN
> The stored procedure, view, and function dependencies should not matter;
> however, you probably will have to drop and recreate any PKC, UC, FKC, CC,
> and Defaults that may be created on this field.
> If you use the database designer tool, EM will usually script out a new
> table with all of the dependency drops and recreates, move all of the data
,
> and drop and rename the tables for you.
> This is usually not the best way to do this, especially for very large
> tables, but you can "SAVE AS SCRIPT" instead of executing it. This is a
> good way to learn at least the details if not a poorer solution.
> Sincerely,
>
> Anthony Thomas|||Well, there is. As I stated before, if you use the Table Designer through
the EM, it will handle all of the scripting for you. It usually will just
do the creat, copy, drop, replace method, which can work, but it will take a
lot of resources to pull off on larger tables. The same could be done, just
do the same thing except save as script instead save. Keep the drop and
create dependencies, just replace the create, copy, and rename table pieces
with a single ALTER TABLE ... ALTER COLUMN statement. At leas this way, you
would have to parse the dependencies.
There is a caveat to this, however; the EM uses the sysdependencies to
script out all the drops and creates. If you have ever renamed an object
without dropping and recreating the dependencies, and have gotten that
little error message, this means the records in this system table have not
been updated to reflect the name change. So, the little wizard inside the
EM scripter will not catch everything...but your errors will.
Good luck.
Anthony Thomas
"Sandiyan" <sandiyan@.yahoo.co.uk> wrote in message
news:15EEA5C6-8281-41FB-8287-085E1193F84F@.microsoft.com...
Thanks Anthony...I was hoping that there would be an easier option than
going
through and sorting out dependencies and etc...
I hope this will be addressed in sql2005 - my bet is not!
regards,
Sandiyan.
"Anthony Thomas" wrote:

> ALTER TABLE ...
> ALTER COLUMN
> The stored procedure, view, and function dependencies should not matter;
> however, you probably will have to drop and recreate any PKC, UC, FKC, CC,
> and Defaults that may be created on this field.
> If you use the database designer tool, EM will usually script out a new
> table with all of the dependency drops and recreates, move all of the
data,
> and drop and rename the tables for you.
> This is usually not the best way to do this, especially for very large
> tables, but you can "SAVE AS SCRIPT" instead of executing it. This is a
> good way to learn at least the details if not a poorer solution.
> Sincerely,
>
> Anthony Thomas

Change user type from char to vchar

We have a requirement to change a user defined type from char(4) to vchar(4).
I was wondering whether there's a easier(quickest) method to do this as opposed to:
- Drop dependent storedprocs and views
- rename type
- add type with new def
- reattach table columns
- drop old type
- recreate storedprocs,views
Yes, we have quite a few tables, storedproc and views that reference this type.
Thanks,
ManodALTER TABLE ...
ALTER COLUMN
The stored procedure, view, and function dependencies should not matter;
however, you probably will have to drop and recreate any PKC, UC, FKC, CC,
and Defaults that may be created on this field.
If you use the database designer tool, EM will usually script out a new
table with all of the dependency drops and recreates, move all of the data,
and drop and rename the tables for you.
This is usually not the best way to do this, especially for very large
tables, but you can "SAVE AS SCRIPT" instead of executing it. This is a
good way to learn at least the details if not a poorer solution.
Sincerely,
Anthony Thomas
"sandiyan" <sandiyan@.yahoo.co.uk> wrote in message
news:69e9c64b.0503090211.3552c797@.posting.google.com...
We have a requirement to change a user defined type from char(4) to
vchar(4).
I was wondering whether there's a easier(quickest) method to do this as
opposed to:
- Drop dependent storedprocs and views
- rename type
- add type with new def
- reattach table columns
- drop old type
- recreate storedprocs,views
Yes, we have quite a few tables, storedproc and views that reference this
type.
Thanks,
Manod|||Thanks Anthony...I was hoping that there would be an easier option than going
through and sorting out dependencies and etc...
I hope this will be addressed in sql2005 - my bet is not!
regards,
Sandiyan.
"Anthony Thomas" wrote:
> ALTER TABLE ...
> ALTER COLUMN
> The stored procedure, view, and function dependencies should not matter;
> however, you probably will have to drop and recreate any PKC, UC, FKC, CC,
> and Defaults that may be created on this field.
> If you use the database designer tool, EM will usually script out a new
> table with all of the dependency drops and recreates, move all of the data,
> and drop and rename the tables for you.
> This is usually not the best way to do this, especially for very large
> tables, but you can "SAVE AS SCRIPT" instead of executing it. This is a
> good way to learn at least the details if not a poorer solution.
> Sincerely,
>
> Anthony Thomas|||Well, there is. As I stated before, if you use the Table Designer through
the EM, it will handle all of the scripting for you. It usually will just
do the creat, copy, drop, replace method, which can work, but it will take a
lot of resources to pull off on larger tables. The same could be done, just
do the same thing except save as script instead save. Keep the drop and
create dependencies, just replace the create, copy, and rename table pieces
with a single ALTER TABLE ... ALTER COLUMN statement. At leas this way, you
would have to parse the dependencies.
There is a caveat to this, however; the EM uses the sysdependencies to
script out all the drops and creates. If you have ever renamed an object
without dropping and recreating the dependencies, and have gotten that
little error message, this means the records in this system table have not
been updated to reflect the name change. So, the little wizard inside the
EM scripter will not catch everything...but your errors will.
Good luck.
Anthony Thomas
"Sandiyan" <sandiyan@.yahoo.co.uk> wrote in message
news:15EEA5C6-8281-41FB-8287-085E1193F84F@.microsoft.com...
Thanks Anthony...I was hoping that there would be an easier option than
going
through and sorting out dependencies and etc...
I hope this will be addressed in sql2005 - my bet is not!
regards,
Sandiyan.
"Anthony Thomas" wrote:
> ALTER TABLE ...
> ALTER COLUMN
> The stored procedure, view, and function dependencies should not matter;
> however, you probably will have to drop and recreate any PKC, UC, FKC, CC,
> and Defaults that may be created on this field.
> If you use the database designer tool, EM will usually script out a new
> table with all of the dependency drops and recreates, move all of the
data,
> and drop and rename the tables for you.
> This is usually not the best way to do this, especially for very large
> tables, but you can "SAVE AS SCRIPT" instead of executing it. This is a
> good way to learn at least the details if not a poorer solution.
> Sincerely,
>
> Anthony Thomas

change nchar to char

Can I change a double byte (nchar) to 2 single byte (char)?Win
You can lose date
CREATE TABLE #T
(
col NCHAR(2) NOT NULL
)
INSERT INTO #T VALUES (N'K?')
GO
SELECT * FROM #T
--K?
GO
ALTER TABLE #T ALTER COLUMN col CHAR(2)
GO
SELECT * FROM #T
--K?
"Win" <aaa@.aaa.com> wrote in message
news:uZPIZ8CYFHA.3320@.TK2MSFTNGP12.phx.gbl...
> Can I change a double byte (nchar) to 2 single byte (char)?
>
>
>|||Hi
nchar will explicitly convert to char see
http://msdn.microsoft.com/library/d...br />
2f3o.asp
If you want to separate each byte of an nchar into separate characters does
not make sense!
If you want to change the datatype for a column you can use alter table
statement, but (as in the recent conversation http://tinyurl.com/9bz6c) you
have to be careful with ANSI_PADDING and you may be better to create a
separate column, update it, and the drop the original column.
This may help!
SET ANSI_PADDING OFF
CREATE TABLE MyTable ( ncharcolumn nchar(10) NULL )
INSERT INTO MyTable ( ncharcolumn )
SELECT 'ABC '
UNION ALL SELECT 'DEF '
UNION ALL SELECT 'GHI'
SELECT ncharcolumn, DATALENGTH(ncharcolumn)
FROM MyTable
/*
ncharcolumn
-- --
ABC 20
DEF 20
GHI 20
*/
ALTER TABLE MyTable ADD charcolumn char(10) NULL
UPDATE MyTable
SET charcolumn = ncharcolumn
SELECT ncharcolumn, DATALENGTH(ncharcolumn), charcolumn,
DATALENGTH(charcolumn)
FROM MyTable
/*
ncharcolumn charcolumn
-- -- -- --
ABC 20 ABC 3
DEF 20 DEF 3
GHI 20 GHI 3
*/
ALTER TABLE MyTable ALTER COLUMN ncharcolumn char(10) NULL
SELECT ncharcolumn, DATALENGTH(ncharcolumn), charcolumn,
DATALENGTH(charcolumn)
FROM MyTable
/*
ncharcolumn charcolumn
-- -- -- --
ABC 10 ABC 3
DEF 10 DEF 3
GHI 10 GHI 3
*/
SET ANSI_PADDING ON
DROP TABLE MyTable
CREATE TABLE MyTable ( ncharcolumn nchar(10) NULL )
INSERT INTO MyTable ( ncharcolumn )
SELECT 'ABC '
UNION ALL SELECT 'DEF '
UNION ALL SELECT 'GHI'
SELECT ncharcolumn, DATALENGTH(ncharcolumn)
FROM MyTable
/*
ncharcolumn
-- --
ABC 20
DEF 20
GHI 20
*/
ALTER TABLE MyTable ADD charcolumn char(10) NULL
UPDATE MyTable
SET charcolumn = ncharcolumn
SELECT ncharcolumn, DATALENGTH(ncharcolumn), charcolumn,
DATALENGTH(charcolumn)
FROM MyTable
/*
ncharcolumn charcolumn
-- -- -- --
ABC 20 ABC 10
DEF 20 DEF 10
GHI 20 GHI 10
*/
ALTER TABLE MyTable ALTER COLUMN ncharcolumn char(10) NULL
SELECT ncharcolumn, DATALENGTH(ncharcolumn), charcolumn,
DATALENGTH(charcolumn)
FROM MyTable
/*
ncharcolumn charcolumn
-- -- -- --
ABC 10 ABC 10
DEF 10 DEF 10
GHI 10 GHI 10
*/
John
"Win" wrote:

> Can I change a double byte (nchar) to 2 single byte (char)?
>
>
>
>|||Can I convert 1 double byte character to 2 signle byte characters.
"Uri Dimant" <urid@.iscar.co.il> wrote in message
news:ecvfkHDYFHA.2740@.TK2MSFTNGP14.phx.gbl...
> Win
> You can lose date
> CREATE TABLE #T
> (
> col NCHAR(2) NOT NULL
> )
> INSERT INTO #T VALUES (N'K?')
> GO
> SELECT * FROM #T
> --K?
> GO
> ALTER TABLE #T ALTER COLUMN col CHAR(2)
> GO
> SELECT * FROM #T
> --K?
>
>
> "Win" <aaa@.aaa.com> wrote in message
> news:uZPIZ8CYFHA.3320@.TK2MSFTNGP12.phx.gbl...
>|||Hi
Yes, but as Uri says there may be data loss or if you convert the two
bytes to ascii values there are not meaningful This may help explain:
DECLARE @.nstring NCHAR(1)
DECLARE @.charmask CHAR(2)
DECLARE @.binarymask BINARY(2)
SET @.nstring = NCHAR(260)
SELECT UNICODE(@.nstring),
NCHAR(UNICODE(@.nstring)),
CAST(@.nstring AS CHAR(1)),
ASCII(CAST(@.nstring AS CHAR(1)))
SELECT @.charmask = CAST(@.nstring as char(2)), @.binarymask =
CAST(@.nstring as binary(2))
SELECT @.charmask, ASCII(SUBSTRING(@.charmask, 1, 1)),
ASCII(SUBSTRING(@.charmask, 2, 1)),
@.binarymask, ASCII(SUBSTRING(@.binarymask, 1, 1)),
ASCII(SUBSTRING(@.binarymask, 2, 1))
John|||Hi John,
Actually I am using powerbuilder to make reports.
When I input chinese word (double byte) to a field, it will change it to 2
single byte (using powerbuilder).
But the datawindow can read the "2 single byte" data and print the chinese
word.
However, when I use web programs (ASP) and (nvarchar) to store the chinese
word, the report cannot read the double byte character.
It just shows ?.
Should I change the 1 double byte data to 2 single byte data?
How can I print the report in chinese word and using nvarchar to store data?
Win
"John Bell" <jbellnewsposts@.hotmail.com> wrote in message
news:1116937596.821455.153100@.g49g2000cwa.googlegroups.com...
> Hi
> Yes, but as Uri says there may be data loss or if you convert the two
> bytes to ascii values there are not meaningful This may help explain:
> DECLARE @.nstring NCHAR(1)
> DECLARE @.charmask CHAR(2)
> DECLARE @.binarymask BINARY(2)
> SET @.nstring = NCHAR(260)
> SELECT UNICODE(@.nstring),
> NCHAR(UNICODE(@.nstring)),
> CAST(@.nstring AS CHAR(1)),
> ASCII(CAST(@.nstring AS CHAR(1)))
> SELECT @.charmask = CAST(@.nstring as char(2)), @.binarymask =
> CAST(@.nstring as binary(2))
> SELECT @.charmask, ASCII(SUBSTRING(@.charmask, 1, 1)),
> ASCII(SUBSTRING(@.charmask, 2, 1)),
> @.binarymask, ASCII(SUBSTRING(@.binarymask, 1, 1)),
> ASCII(SUBSTRING(@.binarymask, 2, 1))
> John
>|||Hi
I don't know what powerbuilder is doing under the covers to make sense of
this. If your database is currently nchar then how do you know Powerbuilder
is using 2 single byte characters?
When your asp page displays a '?' this usually means your browser can not
interpret the character to display it. You may need to set the codepage as i
n
http://msdn.microsoft.com/library/d...ge
n.asp
This page and the links may also be worth reading:
http://support.microsoft.com/defaul...kb;en-us;303612
HTH
John
"Win" wrote:

> Hi John,
> Actually I am using powerbuilder to make reports.
> When I input chinese word (double byte) to a field, it will change it to 2
> single byte (using powerbuilder).
> But the datawindow can read the "2 single byte" data and print the chinese
> word.
> However, when I use web programs (ASP) and (nvarchar) to store the chinese
> word, the report cannot read the double byte character.
> It just shows ?.
> Should I change the 1 double byte data to 2 single byte data?
> How can I print the report in chinese word and using nvarchar to store dat
a?
> Win
> "John Bell" <jbellnewsposts@.hotmail.com> wrote in message
> news:1116937596.821455.153100@.g49g2000cwa.googlegroups.com...
>
>