Code page translations are not supported for the text data type. From: 1252 To: 950.

Code page translations are not supported for the text data type. From:
1252 To: 950.

I would like to know what this message means. I also installed the
language packs in advanced settings, Everything is set to English. My
windows XP computer is XP English. For some reason I cant get an update
to go thru using ADO. like Recordset.Update

Although other routines using .update work

Any ideas?Is it possible that If I installed MSDE when I had set under advanced
settings the nonunicode programs to Chinese that this would happen? I
have also noticed I can get around this by using the N' like select *
from some where something = N'something'

Anyway, how does one normally get around this issue, would an uninstall
of MSDE and then reinstall while XP is set to English fix this issue?|||That worked, uninstaled MSDE and reinstalled while XP was set to
english.
But I think the only setting change I made was under
control panel
regional settings
advanced language for nonunicode programs to Chinese(Taiwan).|||Hi

The collation was probably not explicitly set for the installation see
http://msdn.microsoft.com/library/d...istsql_84xl.asp
http://msdn.microsoft.com/library/d..._ca-co_2e95.asp

John

<sdowney717@.msn.com> wrote in message
news:1110744591.148218.180470@.z14g2000cwz.googlegr oups.com...
> That worked, uninstaled MSDE and reinstalled while XP was set to
> english.
> But I think the only setting change I made was under
> control panel
> regional settings
> advanced language for nonunicode programs to Chinese(Taiwan).|||Yes, it gives no options on the install, it must just use whatever is
set for the language. That does answer another question I was wondering
about, involving default collations. Is there an updated install for
MSDE, I only have the one off my Office XP CDROM. from 2000|||Hi

The latest release is downloadable from
http://www.microsoft.com/downloads/...&displaylang=en
this includes SP3a although you can apply SP3a to your existing system using
the appropriate download from
http://www.microsoft.com/sql/downloads/2000/sp3.asp

John

<sdowney717@.msn.com> wrote in message
news:1110749126.795817.193210@.f14g2000cwb.googlegr oups.com...
> Yes, it gives no options on the install, it must just use whatever is
> set for the language. That does answer another question I was wondering
> about, involving default collations. Is there an updated install for
> MSDE, I only have the one off my Office XP CDROM. from 2000|||sdowney717@.msn.com (sdowney717@.msn.com) writes:
> Is it possible that If I installed MSDE when I had set under advanced
> settings the nonunicode programs to Chinese that this would happen? I
> have also noticed I can get around this by using the N' like select *
> from some where something = N'something'

The N' means that the literal is nvarchar and thus Unicode, and thus not
subject to conversion between different 8-bit character sets.

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

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techin.../2000/books.asp

Code Page

