_wcsupr () with german characters

Hi,
I have a string which contains some german characters e.g 'Men'. I
am converting it to upper case using wcsupr (). But is not converted to .
There are other characters too. I can use the _wsetlocale () function before
using _wcsupr (). I cannot use the current machines locale setting. The
strings have to be converted to upper case based on the locale of the target
machine which is a SQL Server. What's the most efficient way of converting
the string to upper case considering the language specific characters. I
tried using the _wsetlocale (LC_CTYPE , L".OCP"); which uses the OEM code
page. This seems to be working. What's the difference in OEM code page and
language specific code page?
Thanks in advance
AjeyHi
The easiest way may be to use the UPPER function when retrieving/saving the
data
SELECT UPPER( 'Menü')
MENü
John
"Ajey" wrote:

> Hi,
> I have a string which contains some german characters e.g 'Menü'.
I
> am converting it to upper case using wcsupr (). But ü is not converted to
ü.
> There are other characters too. I can use the _wsetlocale () function befo
re
> using _wcsupr (). I cannot use the current machines locale setting. The
> strings have to be converted to upper case based on the locale of the targ
et
> machine which is a SQL Server. What's the most efficient way of converting
> the string to upper case considering the language specific characters. I
> tried using the _wsetlocale (LC_CTYPE , L".OCP"); which uses the OEM code
> page. This seems to be working. What's the difference in OEM code page and
> language specific code page?
> Thanks in advance
> Ajey
>
>|||There are many such string. I cannot use sql query for each to just make it
a upper case. Is there a way i can find out exact local the SQL Server is
using or is there any documentation of which API UPPER function insql uses.
"John Bell" <JohnBell@.discussions.microsoft.com> wrote in message
news:E55039D7-F207-4131-AF23-4E603E29A38D@.microsoft.com...
> Hi
> The easiest way may be to use the UPPER function when retrieving/saving
the
> data
> SELECT UPPER( 'Men')
> --
> MEN
> John
> "Ajey" wrote:
>
I
to .
before
target
converting
code
and|||If i get the code page from the SQL Server as 1252 where as the language on
server is german but the machine where i am running the API has English,
will _wsetlocale(LC_CTYPE, L".1252") work fine. Are code page number specifc
to languages or they cover range of languages. (I want to make sure that
code page 1252 is not different for german and different for english)
"Ajey" <ajey5@.hotmail.com> wrote in message
news:OJYC$WQNFHA.688@.TK2MSFTNGP10.phx.gbl...
> There are many such string. I cannot use sql query for each to just make
it
> a upper case. Is there a way i can find out exact local the SQL Server is
> using or is there any documentation of which API UPPER function insql
uses.
> "John Bell" <JohnBell@.discussions.microsoft.com> wrote in message
> news:E55039D7-F207-4131-AF23-4E603E29A38D@.microsoft.com...
> the
'Men'.
> I
> to .
> before
The
> target
> converting
I
> code
> and
>|||"Ajey" <ajey5@.hotmail.com> schrieb im Newsbeitrag =
news:OkTRS$ONFHA.1528@.TK2MSFTNGP09.phx.gbl...
> Hi,
> I have a string which contains some german characters e.g =
'Men=FC'. I
> am converting it to upper case using wcsupr (). But =FC is not =
converted to =DC.
> There are other characters too. I can use the _wsetlocale () function =
before
> using _wcsupr (). I cannot use the current machines locale setting. =
The
> strings have to be converted to upper case based on the locale of the =
target
> machine which is a SQL Server. What's the most efficient way of =
converting
> the string to upper case considering the language specific characters. =
I
> tried using the _wsetlocale (LC_CTYPE , L".OCP"); which uses the OEM =
code
> page. This seems to be working. What's the difference in OEM code page =
and
> language specific code page?
wcsupr should be independent of the current locale. However, there seems =
to be a bug in the implementation of wcsupr. It first checks the current =
locale and if the "C" locale is used, it simply translates 'a'-'z' to =
upper case but ignores all other letters. If you select any locale =
different form the "C" locale, the string will be translated correctly. =
So, your call to setlocale does fix that bug, but using an OEM codepage =
might introduce other problems. Using the current ANSI codepage (".ACP") =
probably is a better choice.
If you are very cautions, you should implement your own to-upper =
function that selects a reasonable codepage and later restores the =
original one. Something like
void ToUpper(wchar_t* s)
{
char const* loc =3D setlocale(LC_CTYPE, ".ACP");
wcsupr(s);
setlocale(LC_CTYPE, loc);
}
As long as you feed unicode strings (wchar_t) to your SQL server, you =
shouldn't have to worry about locales. You only have to select some =
locale to fix that stupid bug of wcsupr.
HTH
Heinz|||Is the setting applicable to current thread only or to entire program (all
threads)?
"Heinz Ozwirk" <hozwirk.SPAM@.arcor.de> wrote in message
news:424a7cd4$0$11477$9b4e6d93@.newsread2
.arcor-online.net...
"Ajey" <ajey5@.hotmail.com> schrieb im Newsbeitrag
news:OkTRS$ONFHA.1528@.TK2MSFTNGP09.phx.gbl...
> Hi,
> I have a string which contains some german characters e.g 'Men'. I
> am converting it to upper case using wcsupr (). But is not converted to
.
> There are other characters too. I can use the _wsetlocale () function
before
> using _wcsupr (). I cannot use the current machines locale setting. The
> strings have to be converted to upper case based on the locale of the
target
> machine which is a SQL Server. What's the most efficient way of converting
> the string to upper case considering the language specific characters. I
> tried using the _wsetlocale (LC_CTYPE , L".OCP"); which uses the OEM code
> page. This seems to be working. What's the difference in OEM code page and
> language specific code page?
wcsupr should be independent of the current locale. However, there seems to
be a bug in the implementation of wcsupr. It first checks the current locale
and if the "C" locale is used, it simply translates 'a'-'z' to upper case
but ignores all other letters. If you select any locale different form the
"C" locale, the string will be translated correctly. So, your call to
setlocale does fix that bug, but using an OEM codepage might introduce other
problems. Using the current ANSI codepage (".ACP") probably is a better
choice.
If you are very cautions, you should implement your own to-upper function
that selects a reasonable codepage and later restores the original one.
Something like
void ToUpper(wchar_t* s)
{
char const* loc = setlocale(LC_CTYPE, ".ACP");
wcsupr(s);
setlocale(LC_CTYPE, loc);
}
As long as you feed unicode strings (wchar_t) to your SQL server, you
shouldn't have to worry about locales. You only have to select some locale
to fix that stupid bug of wcsupr.
HTH
Heinz|||Hi
If you always require uppercase then you may think about changing the
data and adding contraints to make sure it is always in uppercase.
Changing you queries may actually be less work than changing the code
especially if you are using stored procedures.
John
Ajey wrote:
> There are many such string. I cannot use sql query for each to just
make it
> a upper case. Is there a way i can find out exact local the SQL
Server is
> using or is there any documentation of which API UPPER function insql
uses.
> "John Bell" <JohnBell@.discussions.microsoft.com> wrote in message
> news:E55039D7-F207-4131-AF23-4E603E29A38D@.microsoft.com...
retrieving/saving
> the
'Men=FC'.
> I
converted
> to =DC.
function
> before
setting. The
the
> target
> converting
characters. I
OEM
> code
page
> and|||"Ajey" <ajey5@.hotmail.com> schrieb im Newsbeitrag =
news:e6a6QnRNFHA.3328@.TK2MSFTNGP14.phx.gbl...
> Is the setting applicable to current thread only or to entire program =
(all
> threads)?
The code looks like it should be thread specific. Give it a try...
HTH
Heinz

_wcsupr () with german characters