I read text files in ASP on server side, then try to enter data into a
database in SQL Server. The files are in ibm852 (1250) coding - at least
that's the code page with which they are shown properly when putting the
lines read on the output.
However, when I enter them into the SQL Server (currently simply by setting
a string to an "INSERT INTO T1(6, 'hello')"-like statement and then execute
it through the connection such as oConn.Execute sSQL), the special
characters (Hungarian) are all changed to meaningless characters, such as
'hell:' for 'helló' etc.
The texty columns are of type varchar(n). I also tried nvarchar, but nothing
has changed.
So, how can I set the appropriate code page in SQL Server or transform the
strings so that the special characters don't get messed up when entered?Agoston,
Try changing the column type to nvarchar(n) and executing this query:
INSERT INTO T1(6, N'helló')
Perhaps you simply forgot to type the N required to signify a Unicode
string.
Steve Kass
Drew University
Agoston Bejo wrote:
>I read text files in ASP on server side, then try to enter data into a
>database in SQL Server. The files are in ibm852 (1250) coding - at least
>that's the code page with which they are shown properly when putting the
>lines read on the output.
>However, when I enter them into the SQL Server (currently simply by setting
>a string to an "INSERT INTO T1(6, 'hello')"-like statement and then execute
>it through the connection such as oConn.Execute sSQL), the special
>characters (Hungarian) are all changed to meaningless characters, such as
>'hell:' for 'helló' etc.
>The texty columns are of type varchar(n). I also tried nvarchar, but nothing
>has changed.
>So, how can I set the appropriate code page in SQL Server or transform the
>strings so that the special characters don't get messed up when entered?
>
>|||"Steve Kass" <skass@.drew.edu> wrote in message
news:%23xM75ETpEHA.1712@.tk2msftngp13.phx.gbl...
> Agoston,
> Try changing the column type to nvarchar(n) and executing this query:
> INSERT INTO T1(6, N'helló')
> Perhaps you simply forgot to type the N required to signify a Unicode
> string.
It doesn't change a thing. The same messy characters are in the db. Any
other ideas?
> Steve Kass
> Drew University
> Agoston Bejo wrote:
> >I read text files in ASP on server side, then try to enter data into a
> >database in SQL Server. The files are in ibm852 (1250) coding - at least
> >that's the code page with which they are shown properly when putting the
> >lines read on the output.
> >
> >However, when I enter them into the SQL Server (currently simply by
setting
> >a string to an "INSERT INTO T1(6, 'hello')"-like statement and then
execute
> >it through the connection such as oConn.Execute sSQL), the special
> >characters (Hungarian) are all changed to meaningless characters, such as
> >'hell:' for 'helló' etc.
> >The texty columns are of type varchar(n). I also tried nvarchar, but
nothing
> >has changed.
> >
> >So, how can I set the appropriate code page in SQL Server or transform
the
> >strings so that the special characters don't get messed up when entered?
> >
> >
> >
> >|||I don't do ASP programming, but is the string "INSERT INTO T1 ..." a
Unicode string? If not, it will not preserve the accented characters.
There ought to be some way to specify that it be Unicode, similar to the
way you do in SQL Server with the N prefix. If that fails to produce
the right result, I'm not sure what could be happening, since Unicode
strings shouldn't be affected by code page settings, but I'd probably
try specifying the 1250 code page somewhere on the ASP page - maybe the
ASP programmers have a better idea.
SK
Agoston Bejo wrote:
>"Steve Kass" <skass@.drew.edu> wrote in message
>news:%23xM75ETpEHA.1712@.tk2msftngp13.phx.gbl...
>
>>Agoston,
>> Try changing the column type to nvarchar(n) and executing this query:
>>INSERT INTO T1(6, N'helló')
>>Perhaps you simply forgot to type the N required to signify a Unicode
>>string.
>>
>
>It doesn't change a thing. The same messy characters are in the db. Any
>other ideas?
>
>
>>Steve Kass
>>Drew University
>>Agoston Bejo wrote:
>>
>>I read text files in ASP on server side, then try to enter data into a
>>database in SQL Server. The files are in ibm852 (1250) coding - at least
>>that's the code page with which they are shown properly when putting the
>>lines read on the output.
>>However, when I enter them into the SQL Server (currently simply by
>>
>setting
>
>>a string to an "INSERT INTO T1(6, 'hello')"-like statement and then
>>
>execute
>
>>it through the connection such as oConn.Execute sSQL), the special
>>characters (Hungarian) are all changed to meaningless characters, such as
>>'hell:' for 'helló' etc.
>>The texty columns are of type varchar(n). I also tried nvarchar, but
>>
>nothing
>
>>has changed.
>>So, how can I set the appropriate code page in SQL Server or transform
>>
>the
>
>>strings so that the special characters don't get messed up when entered?
>>
>>
>>
>
>|||Steve Kass wrote:
> I don't do ASP programming, but is the string "INSERT INTO T1 ..." a
> Unicode string? If not, it will not preserve the accented characters.
> There ought to be some way to specify that it be Unicode, similar to
> the way you do in SQL Server with the N prefix. If that fails to
> produce the right result, I'm not sure what could be happening, since
> Unicode
> strings shouldn't be affected by code page settings, but I'd probably
> try specifying the 1250 code page somewhere on the ASP page - maybe
> the ASP programmers have a better idea.
>
Good thought, but vbscript is unicode by default.
--
Microsoft MVP - ASP/ASP.NET
Please reply to the newsgroup. This email account is my spam trap so I
don't check it very often. If you must reply off-line, then remove the
"NO SPAM"