Hi,
I have a string which contains some german characters e.g 'Menü'. I
am converting it to upper case using wcsupr (). But ü is not converted to Ü.
There are other characters too. I can use the _wsetlocale () function before
using _wcsupr (). I cannot use the current machines locale setting. The
strings have to be converted to upper case based on the locale of the target
machine which is a SQL Server. What's the most efficient way of converting
the string to upper case considering the language specific characters. I
tried using the _wsetlocale (LC_CTYPE , L".OCP"); which uses the OEM code
page. This seems to be working. What's the difference in OEM code page and
language specific code page?
Thanks in advance
AjeyHi
The easiest way may be to use the UPPER function when retrieving/saving the
data
SELECT UPPER( 'Menü')
--
MENÃ?
John
"Ajey" wrote:
> Hi,
> I have a string which contains some german characters e.g 'Menü'. I
> am converting it to upper case using wcsupr (). But ü is not converted to �.
> There are other characters too. I can use the _wsetlocale () function before
> using _wcsupr (). I cannot use the current machines locale setting. The
> strings have to be converted to upper case based on the locale of the target
> machine which is a SQL Server. What's the most efficient way of converting
> the string to upper case considering the language specific characters. I
> tried using the _wsetlocale (LC_CTYPE , L".OCP"); which uses the OEM code
> page. This seems to be working. What's the difference in OEM code page and
> language specific code page?
> Thanks in advance
> Ajey
>
>|||There are many such string. I cannot use sql query for each to just make it
a upper case. Is there a way i can find out exact local the SQL Server is
using or is there any documentation of which API UPPER function insql uses.
"John Bell" <JohnBell@.discussions.microsoft.com> wrote in message
news:E55039D7-F207-4131-AF23-4E603E29A38D@.microsoft.com...
> Hi
> The easiest way may be to use the UPPER function when retrieving/saving
the
> data
> SELECT UPPER( 'Menü')
> --
> MENÜ
> John
> "Ajey" wrote:
> > Hi,
> > I have a string which contains some german characters e.g 'Menü'.
I
> > am converting it to upper case using wcsupr (). But ü is not converted
to Ü.
> > There are other characters too. I can use the _wsetlocale () function
before
> > using _wcsupr (). I cannot use the current machines locale setting. The
> > strings have to be converted to upper case based on the locale of the
target
> > machine which is a SQL Server. What's the most efficient way of
converting
> > the string to upper case considering the language specific characters. I
> > tried using the _wsetlocale (LC_CTYPE , L".OCP"); which uses the OEM
code
> > page. This seems to be working. What's the difference in OEM code page
and
> > language specific code page?
> >
> > Thanks in advance
> >
> > Ajey
> >
> >
> >
> >|||If i get the code page from the SQL Server as 1252 where as the language on
server is german but the machine where i am running the API has English,
will _wsetlocale(LC_CTYPE, L".1252") work fine. Are code page number specifc
to languages or they cover range of languages. (I want to make sure that
code page 1252 is not different for german and different for english)
"Ajey" <ajey5@.hotmail.com> wrote in message
news:OJYC$WQNFHA.688@.TK2MSFTNGP10.phx.gbl...
> There are many such string. I cannot use sql query for each to just make
it
> a upper case. Is there a way i can find out exact local the SQL Server is
> using or is there any documentation of which API UPPER function insql
uses.
> "John Bell" <JohnBell@.discussions.microsoft.com> wrote in message
> news:E55039D7-F207-4131-AF23-4E603E29A38D@.microsoft.com...
> > Hi
> >
> > The easiest way may be to use the UPPER function when retrieving/saving
> the
> > data
> >
> > SELECT UPPER( 'Menü')
> >
> > --
> > MENÜ
> >
> > John
> >
> > "Ajey" wrote:
> >
> > > Hi,
> > > I have a string which contains some german characters e.g
'Menü'.
> I
> > > am converting it to upper case using wcsupr (). But ü is not converted
> to Ü.
> > > There are other characters too. I can use the _wsetlocale () function
> before
> > > using _wcsupr (). I cannot use the current machines locale setting.
The
> > > strings have to be converted to upper case based on the locale of the
> target
> > > machine which is a SQL Server. What's the most efficient way of
> converting
> > > the string to upper case considering the language specific characters.
I
> > > tried using the _wsetlocale (LC_CTYPE , L".OCP"); which uses the OEM
> code
> > > page. This seems to be working. What's the difference in OEM code page
> and
> > > language specific code page?
> > >
> > > Thanks in advance
> > >
> > > Ajey
> > >
> > >
> > >
> > >
>|||"Ajey" <ajey5@.hotmail.com> schrieb im Newsbeitrag =news:OkTRS$ONFHA.1528@.TK2MSFTNGP09.phx.gbl...
> Hi,
> I have a string which contains some german characters e.g ='Men=FC'. I
> am converting it to upper case using wcsupr (). But =FC is not =converted to =DC.
> There are other characters too. I can use the _wsetlocale () function =before
> using _wcsupr (). I cannot use the current machines locale setting. =The
> strings have to be converted to upper case based on the locale of the =target
> machine which is a SQL Server. What's the most efficient way of =converting
> the string to upper case considering the language specific characters. =I
> tried using the _wsetlocale (LC_CTYPE , L".OCP"); which uses the OEM =code
> page. This seems to be working. What's the difference in OEM code page =and
> language specific code page?
wcsupr should be independent of the current locale. However, there seems =to be a bug in the implementation of wcsupr. It first checks the current =locale and if the "C" locale is used, it simply translates 'a'-'z' to =upper case but ignores all other letters. If you select any locale =different form the "C" locale, the string will be translated correctly. =So, your call to setlocale does fix that bug, but using an OEM codepage =might introduce other problems. Using the current ANSI codepage (".ACP") =probably is a better choice.
If you are very cautions, you should implement your own to-upper =function that selects a reasonable codepage and later restores the =original one. Something like
void ToUpper(wchar_t* s)
{
char const* loc =3D setlocale(LC_CTYPE, ".ACP");
wcsupr(s);
setlocale(LC_CTYPE, loc);
}
As long as you feed unicode strings (wchar_t) to your SQL server, you =shouldn't have to worry about locales. You only have to select some =locale to fix that stupid bug of wcsupr.
HTH
Heinz|||Is the setting applicable to current thread only or to entire program (all
threads)?
"Heinz Ozwirk" <hozwirk.SPAM@.arcor.de> wrote in message
news:424a7cd4$0$11477$9b4e6d93@.newsread2.arcor-online.net...
"Ajey" <ajey5@.hotmail.com> schrieb im Newsbeitrag
news:OkTRS$ONFHA.1528@.TK2MSFTNGP09.phx.gbl...
> Hi,
> I have a string which contains some german characters e.g 'Menü'. I
> am converting it to upper case using wcsupr (). But ü is not converted to
Ü.
> There are other characters too. I can use the _wsetlocale () function
before
> using _wcsupr (). I cannot use the current machines locale setting. The
> strings have to be converted to upper case based on the locale of the
target
> machine which is a SQL Server. What's the most efficient way of converting
> the string to upper case considering the language specific characters. I
> tried using the _wsetlocale (LC_CTYPE , L".OCP"); which uses the OEM code
> page. This seems to be working. What's the difference in OEM code page and
> language specific code page?
wcsupr should be independent of the current locale. However, there seems to
be a bug in the implementation of wcsupr. It first checks the current locale
and if the "C" locale is used, it simply translates 'a'-'z' to upper case
but ignores all other letters. If you select any locale different form the
"C" locale, the string will be translated correctly. So, your call to
setlocale does fix that bug, but using an OEM codepage might introduce other
problems. Using the current ANSI codepage (".ACP") probably is a better
choice.
If you are very cautions, you should implement your own to-upper function
that selects a reasonable codepage and later restores the original one.
Something like
void ToUpper(wchar_t* s)
{
char const* loc = setlocale(LC_CTYPE, ".ACP");
wcsupr(s);
setlocale(LC_CTYPE, loc);
}
As long as you feed unicode strings (wchar_t) to your SQL server, you
shouldn't have to worry about locales. You only have to select some locale
to fix that stupid bug of wcsupr.
HTH
Heinz|||Hi
If you always require uppercase then you may think about changing the
data and adding contraints to make sure it is always in uppercase.
Changing you queries may actually be less work than changing the code
especially if you are using stored procedures.
John
Ajey wrote:
> There are many such string. I cannot use sql query for each to just
make it
> a upper case. Is there a way i can find out exact local the SQL
Server is
> using or is there any documentation of which API UPPER function insql
uses.
> "John Bell" <JohnBell@.discussions.microsoft.com> wrote in message
> news:E55039D7-F207-4131-AF23-4E603E29A38D@.microsoft.com...
> > Hi
> >
> > The easiest way may be to use the UPPER function when
retrieving/saving
> the
> > data
> >
> > SELECT UPPER( 'Men=FC')
> >
> > --
> > MEN=DC
> >
> > John
> >
> > "Ajey" wrote:
> >
> > > Hi,
> > > I have a string which contains some german characters e.g
'Men=FC'.
> I
> > > am converting it to upper case using wcsupr (). But =FC is not
converted
> to =DC.
> > > There are other characters too. I can use the _wsetlocale ()
function
> before
> > > using _wcsupr (). I cannot use the current machines locale
setting. The
> > > strings have to be converted to upper case based on the locale of
the
> target
> > > machine which is a SQL Server. What's the most efficient way of
> converting
> > > the string to upper case considering the language specific
characters. I
> > > tried using the _wsetlocale (LC_CTYPE , L".OCP"); which uses the
OEM
> code
> > > page. This seems to be working. What's the difference in OEM code
page
> and
> > > language specific code page?
> > >
> > > Thanks in advance
> > >
> > > Ajey
> > >
> > >
> > >
> > >|||"Ajey" <ajey5@.hotmail.com> schrieb im Newsbeitrag =news:e6a6QnRNFHA.3328@.TK2MSFTNGP14.phx.gbl...
> Is the setting applicable to current thread only or to entire program =(all
> threads)?
The code looks like it should be thread specific. Give it a try...
HTH
Heinz