Code Page

I read text files in ASP on server side, then try to enter data into a
database in SQL Server. The files are in ibm852 (1250) coding - at least
that's the code page with which they are shown properly when putting the
lines read on the output.
However, when I enter them into the SQL Server (currently simply by setting
a string to an "INSERT INTO T1(6, 'hello')"-like statement and then execute
it through the connection such as oConn.Execute sSQL), the special
characters (Hungarian) are all changed to meaningless characters, such as
'hell:' for 'hell' etc.
The texty columns are of type varchar(n). I also tried nvarchar, but nothing
has changed.
So, how can I set the appropriate code page in SQL Server or transform the
strings so that the special characters don't get messed up when entered?
Agoston,
Try changing the column type to nvarchar(n) and executing this query:
INSERT INTO T1(6, N'hell')
Perhaps you simply forgot to type the N required to signify a Unicode
string.
Steve Kass
Drew University
Agoston Bejo wrote:

>I read text files in ASP on server side, then try to enter data into a
>database in SQL Server. The files are in ibm852 (1250) coding - at least
>that's the code page with which they are shown properly when putting the
>lines read on the output.
>However, when I enter them into the SQL Server (currently simply by setting
>a string to an "INSERT INTO T1(6, 'hello')"-like statement and then execute
>it through the connection such as oConn.Execute sSQL), the special
>characters (Hungarian) are all changed to meaningless characters, such as
>'hell:' for 'hell' etc.
>The texty columns are of type varchar(n). I also tried nvarchar, but nothing
>has changed.
>So, how can I set the appropriate code page in SQL Server or transform the
>strings so that the special characters don't get messed up when entered?
>
>
|||"Steve Kass" <skass@.drew.edu> wrote in message
news:%23xM75ETpEHA.1712@.tk2msftngp13.phx.gbl...
> Agoston,
> Try changing the column type to nvarchar(n) and executing this query:
> INSERT INTO T1(6, N'hell')
> Perhaps you simply forgot to type the N required to signify a Unicode
> string.
It doesn't change a thing. The same messy characters are in the db. Any
other ideas?
[vbcol=seagreen]
> Steve Kass
> Drew University
> Agoston Bejo wrote:
setting[vbcol=seagreen]
execute[vbcol=seagreen]
nothing[vbcol=seagreen]
the[vbcol=seagreen]
|||I don't do ASP programming, but is the string "INSERT INTO T1 ..." a
Unicode string? If not, it will not preserve the accented characters.
There ought to be some way to specify that it be Unicode, similar to the
way you do in SQL Server with the N prefix. If that fails to produce
the right result, I'm not sure what could be happening, since Unicode
strings shouldn't be affected by code page settings, but I'd probably
try specifying the 1250 code page somewhere on the ASP page - maybe the
ASP programmers have a better idea.
SK
Agoston Bejo wrote:

>"Steve Kass" <skass@.drew.edu> wrote in message
>news:%23xM75ETpEHA.1712@.tk2msftngp13.phx.gbl...
>
>
>It doesn't change a thing. The same messy characters are in the db. Any
>other ideas?
>
>
>setting
>
>execute
>
>nothing
>
>the
>
>
>
|||Steve Kass wrote:
> I don't do ASP programming, but is the string "INSERT INTO T1 ..." a
> Unicode string? If not, it will not preserve the accented characters.
> There ought to be some way to specify that it be Unicode, similar to
> the way you do in SQL Server with the N prefix. If that fails to
> produce the right result, I'm not sure what could be happening, since
> Unicode
> strings shouldn't be affected by code page settings, but I'd probably
> try specifying the 1250 code page somewhere on the ASP page - maybe
> the ASP programmers have a better idea.
>
Good thought, but vbscript is unicode by default.
Microsoft MVP - ASP/ASP.NET
Please reply to the newsgroup. This email account is my spam trap so I
don't check it very often. If you must reply off-line, then remove the
"NO SPAM"