_wcsupr () with german characters

Hi,
I have a string which contains some german characters e.g 'Men'. I
am converting it to upper case using wcsupr (). But is not converted to .
There are other characters too. I can use the _wsetlocale () function before
using _wcsupr (). I cannot use the current machines locale setting. The
strings have to be converted to upper case based on the locale of the target
machine which is a SQL Server. What's the most efficient way of converting
the string to upper case considering the language specific characters. I
tried using the _wsetlocale (LC_CTYPE , L".OCP"); which uses the OEM code
page. This seems to be working. What's the difference in OEM code page and
language specific code page?
Thanks in advance
AjeyHi
The easiest way may be to use the UPPER function when retrieving/saving the
data
SELECT UPPER( 'Menü')
MENü
John
"Ajey" wrote:

> Hi,
> I have a string which contains some german characters e.g 'Menü'.
I
> am converting it to upper case using wcsupr (). But ü is not converted to
ü.
> There are other characters too. I can use the _wsetlocale () function befo
re
> using _wcsupr (). I cannot use the current machines locale setting. The
> strings have to be converted to upper case based on the locale of the targ
et
> machine which is a SQL Server. What's the most efficient way of converting
> the string to upper case considering the language specific characters. I
> tried using the _wsetlocale (LC_CTYPE , L".OCP"); which uses the OEM code
> page. This seems to be working. What's the difference in OEM code page and
> language specific code page?
> Thanks in advance
> Ajey
>
>|||There are many such string. I cannot use sql query for each to just make it
a upper case. Is there a way i can find out exact local the SQL Server is
using or is there any documentation of which API UPPER function insql uses.
"John Bell" <JohnBell@.discussions.microsoft.com> wrote in message
news:E55039D7-F207-4131-AF23-4E603E29A38D@.microsoft.com...
> Hi
> The easiest way may be to use the UPPER function when retrieving/saving
the[vbcol=seagreen]
> data
> SELECT UPPER( 'Men')
> --
> MEN
> John
> "Ajey" wrote:
>
I[vbcol=seagreen]
to .[vbcol=seagreen]
before[vbcol=seagreen]
target[vbcol=seagreen]
converting[vbcol=seagreen]
code[vbcol=seagreen]
and[vbcol=seagreen]|||If i get the code page from the SQL Server as 1252 where as the language on
server is german but the machine where i am running the API has English,
will _wsetlocale(LC_CTYPE, L".1252") work fine. Are code page number specifc
to languages or they cover range of languages. (I want to make sure that
code page 1252 is not different for german and different for english)
"Ajey" <ajey5@.hotmail.com> wrote in message
news:OJYC$WQNFHA.688@.TK2MSFTNGP10.phx.gbl...
> There are many such string. I cannot use sql query for each to just make
it
> a upper case. Is there a way i can find out exact local the SQL Server is
> using or is there any documentation of which API UPPER function insql
uses.
> "John Bell" <JohnBell@.discussions.microsoft.com> wrote in message
> news:E55039D7-F207-4131-AF23-4E603E29A38D@.microsoft.com...
> the
'Men'.[vbcol=seagreen]
> I
> to .
> before
The[vbcol=seagreen]
> target
> converting
I[vbcol=seagreen]
> code
> and
>|||"Ajey" <ajey5@.hotmail.com> schrieb im Newsbeitrag =
news:OkTRS$ONFHA.1528@.TK2MSFTNGP09.phx.gbl...
> Hi,
> I have a string which contains some german characters e.g =
'Men=FC'. I
> am converting it to upper case using wcsupr (). But =FC is not =
converted to =DC.
> There are other characters too. I can use the _wsetlocale () function =
before
> using _wcsupr (). I cannot use the current machines locale setting. =
The
> strings have to be converted to upper case based on the locale of the =
target
> machine which is a SQL Server. What's the most efficient way of =
converting
> the string to upper case considering the language specific characters. =
I
> tried using the _wsetlocale (LC_CTYPE , L".OCP"); which uses the OEM =
code
> page. This seems to be working. What's the difference in OEM code page =
and
> language specific code page?
wcsupr should be independent of the current locale. However, there seems =
to be a bug in the implementation of wcsupr. It first checks the current =
locale and if the "C" locale is used, it simply translates 'a'-'z' to =
upper case but ignores all other letters. If you select any locale =
different form the "C" locale, the string will be translated correctly. =
So, your call to setlocale does fix that bug, but using an OEM codepage =
might introduce other problems. Using the current ANSI codepage (".ACP") =
probably is a better choice.
If you are very cautions, you should implement your own to-upper =
function that selects a reasonable codepage and later restores the =
original one. Something like
void ToUpper(wchar_t* s)
{
char const* loc =3D setlocale(LC_CTYPE, ".ACP");
wcsupr(s);
setlocale(LC_CTYPE, loc);
}
As long as you feed unicode strings (wchar_t) to your SQL server, you =
shouldn't have to worry about locales. You only have to select some =
locale to fix that stupid bug of wcsupr.
HTH
Heinz|||Is the setting applicable to current thread only or to entire program (all
threads)?
"Heinz Ozwirk" <hozwirk.SPAM@.arcor.de> wrote in message
news:424a7cd4$0$11477$9b4e6d93@.newsread2
.arcor-online.net...
"Ajey" <ajey5@.hotmail.com> schrieb im Newsbeitrag
news:OkTRS$ONFHA.1528@.TK2MSFTNGP09.phx.gbl...
> Hi,
> I have a string which contains some german characters e.g 'Men'. I
> am converting it to upper case using wcsupr (). But is not converted to
.
> There are other characters too. I can use the _wsetlocale () function
before
> using _wcsupr (). I cannot use the current machines locale setting. The
> strings have to be converted to upper case based on the locale of the
target
> machine which is a SQL Server. What's the most efficient way of converting
> the string to upper case considering the language specific characters. I
> tried using the _wsetlocale (LC_CTYPE , L".OCP"); which uses the OEM code
> page. This seems to be working. What's the difference in OEM code page and
> language specific code page?
wcsupr should be independent of the current locale. However, there seems to
be a bug in the implementation of wcsupr. It first checks the current locale
and if the "C" locale is used, it simply translates 'a'-'z' to upper case
but ignores all other letters. If you select any locale different form the
"C" locale, the string will be translated correctly. So, your call to
setlocale does fix that bug, but using an OEM codepage might introduce other
problems. Using the current ANSI codepage (".ACP") probably is a better
choice.
If you are very cautions, you should implement your own to-upper function
that selects a reasonable codepage and later restores the original one.
Something like
void ToUpper(wchar_t* s)
{
char const* loc = setlocale(LC_CTYPE, ".ACP");
wcsupr(s);
setlocale(LC_CTYPE, loc);
}
As long as you feed unicode strings (wchar_t) to your SQL server, you
shouldn't have to worry about locales. You only have to select some locale
to fix that stupid bug of wcsupr.
HTH
Heinz|||Hi
If you always require uppercase then you may think about changing the
data and adding contraints to make sure it is always in uppercase.
Changing you queries may actually be less work than changing the code
especially if you are using stored procedures.
John
Ajey wrote:
> There are many such string. I cannot use sql query for each to just
make it
> a upper case. Is there a way i can find out exact local the SQL
Server is
> using or is there any documentation of which API UPPER function insql
uses.[vbcol=seagreen]
> "John Bell" <JohnBell@.discussions.microsoft.com> wrote in message
> news:E55039D7-F207-4131-AF23-4E603E29A38D@.microsoft.com...
retrieving/saving[vbcol=seagreen]
> the
'Men=FC'.[vbcol=seagreen]
> I
converted[vbcol=seagreen]
> to =DC.
function[vbcol=seagreen]
> before
setting. The[vbcol=seagreen]
the[vbcol=seagreen]
> target
> converting
characters. I[vbcol=seagreen]
OEM[vbcol=seagreen]
> code
page[vbcol=seagreen]
> and|||"Ajey" <ajey5@.hotmail.com> schrieb im Newsbeitrag =
news:e6a6QnRNFHA.3328@.TK2MSFTNGP14.phx.gbl...
> Is the setting applicable to current thread only or to entire program =
(all
> threads)?
The code looks like it should be thread specific. Give it a try...
HTH
Heinz