COBOL program output "text" file for SQL Server to read?

Hello
When a COBOL program outputs a "text" file how can SQL Server read that text
file?winlin,
You can import it a number of ways. Read about BCP or BULK INSERT and its
format files. I am assuming that you will need to give some instruction via
the format file about how to parse the "text" file.
Or you may insert it into a staging table with a format something like:
CREATE TABLE CobolStaging
(LineOfCobolText NVARCHAR(1000))
Further, I am assuming that every line is in the same format, so that it can
be viewed as a row in a table. But if that is not the case, then the
reading in is more complex since it would probably be row order dependent
how to interpret the data. (E.g. header rows and detail rows. In that
case, use a table like:
CREATE TABLE CobolStaging
(LineNum INT IDENTITY(1,1)
LineOfCobolText NVARCHAR(1000))
You will need a format file to teach it to skip over the LineNum column when
importing.
After you have read and experimented with BCP you will probably have some
new questions.
RLF
"winlin" <winlin@.verizon.com> wrote in message
news:40E16360-C774-43A6-B4A9-B1B7B5FC4F2B@.microsoft.com...
> Hello
> When a COBOL program outputs a "text" file how can SQL Server read that
> text
> file?

cmdsql - Create a text file without Informational Messages

Hello all

I have a sql file that I want execute by using the cmdsql command line. But when I create a text file I receive two Informational Messages:

1."Changed database context to 'DataBaseName'."

2.(2 row(s) affected)

How can I ignore these messages in my text file? there is a parametter or something elese to configure to avoir these Informational Messages?

Sorry is not cmdsql is Sqlcmd :)

Clustering SQL

This is a multi-part message in MIME format.
--=_NextPart_000_0013_01C3F965.B5C9CBE0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hi everyone,
I have a Design Question about clustering SQL. I know clustering is = an expensive solution but I was given a project to provide high = availablity for Sharepoint Portal Server 2003. The environment = involves over 1400 users and I was given two HP BL20p servers to work = with. The project will need to be finished and in production in two = month and their SAN solution will not have iSCSI available after 3 = months. I have researched and can't seem to come up with a reliable = solution to cluster two servers with SQL, plus my intent is to also = cluster SPS2003 as well since the design for easy growth, the SQLs will = stay the same. It would probably be easy to add two web servers after = the budget allows for such addition. I would appreciate any comments in = this matter.
-- Regards,
David V. Dellanno - MCSE, MCP+I, MCP
MSDEMO Consultants
Williams Place
2564 Bridgewood Lane
Snellville, Georgia 30078 USA
(770) 736-8794 (Office)
msdemo.net
--=_NextPart_000_0013_01C3F965.B5C9CBE0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
&
Hi everyone,

I have a Design Question about = clustering SQL. I know clustering is an expensive solution but I was = given a project to provide high availablity for Sharepoint Portal Server 2003. The environment involves over 1400 users and I was = given two HP BL20p servers to work with. The project will need to be = finished and in production in two month and their SAN solution will not have iSCSI = available after 3 months. I have researched and can't seem to = come up with a reliable solution to cluster two servers with SQL, plus my intent = is to also cluster SPS2003 as well since the design for easy growth, the SQLs = will stay the same. It would probably be easy to add two web servers = after the budget allows for such addition. I would appreciate any comments = in this matter.
-- Regards,