_wcsupr () with german characters

Hi,
I have a string which contains some german characters e.g 'Men'. I
am converting it to upper case using wcsupr (). But is not converted to .
There are other characters too. I can use the _wsetlocale () function before
using _wcsupr (). I cannot use the current machines locale setting. The
strings have to be converted to upper case based on the locale of the target
machine which is a SQL Server. What's the most efficient way of converting
the string to upper case considering the language specific characters. I
tried using the _wsetlocale (LC_CTYPE , L".OCP"); which uses the OEM code
page. This seems to be working. What's the difference in OEM code page and
language specific code page?
Thanks in advance
Ajey
Hi
The easiest way may be to use the UPPER function when retrieving/saving the
data
SELECT UPPER( 'Menü')
MENü
John
"Ajey" wrote:

> Hi,
> I have a string which contains some german characters e.g 'Menü'. I
> am converting it to upper case using wcsupr (). But ü is not converted to ü.
> There are other characters too. I can use the _wsetlocale () function before
> using _wcsupr (). I cannot use the current machines locale setting. The
> strings have to be converted to upper case based on the locale of the target
> machine which is a SQL Server. What's the most efficient way of converting
> the string to upper case considering the language specific characters. I
> tried using the _wsetlocale (LC_CTYPE , L".OCP"); which uses the OEM code
> page. This seems to be working. What's the difference in OEM code page and
> language specific code page?
> Thanks in advance
> Ajey
>
>
|||There are many such string. I cannot use sql query for each to just make it
a upper case. Is there a way i can find out exact local the SQL Server is
using or is there any documentation of which API UPPER function insql uses.
"John Bell" <JohnBell@.discussions.microsoft.com> wrote in message
news:E55039D7-F207-4131-AF23-4E603E29A38D@.microsoft.com...
> Hi
> The easiest way may be to use the UPPER function when retrieving/saving
the[vbcol=seagreen]
> data
> SELECT UPPER( 'Men')
> --
> MEN
> John
> "Ajey" wrote:
I[vbcol=seagreen]
to .[vbcol=seagreen]
before[vbcol=seagreen]
target[vbcol=seagreen]
converting[vbcol=seagreen]
code[vbcol=seagreen]
and[vbcol=seagreen]
|||If i get the code page from the SQL Server as 1252 where as the language on
server is german but the machine where i am running the API has English,
will _wsetlocale(LC_CTYPE, L".1252") work fine. Are code page number specifc
to languages or they cover range of languages. (I want to make sure that
code page 1252 is not different for german and different for english)
"Ajey" <ajey5@.hotmail.com> wrote in message
news:OJYC$WQNFHA.688@.TK2MSFTNGP10.phx.gbl...
> There are many such string. I cannot use sql query for each to just make
it
> a upper case. Is there a way i can find out exact local the SQL Server is
> using or is there any documentation of which API UPPER function insql
uses.[vbcol=seagreen]
> "John Bell" <JohnBell@.discussions.microsoft.com> wrote in message
> news:E55039D7-F207-4131-AF23-4E603E29A38D@.microsoft.com...
> the
'Men'.[vbcol=seagreen]
> I
> to .
> before
The[vbcol=seagreen]
> target
> converting
I
> code
> and
>
|||"Ajey" <ajey5@.hotmail.com> schrieb im Newsbeitrag =
news:OkTRS$ONFHA.1528@.TK2MSFTNGP09.phx.gbl...
> Hi,
> I have a string which contains some german characters e.g =
'Men=FC'. I
> am converting it to upper case using wcsupr (). But =FC is not =
converted to =DC.
> There are other characters too. I can use the _wsetlocale () function =
before
> using _wcsupr (). I cannot use the current machines locale setting. =
The
> strings have to be converted to upper case based on the locale of the =
target
> machine which is a SQL Server. What's the most efficient way of =
converting
> the string to upper case considering the language specific characters. =
I
> tried using the _wsetlocale (LC_CTYPE , L".OCP"); which uses the OEM =
code
> page. This seems to be working. What's the difference in OEM code page =
and
> language specific code page?
wcsupr should be independent of the current locale. However, there seems =
to be a bug in the implementation of wcsupr. It first checks the current =
locale and if the "C" locale is used, it simply translates 'a'-'z' to =
upper case but ignores all other letters. If you select any locale =
different form the "C" locale, the string will be translated correctly. =
So, your call to setlocale does fix that bug, but using an OEM codepage =
might introduce other problems. Using the current ANSI codepage (".ACP") =
probably is a better choice.
If you are very cautions, you should implement your own to-upper =
function that selects a reasonable codepage and later restores the =
original one. Something like
void ToUpper(wchar_t* s)
{
char const* loc =3D setlocale(LC_CTYPE, ".ACP");
wcsupr(s);
setlocale(LC_CTYPE, loc);
}
As long as you feed unicode strings (wchar_t) to your SQL server, you =
shouldn't have to worry about locales. You only have to select some =
locale to fix that stupid bug of wcsupr.
HTH
Heinz
|||Is the setting applicable to current thread only or to entire program (all
threads)?
"Heinz Ozwirk" <hozwirk.SPAM@.arcor.de> wrote in message
news:424a7cd4$0$11477$9b4e6d93@.newsread2.arcor-online.net...
"Ajey" <ajey5@.hotmail.com> schrieb im Newsbeitrag
news:OkTRS$ONFHA.1528@.TK2MSFTNGP09.phx.gbl...
> Hi,
> I have a string which contains some german characters e.g 'Men'. I
> am converting it to upper case using wcsupr (). But is not converted to
.
> There are other characters too. I can use the _wsetlocale () function
before
> using _wcsupr (). I cannot use the current machines locale setting. The
> strings have to be converted to upper case based on the locale of the
target
> machine which is a SQL Server. What's the most efficient way of converting
> the string to upper case considering the language specific characters. I
> tried using the _wsetlocale (LC_CTYPE , L".OCP"); which uses the OEM code
> page. This seems to be working. What's the difference in OEM code page and
> language specific code page?
wcsupr should be independent of the current locale. However, there seems to
be a bug in the implementation of wcsupr. It first checks the current locale
and if the "C" locale is used, it simply translates 'a'-'z' to upper case
but ignores all other letters. If you select any locale different form the
"C" locale, the string will be translated correctly. So, your call to
setlocale does fix that bug, but using an OEM codepage might introduce other
problems. Using the current ANSI codepage (".ACP") probably is a better
choice.
If you are very cautions, you should implement your own to-upper function
that selects a reasonable codepage and later restores the original one.
Something like
void ToUpper(wchar_t* s)
{
char const* loc = setlocale(LC_CTYPE, ".ACP");
wcsupr(s);
setlocale(LC_CTYPE, loc);
}
As long as you feed unicode strings (wchar_t) to your SQL server, you
shouldn't have to worry about locales. You only have to select some locale
to fix that stupid bug of wcsupr.
HTH
Heinz
|||Hi
If you always require uppercase then you may think about changing the
data and adding contraints to make sure it is always in uppercase.
Changing you queries may actually be less work than changing the code
especially if you are using stored procedures.
John
Ajey wrote:
> There are many such string. I cannot use sql query for each to just
make it
> a upper case. Is there a way i can find out exact local the SQL
Server is
> using or is there any documentation of which API UPPER function insql
uses.[vbcol=seagreen]
> "John Bell" <JohnBell@.discussions.microsoft.com> wrote in message
> news:E55039D7-F207-4131-AF23-4E603E29A38D@.microsoft.com...
retrieving/saving[vbcol=seagreen]
> the
'Men=FC'.[vbcol=seagreen]
> I
converted[vbcol=seagreen]
> to =DC.
function[vbcol=seagreen]
> before
setting. The[vbcol=seagreen]
the[vbcol=seagreen]
> target
> converting
characters. I[vbcol=seagreen]
OEM[vbcol=seagreen]
> code
page[vbcol=seagreen]
> and
|||"Ajey" <ajey5@.hotmail.com> schrieb im Newsbeitrag =
news:e6a6QnRNFHA.3328@.TK2MSFTNGP14.phx.gbl...
> Is the setting applicable to current thread only or to entire program =
(all
> threads)?
The code looks like it should be thread specific. Give it a try...
HTH
Heinz
sql

[OT] User-Defined string Functions Transact-SQL

Ladies and Gentlemen,

I am pleased to offer, free of charge, the following string functions Transact-SQL:

AT(): Returns the beginning numeric position of the nth occurrence of a character expression within another character expression, counting from the leftmost character.
RAT(): Returns the numeric position of the last (rightmost) occurrence of a character string within another character string.
OCCURS(): Returns the number of times a character expression occurs within another character expression (including overlaps).
OCCURS2(): Returns the number of times a character expression occurs within another character expression (excluding overlaps).
PADL(): Returns a string from an expression, padded with spaces or characters to a specified length on the left side.
PADR(): Returns a string from an expression, padded with spaces or characters to a specified length on the right side.
PADC(): Returns a string from an expression, padded with spaces or characters to a specified length on the both sides.
CHRTRAN(): Replaces each character in a character expression that matches a character in a second character expression with the corresponding character in a third character expression.
STRTRAN(): Searches a character expression for occurrences of a second character expression, and then replaces each occurrence with a third character expression. Unlike a built-in function Replace, STRTRAN has three additional parameters.
STRFILTER(): Removes all characters from a string except those specified.
GETWORDCOUNT(): Counts the words in a string.
GETWORDNUM(): Returns a specified word from a string.
GETALLWORDS(): Inserts the words from a string into the table.
PROPER(): Returns from a character expression a string capitalized as appropriate for proper names.
RCHARINDEX(): Similar to the Transact-SQL function Charindex, with a Right search.
ARABTOROMAN(): Returns the character Roman numeral equivalent of a specified numeric expression (from 1 to 3999).
ROMANTOARAB(): Returns the number equivalent of a specified character Roman numeral expression (from I to MMMCMXCIX).

AT, PADL, PADR, CHRTRAN, PROPER: Similar to the Oracle functions PL/SQL INSTR, LPAD, RPAD, TRANSLATE, INITCAP.

Plus, there are CHM files in English, French, Spanish, German and Russian.

More than 6000 people have already downloaded my functions. I hope you will find them useful as well.

For more information about string UDFs Transact-SQL please visit the
http://www.universalthread.com/wconnect/wc.dll?LevelExtreme~2,54,33,27115

Please, download the file
http://www.universalthread.com/wconnect/wc.dll?LevelExtreme~2,2,27115

With the best regards.DON'T LOOK AT THE LIGHT!

If you give me a cheesburger today, I'll gladly pay you next Thursday|||Didn't this guy post before under a different name, and get his code ripped apart?|||Same name, different forum, same ineffecient code

http://www.sqlteam.com/forums/topic.asp?TOPIC_ID=54333

[OT] User-Defined string Functions MS SQL Server 2005 Transact-SQL SQLCLR .Net