David V. Dellanno - MCSE, MCP+I, MCPMSDEMO = ConsultantsWilliams Place2564 Bridgewood LaneSnellville, Georgia 30078 USA(770) = 736-8794 (Office)msdemo.net
--=_NextPart_000_0013_01C3F965.B5C9CBE0--You will need shared disks hardware to cluster two sql
servers. At this point you should consider clustering your
webservers, and then request for more hardware to cluster
database servers. Most 24/4 sites are first designed this
way.
Clustering in sql server is more about hardware than
software. You will need to buy additional storage hardware
with simultaneous disk access capability. Meanwhile make
sure you use RAID 1, 10 or 5 and implement a good sql
backup strategy. SQL Server 2000 on win2k is a very stable
configuration, even more stable then those overrated
unix/oracle configurations. You can also have another
server with sql server installed on it, and export key
tables for your sites to this server once, twice or more
often in a day. In case of unplanned downtime of sql
sever, you can quickly point your apps to the spare sql
server.
Cluster in any database system will take lots of time in
planning, and lots of money too. Usually database servers
are most expensive server in any IT infrastructure anyway.
>--Original Message--
>Hi everyone,
> I have a Design Question about clustering SQL. I know
clustering is an expensive solution but I was given a
project to provide high availablity for Sharepoint Portal
Server 2003. The environment involves over 1400 users
and I was given two HP BL20p servers to work with. The
project will need to be finished and in production in two
month and their SAN solution will not have iSCSI
available after 3 months. I have researched and can't
seem to come up with a reliable solution to cluster two
servers with SQL, plus my intent is to also cluster
SPS2003 as well since the design for easy growth, the SQLs
will stay the same. It would probably be easy to add two
web servers after the budget allows for such addition. I
would appreciate any comments in this matter.
>--
>Regards,
>David V. Dellanno - MCSE, MCP+I, MCP
>MSDEMO Consultants
>Williams Place
>2564 Bridgewood Lane
>Snellville, Georgia 30078 USA
>(770) 736-8794 (Office)
>msdemo.net
>

Clustering and SA Role

Sorry for the re-post.
In a clustered SQL Server 2005 environment you must assign SQL Server, Agent
and Full Text Search to domain groups. These groups then appear in the Sys
Admin fixed role. With that, anyone who can add members to groups in the
domain can also become SQL Server SAs. How can this be prevented? I don't
think anyone with ability/access to add members to groups (even domain
admins) should be allowed to automatically make him/herself a SQL SA be
inheritance.
Hi
It comes down to processes within your organization and also how you secure
your AD.
You can grant someone to only manage objects in a certain tree, so not
giving them rights to the SQL Server accounts that should be in their own
tree would be the correct way of doing it.
Do you trust the same person not to give themselves Enterprise Admin rights
in the domain?
Regards
Mike Epprecht, Microsoft SQL Server MVP
Zurich, Switzerland
IM: mike@.epprecht.net
MVP Program: http://www.microsoft.com/mvp
Blog: http://www.msmvps.com/epprecht/
"Jay" <msnews.microsoft.com> wrote in message
news:uf6d0$L6FHA.1148@.tk2msftngp13.phx.gbl...
> Sorry for the re-post.
> In a clustered SQL Server 2005 environment you must assign SQL Server,
> Agent
> and Full Text Search to domain groups. These groups then appear in the
> Sys
> Admin fixed role. With that, anyone who can add members to groups in the
> domain can also become SQL Server SAs. How can this be prevented? I
> don't think anyone with ability/access to add members to groups (even
> domain admins) should be allowed to automatically make him/herself a SQL
> SA be inheritance.
>
>
|||I guess the issue is that in SQL2000 one could remove local admin group from
the sysadmin role, thus preventing the server admin from easily and
legitimately getting into SQL Server. So why can't we have that in SQL2005?
In practice, of course, I bet in many places one would find that the
accounts of the DBAs are placed into a group and that group is granted
access to SQL Server. So if a server admin really wants, he can add himself
to that group, thus gaining full access to SQL Server. So in the end, it
does come down to trust. Trust for sure simplifies management in many
scenarios. Without trust, one would have to go to excessive length to get
things down or prevent things from happening. And in most places, I'd say if
you don't have trust, you have a bigger problem than keeping the server
admin out of SQL Server.
Nevertheless it's nice to, at least, have the option available to keep the
server admin out, if necessary. Unfortunately, the cluster domain groups
required in SQl2005 are not thoroughly documented in current SQL2005 BOL. I
underdstand that the December BOL refresh will have more materials on these
groups. I hope it can shed some light on the issue being discussed here.
Linchi
"Mike Epprecht (SQL MVP)" <mike@.epprecht.net> wrote in message
news:Ok%23Y3jN6FHA.2816@.tk2msftngp13.phx.gbl...
> Hi
> It comes down to processes within your organization and also how you
> secure your AD.
> You can grant someone to only manage objects in a certain tree, so not
> giving them rights to the SQL Server accounts that should be in their own
> tree would be the correct way of doing it.
> Do you trust the same person not to give themselves Enterprise Admin
> rights in the domain?
> Regards
> --
> Mike Epprecht, Microsoft SQL Server MVP
> Zurich, Switzerland
> IM: mike@.epprecht.net
> MVP Program: http://www.microsoft.com/mvp
> Blog: http://www.msmvps.com/epprecht/
> "Jay" <msnews.microsoft.com> wrote in message
> news:uf6d0$L6FHA.1148@.tk2msftngp13.phx.gbl...
>
|||You do have to remember too that Domain Admins, Enterprise Admins, User
Admins, and OU Admins have the ability to reset the passwords to user
accounts in the AD as well as add users to Global and Resource (Domain
Local?) Groups. So, again, it comes down to trust . . . and audits.
It helps if your Domain/Enterprise Administrators, Server Administrators,
Security Administrators, AD Administrators, Exchange Administrators, Web
Server Administrators, Application Server Administrators, Message Queue
Administrators, and SQL Server Administrators, etc., etc., etc., all be
managed by separate groups by managers of equal rank, all with elevated
privileges, all auditing the activities of the other groups: peer review,
within and throughout the organization to provide checks and balances to the
Change Control Process.
Sincerely,
Anthony Thomas

"Linchi Shea" <linchi_shea@.NOSPAMml.om> wrote in message
news:u3MQcxN6FHA.2888@.tk2msftngp13.phx.gbl...
> I guess the issue is that in SQL2000 one could remove local admin group
from
> the sysadmin role, thus preventing the server admin from easily and
> legitimately getting into SQL Server. So why can't we have that in
SQL2005?
> In practice, of course, I bet in many places one would find that the
> accounts of the DBAs are placed into a group and that group is granted
> access to SQL Server. So if a server admin really wants, he can add
himself
> to that group, thus gaining full access to SQL Server. So in the end, it
> does come down to trust. Trust for sure simplifies management in many
> scenarios. Without trust, one would have to go to excessive length to get
> things down or prevent things from happening. And in most places, I'd say
if
> you don't have trust, you have a bigger problem than keeping the server
> admin out of SQL Server.
> Nevertheless it's nice to, at least, have the option available to keep the
> server admin out, if necessary. Unfortunately, the cluster domain groups
> required in SQl2005 are not thoroughly documented in current SQL2005 BOL.
I
> underdstand that the December BOL refresh will have more materials on
these[vbcol=seagreen]
> groups. I hope it can shed some light on the issue being discussed here.
> Linchi
> "Mike Epprecht (SQL MVP)" <mike@.epprecht.net> wrote in message
> news:Ok%23Y3jN6FHA.2816@.tk2msftngp13.phx.gbl...
own[vbcol=seagreen]
the[vbcol=seagreen]
SQL
>