User-Defined string Functions MS SQL Server 2005 Transact-SQL SQLCLR (VB. Net, C#.Net, C++. Net)

Ladies and Gentlemen,

I am pleased to offer, free of charge, the following string functions MS SQL Server 2005 Transact-SQL SQLCLR (VB. Net, C#.Net, C++. Net):

AT(): Returns the beginning numeric position of the nth occurrence of a character expression within another character expression, counting from the leftmost character.
RAT(): Returns the numeric position of the last (rightmost) occurrence of a character string within another character string.
OCCURS(): Returns the number of times a character expression occurs within another character expression (including overlaps).
OCCURS2(): Returns the number of times a character expression occurs within another character expression (excluding overlaps).
PADL(): Returns a string from an expression, padded with spaces or characters to a specified length on the left side.
PADR(): Returns a string from an expression, padded with spaces or characters to a specified length on the right side.
PADC(): Returns a string from an expression, padded with spaces or characters to a specified length on the both sides.
CHRTRAN(): Replaces each character in a character expression that matches a character in a second character expression with the corresponding character in a third character expression.
STRTRAN(): Searches a character expression for occurrences of a second character expression, and then replaces each occurrence with a third character expression. Unlike a built-in function Replace, STRTRAN has three additional parameters.
STRFILTER(): Removes all characters from a string except those specified.
GETWORDCOUNT(): Counts the words in a string.
GETWORDNUM(): Returns a specified word from a string.
GETALLWORDS(): Inserts the words from a string into the table.
PROPER(): Returns from a character expression a string capitalized as appropriate for proper names.
RCHARINDEX(): Similar to the Transact-SQL function Charindex, with a Right search.
ARABTOROMAN(): Returns the character Roman numeral equivalent of a specified numeric expression (from 1 to 3999).
ROMANTOARAB(): Returns the number equivalent of a specified character Roman numeral expression (from I to MMMCMXCIX).

AT, PADL, PADR, CHRTRAN, PROPER: Similar to the Oracle functions PL/SQL INSTR, LPAD, RPAD, TRANSLATE, INITCAP.

Plus, there are CHM files in English, French, Spanish, German and Russian.

Plus, there are versions for MS SQL SERVER, SYBASE ASA, DB2, Oracle.

More than 8000 people have already downloaded my functions. I hope you will find them useful as well.

For more information about string UDFs MS SQL Server 2005 Transact-SQL SQLCLR (VB. Net, C#.Net, C++. Net) please visit the
http://www.universalthread.com/wconnect/wc.dll?LevelExtreme~2,54,33,29527

Please, download the file
http://www.universalthread.com/wconnect/wc.dll?LevelExtreme~2,2,29527

With the best regards.Igor! Long time no see! Its good to see that you've returned to re-enable the laugh track here at DBForums!

It will be interesting to see the reception of this incarnation of your library in a new (CLR) environment! Someday I may download this incarnation myself.

-PatP

[Microsoft][ODBC SQL Server Driver]Timeout expired"

Could anyone help?
"Connection failed:
SQLState: '01S00'
SQL Server Error: 0
[Microsoft][ODBC SQL Server Driver]Invalid connection string attribute
Connection failed:
SQLState: 'S1T00'
SQL server Error: 0
[Microsoft][ODBC SQL Server Driver]Timeout expired"
Thanks in advance
Please post your connection string.
Hope this helps.
Dan Guzman
SQL Server MVP
"Alexis Robles" <AlexisRobles@.discussions.microsoft.com> wrote in message
news:9F8B08B1-26CF-4601-8457-C7E810149812@.microsoft.com...
> Could anyone help?
> "Connection failed:
> SQLState: '01S00'
> SQL Server Error: 0
> [Microsoft][ODBC SQL Server Driver]Invalid connection string attribute
> Connection failed:
> SQLState: 'S1T00'
> SQL server Error: 0
> [Microsoft][ODBC SQL Server Driver]Timeout expired"
> Thanks in advance
|||Here is the connection string:
OPEN=ODBC;DATABASE=AFM_CALLISTO;DSN=AFM_CALLISTO;
"Dan Guzman" wrote:

> Please post your connection string.
> --
> Hope this helps.
> Dan Guzman
> SQL Server MVP
> "Alexis Robles" <AlexisRobles@.discussions.microsoft.com> wrote in message
> news:9F8B08B1-26CF-4601-8457-C7E810149812@.microsoft.com...
>
>
|||The 'invalid connection string attribute' informational error is due to the
extraneous 'OPEN=ODBC' specification. Try removing it:
DATABASE=AFM_CALLISTO;DSN=AFM_CALLISTO
I don't know what API you are using but the default command timeout is 30
seconds. In the case of ADO, you can specify a longer interval with the
CommandTimeout command object property. Specify 0 for unlimitted. You
might also consider query/index tuning to speed up the query and also check
for blocking.
Hope this helps.
Dan Guzman
SQL Server MVP
"Alexis Robles" <AlexisRobles@.discussions.microsoft.com> wrote in message
news:4A6C5752-A705-40CC-81B7-8FAAF54F2AE8@.microsoft.com...[vbcol=seagreen]
> Here is the connection string:
> OPEN=ODBC;DATABASE=AFM_CALLISTO;DSN=AFM_CALLISTO;
> "Dan Guzman" wrote:
|||It hs been always working with that string. Anyway, I'm going to try to see
if it works.
Thanks
"Dan Guzman" wrote:

> The 'invalid connection string attribute' informational error is due to the
> extraneous 'OPEN=ODBC' specification. Try removing it:
> DATABASE=AFM_CALLISTO;DSN=AFM_CALLISTO
> I don't know what API you are using but the default command timeout is 30
> seconds. In the case of ADO, you can specify a longer interval with the
> CommandTimeout command object property. Specify 0 for unlimitted. You
> might also consider query/index tuning to speed up the query and also check
> for blocking.
> --
> Hope this helps.
> Dan Guzman
> SQL Server MVP
> "Alexis Robles" <AlexisRobles@.discussions.microsoft.com> wrote in message
> news:4A6C5752-A705-40CC-81B7-8FAAF54F2AE8@.microsoft.com...
>
>
|||It didn't connect when I remove 'OPEN=ODBC'
"Dan Guzman" wrote:

> The 'invalid connection string attribute' informational error is due to the
> extraneous 'OPEN=ODBC' specification. Try removing it:
> DATABASE=AFM_CALLISTO;DSN=AFM_CALLISTO
> I don't know what API you are using but the default command timeout is 30
> seconds. In the case of ADO, you can specify a longer interval with the
> CommandTimeout command object property. Specify 0 for unlimitted. You
> might also consider query/index tuning to speed up the query and also check
> for blocking.
> --
> Hope this helps.
> Dan Guzman
> SQL Server MVP
> "Alexis Robles" <AlexisRobles@.discussions.microsoft.com> wrote in message
> news:4A6C5752-A705-40CC-81B7-8FAAF54F2AE8@.microsoft.com...
>
>
|||Try changing the order of the parameters. Normally, the DSN will have a designated DATABASE parameter, although this can be overridden. But how could it be if it hasn't loaded from the DSN yet.
Try 'OPEN=ODBC;DSN=AFM_CALLISTO;DATABASE=AFM_CALLISTO'
Another possibility is that a recent MDAC release or patch has been applied to the client. This has a nasty habit of messing with ODBC. You might want to use the ODBC Administrator and recheck the DSN attributes. When you're done, use the TEST CONNECTION capability to validate the attributes.
Sincerely,
Anthony Thomas

"Alexis Robles" <AlexisRobles@.discussions.microsoft.com> wrote in message news:87584EDE-BCFE-401D-81DF-38A260BFD0D5@.microsoft.com...
It didn't connect when I remove 'OPEN=ODBC'
"Dan Guzman" wrote:

> The 'invalid connection string attribute' informational error is due to the
> extraneous 'OPEN=ODBC' specification. Try removing it:
>
> DATABASE=AFM_CALLISTO;DSN=AFM_CALLISTO
>
> I don't know what API you are using but the default command timeout is 30
> seconds. In the case of ADO, you can specify a longer interval with the
> CommandTimeout command object property. Specify 0 for unlimitted. You
> might also consider query/index tuning to speed up the query and also check
> for blocking.
>
> --
> Hope this helps.
>
> Dan Guzman
> SQL Server MVP
>
> "Alexis Robles" <AlexisRobles@.discussions.microsoft.com> wrote in message
> news:4A6C5752-A705-40CC-81B7-8FAAF54F2AE8@.microsoft.com...
>
>
>|||In my ADO test, ODBC ignored the ODBC attribute in the connection string,
returned an informational message and successfully connected. Without the
attribute, the connection was successful without the message. What API are
you using? Perhaps the ODBC attribute is required by a high-level API that
you are using. I'd expect the API to remove the attribute before passing it
to ODBC, though.
In any case, I suggest you follow the suggestions in my earlier response to
resolve the timeout problem.
Hope this helps.
Dan Guzman
SQL Server MVP
"Alexis Robles" <AlexisRobles@.discussions.microsoft.com> wrote in message
news:87584EDE-BCFE-401D-81DF-38A260BFD0D5@.microsoft.com...
> It didn't connect when I remove 'OPEN=ODBC'
>
|||Can I remove the MDAC?
"AnthonyThomas" wrote:

> Try changing the order of the parameters. Normally, the DSN will have a designated DATABASE parameter, although this can be overridden. But how could it be if it hasn't loaded from the DSN yet.
> Try 'OPEN=ODBC;DSN=AFM_CALLISTO;DATABASE=AFM_CALLISTO'
> Another possibility is that a recent MDAC release or patch has been applied to the client. This has a nasty habit of messing with ODBC. You might want to use the ODBC Administrator and recheck the DSN attributes. When you're done, use the TEST CONNEC
TION capability to validate the attributes.[vbcol=seagreen]
> Sincerely,
>
> Anthony Thomas
>
> --
> "Alexis Robles" <AlexisRobles@.discussions.microsoft.com> wrote in message news:87584EDE-BCFE-401D-81DF-38A260BFD0D5@.microsoft.com...
> It didn't connect when I remove 'OPEN=ODBC'
>
> "Dan Guzman" wrote:

[Microsoft][ODBC SQL Server Driver]Timeout expired"

Could anyone help?
"Connection failed:
SQLState: '01S00'
SQL Server Error: 0
[Microsoft][ODBC SQL Server Driver]Invalid connection string attribute
Connection failed:
SQLState: 'S1T00'
SQL server Error: 0
[Microsoft][ODBC SQL Server Driver]Timeout expired"
Thanks in advancePlease post your connection string.
--
Hope this helps.
Dan Guzman
SQL Server MVP
"Alexis Robles" <AlexisRobles@.discussions.microsoft.com> wrote in message
news:9F8B08B1-26CF-4601-8457-C7E810149812@.microsoft.com...
> Could anyone help?
> "Connection failed:
> SQLState: '01S00'
> SQL Server Error: 0
> [Microsoft][ODBC SQL Server Driver]Invalid connection string attribute
> Connection failed:
> SQLState: 'S1T00'
> SQL server Error: 0
> [Microsoft][ODBC SQL Server Driver]Timeout expired"
> Thanks in advance|||Here is the connection string:
OPEN=ODBC;DATABASE=AFM_CALLISTO;DSN=AFM_CALLISTO;
"Dan Guzman" wrote:
> Please post your connection string.
> --
> Hope this helps.
> Dan Guzman
> SQL Server MVP
> "Alexis Robles" <AlexisRobles@.discussions.microsoft.com> wrote in message
> news:9F8B08B1-26CF-4601-8457-C7E810149812@.microsoft.com...
> > Could anyone help?
> >
> > "Connection failed:
> > SQLState: '01S00'
> > SQL Server Error: 0
> > [Microsoft][ODBC SQL Server Driver]Invalid connection string attribute
> > Connection failed:
> > SQLState: 'S1T00'
> > SQL server Error: 0
> > [Microsoft][ODBC SQL Server Driver]Timeout expired"
> >
> > Thanks in advance
>
>|||The 'invalid connection string attribute' informational error is due to the
extraneous 'OPEN=ODBC' specification. Try removing it:
DATABASE=AFM_CALLISTO;DSN=AFM_CALLISTO
I don't know what API you are using but the default command timeout is 30
seconds. In the case of ADO, you can specify a longer interval with the
CommandTimeout command object property. Specify 0 for unlimitted. You
might also consider query/index tuning to speed up the query and also check
for blocking.
--
Hope this helps.
Dan Guzman
SQL Server MVP
"Alexis Robles" <AlexisRobles@.discussions.microsoft.com> wrote in message
news:4A6C5752-A705-40CC-81B7-8FAAF54F2AE8@.microsoft.com...
> Here is the connection string:
> OPEN=ODBC;DATABASE=AFM_CALLISTO;DSN=AFM_CALLISTO;
> "Dan Guzman" wrote:
>> Please post your connection string.
>> --
>> Hope this helps.
>> Dan Guzman
>> SQL Server MVP
>> "Alexis Robles" <AlexisRobles@.discussions.microsoft.com> wrote in message
>> news:9F8B08B1-26CF-4601-8457-C7E810149812@.microsoft.com...
>> > Could anyone help?
>> >
>> > "Connection failed:
>> > SQLState: '01S00'
>> > SQL Server Error: 0
>> > [Microsoft][ODBC SQL Server Driver]Invalid connection string attribute
>> > Connection failed:
>> > SQLState: 'S1T00'
>> > SQL server Error: 0
>> > [Microsoft][ODBC SQL Server Driver]Timeout expired"
>> >
>> > Thanks in advance
>>|||It hs been always working with that string. Anyway, I'm going to try to see
if it works.
Thanks
"Dan Guzman" wrote:
> The 'invalid connection string attribute' informational error is due to the
> extraneous 'OPEN=ODBC' specification. Try removing it:
> DATABASE=AFM_CALLISTO;DSN=AFM_CALLISTO
> I don't know what API you are using but the default command timeout is 30
> seconds. In the case of ADO, you can specify a longer interval with the
> CommandTimeout command object property. Specify 0 for unlimitted. You
> might also consider query/index tuning to speed up the query and also check
> for blocking.
> --
> Hope this helps.
> Dan Guzman
> SQL Server MVP
> "Alexis Robles" <AlexisRobles@.discussions.microsoft.com> wrote in message
> news:4A6C5752-A705-40CC-81B7-8FAAF54F2AE8@.microsoft.com...
> > Here is the connection string:
> >
> > OPEN=ODBC;DATABASE=AFM_CALLISTO;DSN=AFM_CALLISTO;
> >
> > "Dan Guzman" wrote:
> >
> >> Please post your connection string.
> >>
> >> --
> >> Hope this helps.
> >>
> >> Dan Guzman
> >> SQL Server MVP
> >>
> >> "Alexis Robles" <AlexisRobles@.discussions.microsoft.com> wrote in message
> >> news:9F8B08B1-26CF-4601-8457-C7E810149812@.microsoft.com...
> >> > Could anyone help?
> >> >
> >> > "Connection failed:
> >> > SQLState: '01S00'
> >> > SQL Server Error: 0
> >> > [Microsoft][ODBC SQL Server Driver]Invalid connection string attribute
> >> > Connection failed:
> >> > SQLState: 'S1T00'
> >> > SQL server Error: 0
> >> > [Microsoft][ODBC SQL Server Driver]Timeout expired"
> >> >
> >> > Thanks in advance
> >>
> >>
> >>
>
>|||It didn't connect when I remove 'OPEN=ODBC'
"Dan Guzman" wrote:
> The 'invalid connection string attribute' informational error is due to the
> extraneous 'OPEN=ODBC' specification. Try removing it:
> DATABASE=AFM_CALLISTO;DSN=AFM_CALLISTO
> I don't know what API you are using but the default command timeout is 30
> seconds. In the case of ADO, you can specify a longer interval with the
> CommandTimeout command object property. Specify 0 for unlimitted. You
> might also consider query/index tuning to speed up the query and also check
> for blocking.
> --
> Hope this helps.
> Dan Guzman
> SQL Server MVP
> "Alexis Robles" <AlexisRobles@.discussions.microsoft.com> wrote in message
> news:4A6C5752-A705-40CC-81B7-8FAAF54F2AE8@.microsoft.com...
> > Here is the connection string:
> >
> > OPEN=ODBC;DATABASE=AFM_CALLISTO;DSN=AFM_CALLISTO;
> >
> > "Dan Guzman" wrote:
> >
> >> Please post your connection string.
> >>
> >> --
> >> Hope this helps.
> >>
> >> Dan Guzman
> >> SQL Server MVP
> >>
> >> "Alexis Robles" <AlexisRobles@.discussions.microsoft.com> wrote in message
> >> news:9F8B08B1-26CF-4601-8457-C7E810149812@.microsoft.com...
> >> > Could anyone help?
> >> >
> >> > "Connection failed:
> >> > SQLState: '01S00'
> >> > SQL Server Error: 0
> >> > [Microsoft][ODBC SQL Server Driver]Invalid connection string attribute
> >> > Connection failed:
> >> > SQLState: 'S1T00'
> >> > SQL server Error: 0
> >> > [Microsoft][ODBC SQL Server Driver]Timeout expired"
> >> >
> >> > Thanks in advance
> >>
> >>
> >>
>
>|||In my ADO test, ODBC ignored the ODBC attribute in the connection string,
returned an informational message and successfully connected. Without the
attribute, the connection was successful without the message. What API are
you using? Perhaps the ODBC attribute is required by a high-level API that
you are using. I'd expect the API to remove the attribute before passing it
to ODBC, though.
In any case, I suggest you follow the suggestions in my earlier response to
resolve the timeout problem.
--
Hope this helps.
Dan Guzman
SQL Server MVP
"Alexis Robles" <AlexisRobles@.discussions.microsoft.com> wrote in message
news:87584EDE-BCFE-401D-81DF-38A260BFD0D5@.microsoft.com...
> It didn't connect when I remove 'OPEN=ODBC'
>|||Can I remove the MDAC?
"AnthonyThomas" wrote:
> Try changing the order of the parameters. Normally, the DSN will have a designated DATABASE parameter, although this can be overridden. But how could it be if it hasn't loaded from the DSN yet.
> Try 'OPEN=ODBC;DSN=AFM_CALLISTO;DATABASE=AFM_CALLISTO'
> Another possibility is that a recent MDAC release or patch has been applied to the client. This has a nasty habit of messing with ODBC. You might want to use the ODBC Administrator and recheck the DSN attributes. When you're done, use the TEST CONNECTION capability to validate the attributes.
> Sincerely,
>
> Anthony Thomas
>
> --
> "Alexis Robles" <AlexisRobles@.discussions.microsoft.com> wrote in message news:87584EDE-BCFE-401D-81DF-38A260BFD0D5@.microsoft.com...
> It didn't connect when I remove 'OPEN=ODBC'
>
> "Dan Guzman" wrote:
> > The 'invalid connection string attribute' informational error is due to the
> > extraneous 'OPEN=ODBC' specification. Try removing it:
> >
> > DATABASE=AFM_CALLISTO;DSN=AFM_CALLISTO
> >
> > I don't know what API you are using but the default command timeout is 30
> > seconds. In the case of ADO, you can specify a longer interval with the
> > CommandTimeout command object property. Specify 0 for unlimitted. You
> > might also consider query/index tuning to speed up the query and also check
> > for blocking.
> >
> > --
> > Hope this helps.
> >
> > Dan Guzman
> > SQL Server MVP
> >
> > "Alexis Robles" <AlexisRobles@.discussions.microsoft.com> wrote in message
> > news:4A6C5752-A705-40CC-81B7-8FAAF54F2AE8@.microsoft.com...
> > > Here is the connection string:
> > >
> > > OPEN=ODBC;DATABASE=AFM_CALLISTO;DSN=AFM_CALLISTO;
> > >
> > > "Dan Guzman" wrote:
> > >
> > >> Please post your connection string.
> > >>
> > >> --
> > >> Hope this helps.
> > >>
> > >> Dan Guzman
> > >> SQL Server MVP
> > >>
> > >> "Alexis Robles" <AlexisRobles@.discussions.microsoft.com> wrote in message
> > >> news:9F8B08B1-26CF-4601-8457-C7E810149812@.microsoft.com...
> > >> > Could anyone help?
> > >> >
> > >> > "Connection failed:
> > >> > SQLState: '01S00'
> > >> > SQL Server Error: 0
> > >> > [Microsoft][ODBC SQL Server Driver]Invalid connection string attribute
> > >> > Connection failed:
> > >> > SQLState: 'S1T00'
> > >> > SQL server Error: 0
> > >> > [Microsoft][ODBC SQL Server Driver]Timeout expired"
> > >> >
> > >> > Thanks in advance
> > >>
> > >>
> > >>
> >
> >
> >

[HELP!] How do you make the database path relative in the connection string?

Hi everyone,

I am working on a Hospital Information System project with a team of 6.Each one of us builds or modifies a part of the system and shares the project over a common repository. The problem here is that we use the absolute path of the database in our connection string. Although the directory structure of our project is the same for each member, since the main project folder itself is stored in different locations on each person's computer (for example, one may have it stored in c:\My Documents and the other in d:\ My Documents), we are forced to modify the connection string manually each time someone else from the team updates the repository with the database. How do we make the path of the database relative so that we don't have to modify the connection string manually each time after receiving an update from the repository?

Your help is greatly appreciated.

If you're referencing the path, then I wonder what database you are using. e.g. for MSSQL you would refer to a server and the database on that server, generally just '.' for a local server

Lot's of ways you could do this, e.g. I've just been playing with clickonce install and this is one I use;

connectionString="Data Source=.\SQLEXPRESS;AttachDbFilename=|DataDirectory|\dbRaptor_Data.mdf;Integrated Security=True;User Instance=True"

[ask] how to append string to the previous select statement bounded to gridview

i have a case :

i'm using a select statement with SqlCommand and save the results in the SQLDataAdapter

and using the data table I post the result to the gridview and show it there...

my question is what should I do to append string to the SQL Command??

I'm not sure if I understand what you're asking. Can you use something like this

SqlCommand.CommandText &=" appended text "

before executing the command?

|||

yes i need the command text to be appended with some text later

thanks anyway, i think it's better to try it first :)

@@server_name

Should it concern me that the code below returns Null? I simply was hoping
to get the name of the server as a string ...
select @.@.SERVERNAME
Thanks in advance.
Mark
Hi
Run sp_dropserver and then sp_addserver against the server.
Master DB does not have a valid value for the server. This can occur on
servers where Master DB was restored, or upgraded or the server name was
changed.
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/
"Mark" <Mark@.nowhere.com> wrote in message
news:eJZOBVWDFHA.3256@.tk2msftngp13.phx.gbl...
> Should it concern me that the code below returns Null? I simply was
hoping
> to get the name of the server as a string ...
> select @.@.SERVERNAME
> Thanks in advance.
> Mark
>

@@server_name

Should it concern me that the code below returns Null' I simply was hoping
to get the name of the server as a string ...
select @.@.SERVERNAME
Thanks in advance.
MarkHi
Run sp_dropserver and then sp_addserver against the server.
Master DB does not have a valid value for the server. This can occur on
servers where Master DB was restored, or upgraded or the server name was
changed.
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/
"Mark" <Mark@.nowhere.com> wrote in message
news:eJZOBVWDFHA.3256@.tk2msftngp13.phx.gbl...
> Should it concern me that the code below returns Null' I simply was
hoping
> to get the name of the server as a string ...
> select @.@.SERVERNAME
> Thanks in advance.
> Mark
>

@@server_name

Should it concern me that the code below returns Null' I simply was hoping
to get the name of the server as a string ...
select @.@.SERVERNAME
Thanks in advance.
MarkHi
Run sp_dropserver and then sp_addserver against the server.
Master DB does not have a valid value for the server. This can occur on
servers where Master DB was restored, or upgraded or the server name was
changed.
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/
"Mark" <Mark@.nowhere.com> wrote in message
news:eJZOBVWDFHA.3256@.tk2msftngp13.phx.gbl...
> Should it concern me that the code below returns Null' I simply was
hoping
> to get the name of the server as a string ...
> select @.@.SERVERNAME
> Thanks in advance.
> Mark
>

@@identity... am i even close here?

string ConnectionString =ConfigurationManager.ConnectionStrings["myConnString"].ConnectionString;

SqlConnection connection =newSqlConnection(ConnectionString);

SqlCommand cmd =newSqlCommand(@."INSERT INTO CreditAppFile (GI_RB_Div) VALUES(@.GI_RB_Div) SELECT @.@.idientity as 'NewID'", connection);

cmd.Parameters.Add("@.ID", SqlDbType.BigInt, 8).Value = NewID.Text;

.

.

Response.Redirect(DisplayPage.aspx?ID=@.ID);

i want the ID of the most recently added record to be passed to another page to show all entered data from the prior page... am i close?

A general way is to use a stored procedure to do the INSERT and return the value of the ID via OUTPUT Parameter. Also, please use SCOPE_IDENTITY() instead of @.@.IDENTITY.

From Books On Line:

SCOPE_IDENTITY and @.@.IDENTITY return the last identity values that are generated in any table in the current session. However, SCOPE_IDENTITY returns values inserted only within the current scope; @.@.IDENTITY is not limited to a specific scope.

|||

Check the second part of this article:http://dotnetjunkies.com/WebLog/dinakar/articles/74220.aspx to see some sample code for using stored procedures with OUTPUT parameters.

|||

Like Dinakar, my preference is for using stored procedures, but that is not always possible. You can pass two consecutive SQL commands to the command object as you have (almost) done in your example, but they must be separated by a semi-colon. The only parameter you need to add to the command object is the one for @.GI_RB_Div. Then, using Scope_Identity(), your code would look like this:

string connstr = WebConfigurationManager.ConnectionStrings["MyConn"].ConnectionString;
string query = "INSERT INTO CreditAppFile (GI_RB_Div) VALUES(@.GI_RB_Div); Select Scope_Identity();";

SqlConnection conn = new SqlConnection(connstr);
SqlCommand cmd = new SqlCommand(query, conn);
cmd.Parameters.AddWithValue("@.GI_RB_Div", <Value>);
conn.Open();
string NewID = cmd.ExecuteScalar().ToString();
conn.Close();
Server.Transfer("DisplayPage.aspx?ID=" + NewID);

|||

Compiler Error Message:CS1501: No overload for method 'AddWithValue' takes '3' arguments

Source Error:

Line 203: tryLine 204: {Line 205: cmd.Parameters.AddWithValue("@.GI_RB_Div", SqlDbType.VarChar, 50).Value = GI_RB_Div.SelectedValue;Line 206: cmd.Parameters.AddWithValue("@.GI_RB_ExistCust", SqlDbType.VarChar, 50).Value = GI_RB_ExistCust.SelectedValue;Line 207: cmd.Parameters.AddWithValue("@.GI_TB_LegalFirmName", SqlDbType.VarChar, 50).Value = GI_TB_LegalFirmName.Text;

is my error...... any suggesstions?

thanks!!!

|||

You are mixing the syntax of Add, and AddWithValue.

AddWithValue takes a parameters name, and a value and it tries to guess what the datatype should be based on the value. Most of the time it works, sometimes it doesn't do exactly what you want/expect, so I recommend using Add instead and specifying the type.

This is how you would do it in VB.NET, you'll need to convert it to C#:

cmd.Parameters.Add("@.GI_RB_Div", SqlDbType.VarChar, 50).Value = GI_RB_Div.SelectedValue
cmd.Parameters.Add("@.GI_RB_ExistCust", SqlDbType.VarChar, 50).Value = GI_RB_ExistCust.SelectedValue
cmd.Parameters.Add("@.GI_TB_LegalFirmName", SqlDbType.VarChar, 50).Value = GI_TB_LegalFirmName.Text