_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

_WA_SYS% indexes

Does _WA_SYS%(I understand these are optimizer statistics indexes) indexes in
sysindexes impact performance on update, delete or insert?
Any answer will be helpful.
Thanks
Tarlo
No, These are not indexes, they don't have a b-tree associated with them, don't store any data.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
http://www.sqlug.se/
"Tarlo" <Tarlo@.discussions.microsoft.com> wrote in message
news:500DE04C-0239-49B3-BD6C-6B90D44D6C1A@.microsoft.com...
> Does _WA_SYS%(I understand these are optimizer statistics indexes) indexes in
> sysindexes impact performance on update, delete or insert?
> Any answer will be helpful.
> Thanks
> Tarlo
|||Thanks a bunch it helps.
Regards
Tarlo
"Tibor Karaszi" wrote:

> No, These are not indexes, they don't have a b-tree associated with them, don't store any data.
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://www.solidqualitylearning.com/
> http://www.sqlug.se/
>
> "Tarlo" <Tarlo@.discussions.microsoft.com> wrote in message
> news:500DE04C-0239-49B3-BD6C-6B90D44D6C1A@.microsoft.com...
>
>

_WA_SYS% indexes

Does _WA_SYS%(I understand these are optimizer statistics indexes) indexes i
n
sysindexes impact performance on update, delete or insert?
Any answer will be helpful.
Thanks
TarloNo, These are not indexes, they don't have a b-tree associated with them, do
n't store any data.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
http://www.sqlug.se/
"Tarlo" <Tarlo@.discussions.microsoft.com> wrote in message
news:500DE04C-0239-49B3-BD6C-6B90D44D6C1A@.microsoft.com...
> Does _WA_SYS%(I understand these are optimizer statistics indexes) indexes
in
> sysindexes impact performance on update, delete or insert?
> Any answer will be helpful.
> Thanks
> Tarlo|||Thanks a bunch it helps.
Regards
Tarlo
"Tibor Karaszi" wrote:

> No, These are not indexes, they don't have a b-tree associated with them,
don't store any data.
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://www.solidqualitylearning.com/
> http://www.sqlug.se/
>
> "Tarlo" <Tarlo@.discussions.microsoft.com> wrote in message
> news:500DE04C-0239-49B3-BD6C-6B90D44D6C1A@.microsoft.com...
>
>

_WA_SYS% indexes

Does _WA_SYS%(I understand these are optimizer statistics indexes) indexes in
sysindexes impact performance on update, delete or insert?
Any answer will be helpful.
Thanks
TarloNo, These are not indexes, they don't have a b-tree associated with them, don't store any data.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
http://www.sqlug.se/
"Tarlo" <Tarlo@.discussions.microsoft.com> wrote in message
news:500DE04C-0239-49B3-BD6C-6B90D44D6C1A@.microsoft.com...
> Does _WA_SYS%(I understand these are optimizer statistics indexes) indexes in
> sysindexes impact performance on update, delete or insert?
> Any answer will be helpful.
> Thanks
> Tarlo|||Thanks a bunch it helps.
Regards
Tarlo
"Tibor Karaszi" wrote:
> No, These are not indexes, they don't have a b-tree associated with them, don't store any data.
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://www.solidqualitylearning.com/
> http://www.sqlug.se/
>
> "Tarlo" <Tarlo@.discussions.microsoft.com> wrote in message
> news:500DE04C-0239-49B3-BD6C-6B90D44D6C1A@.microsoft.com...
> > Does _WA_SYS%(I understand these are optimizer statistics indexes) indexes in
> > sysindexes impact performance on update, delete or insert?
> >
> > Any answer will be helpful.
> >
> > Thanks
> >
> > Tarlo
>
>

_WA_SYS indexes

Hi,
What are the indexes's significance startign
with '_WA_SYS_*' present in sysindexes...How they are
created...?
How to omit them when we query to find the indexes that
our application is using...
Regards
Sridhar.Those are not indexes. This is statistics for a column, it is autogenerated.
Check the CREATE STATISTICS command in Books OnLine.
--
Dejan Sarka, SQL Server MVP
Associate Mentor
Solid Quality Learning
More than just Training
www.SolidQualityLearning.com
<anonymous@.discussions.microsoft.com> wrote in message
news:9a1901c433f9$2923ecb0$a501280a@.phx.gbl...
> Hi,
>
> What are the indexes's significance startign
> with '_WA_SYS_*' present in sysindexes...How they are
> created...?
> How to omit them when we query to find the indexes that
> our application is using...
>
> Regards
> Sridhar.
>|||You can exclude statistics by filtering the IsStatistics INDEXPROPERTY:
SELECT name
FROM sysindexes
WHERE indid BETWEEN 1 AND 254 AND
INDEXPROPERTY(id, name, 'IsStatistics') = 0
--
Hope this helps.
Dan Guzman
SQL Server MVP
<anonymous@.discussions.microsoft.com> wrote in message
news:9a1901c433f9$2923ecb0$a501280a@.phx.gbl...
> Hi,
>
> What are the indexes's significance startign
> with '_WA_SYS_*' present in sysindexes...How they are
> created...?
> How to omit them when we query to find the indexes that
> our application is using...
>
> Regards
> Sridhar.
>

_WA_SYS indexes

Hi,
What are the indexes's significance startign
with '_WA_SYS_*' present in sysindexes...How they are
created...?
How to omit them when we query to find the indexes that
our application is using...
Regards
Sridhar.Those are not indexes. This is statistics for a column, it is autogenerated.
Check the CREATE STATISTICS command in Books OnLine.
Dejan Sarka, SQL Server MVP
Associate Mentor
Solid Quality Learning
More than just Training
www.SolidQualityLearning.com
<anonymous@.discussions.microsoft.com> wrote in message
news:9a1901c433f9$2923ecb0$a501280a@.phx.gbl...
> Hi,
>
> What are the indexes's significance startign
> with '_WA_SYS_*' present in sysindexes...How they are
> created...?
> How to omit them when we query to find the indexes that
> our application is using...
>
> Regards
> Sridhar.
>|||You can exclude statistics by filtering the IsStatistics INDEXPROPERTY:
SELECT name
FROM sysindexes
WHERE indid BETWEEN 1 AND 254 AND
INDEXPROPERTY(id, name, 'IsStatistics') = 0
Hope this helps.
Dan Guzman
SQL Server MVP
<anonymous@.discussions.microsoft.com> wrote in message
news:9a1901c433f9$2923ecb0$a501280a@.phx.gbl...
> Hi,
>
> What are the indexes's significance startign
> with '_WA_SYS_*' present in sysindexes...How they are
> created...?
> How to omit them when we query to find the indexes that
> our application is using...
>
> Regards
> Sridhar.
>sql

_WA_SYS indexes

Hi,
What are the indexes's significance startign
with '_WA_SYS_*' present in sysindexes...How they are
created...?
How to omit them when we query to find the indexes that
our application is using...
Regards
Sridhar.
Those are not indexes. This is statistics for a column, it is autogenerated.
Check the CREATE STATISTICS command in Books OnLine.
Dejan Sarka, SQL Server MVP
Associate Mentor
Solid Quality Learning
More than just Training
www.SolidQualityLearning.com
<anonymous@.discussions.microsoft.com> wrote in message
news:9a1901c433f9$2923ecb0$a501280a@.phx.gbl...
> Hi,
>
> What are the indexes's significance startign
> with '_WA_SYS_*' present in sysindexes...How they are
> created...?
> How to omit them when we query to find the indexes that
> our application is using...
>
> Regards
> Sridhar.
>
|||You can exclude statistics by filtering the IsStatistics INDEXPROPERTY:
SELECT name
FROM sysindexes
WHERE indid BETWEEN 1 AND 254 AND
INDEXPROPERTY(id, name, 'IsStatistics') = 0
Hope this helps.
Dan Guzman
SQL Server MVP
<anonymous@.discussions.microsoft.com> wrote in message
news:9a1901c433f9$2923ecb0$a501280a@.phx.gbl...
> Hi,
>
> What are the indexes's significance startign
> with '_WA_SYS_*' present in sysindexes...How they are
> created...?
> How to omit them when we query to find the indexes that
> our application is using...
>
> Regards
> Sridhar.
>

_WA_ indexes in sysindexes

Hi
I was writing script to defrag my indexes on a regular basis.
I was checking the sysindexes table and found
_WA_ indexes and I do no see a corresponding object for the sysobjects
WHat are these indexes?
Mangesh
These are statistics rather than indexes. You can exclude statistics and
hyhothetical indexes (created by the Index Tuning Wizard) rows in sysindexes
using INDEXPROPERTY:
SELECT OBJECT_NAME(id), name
FROM sysindexes
WHERE
INDEXPROPERTY(id, name, 'IsStatistics') = 0 AND
INDEXPROPERTY(id, name, 'IsHypothetical') = 0
Hope this helps.
Dan Guzman
SQL Server MVP
"Mangesh Deshpande" <MangeshDeshpande@.discussions.microsoft.com> wrote in
message news:0C87800A-4467-4AD0-BCCD-DD822FFF0649@.microsoft.com...
> Hi
> I was writing script to defrag my indexes on a regular basis.
> I was checking the sysindexes table and found
> _WA_ indexes and I do no see a corresponding object for the sysobjects
> WHat are these indexes?
> Mangesh

_WA_ indexes in sysindexes

Hi
I was writing script to defrag my indexes on a regular basis.
I was checking the sysindexes table and found
_WA_ indexes and I do no see a corresponding object for the sysobjects
WHat are these indexes?
MangeshThese are statistics rather than indexes. You can exclude statistics and
hyhothetical indexes (created by the Index Tuning Wizard) rows in sysindexes
using INDEXPROPERTY:
SELECT OBJECT_NAME(id), name
FROM sysindexes
WHERE
INDEXPROPERTY(id, name, 'IsStatistics') = 0 AND
INDEXPROPERTY(id, name, 'IsHypothetical') = 0
Hope this helps.
Dan Guzman
SQL Server MVP
"Mangesh Deshpande" <MangeshDeshpande@.discussions.microsoft.com> wrote in
message news:0C87800A-4467-4AD0-BCCD-DD822FFF0649@.microsoft.com...
> Hi
> I was writing script to defrag my indexes on a regular basis.
> I was checking the sysindexes table and found
> _WA_ indexes and I do no see a corresponding object for the sysobjects
> WHat are these indexes?
> Mangesh

_WA_ indexes in sysindexes

Hi
I was writing script to defrag my indexes on a regular basis.
I was checking the sysindexes table and found
_WA_ indexes and I do no see a corresponding object for the sysobjects
WHat are these indexes?
MangeshThese are statistics rather than indexes. You can exclude statistics and
hyhothetical indexes (created by the Index Tuning Wizard) rows in sysindexes
using INDEXPROPERTY:
SELECT OBJECT_NAME(id), name
FROM sysindexes
WHERE
INDEXPROPERTY(id, name, 'IsStatistics') = 0 AND
INDEXPROPERTY(id, name, 'IsHypothetical') = 0
Hope this helps.
Dan Guzman
SQL Server MVP
"Mangesh Deshpande" <MangeshDeshpande@.discussions.microsoft.com> wrote in
message news:0C87800A-4467-4AD0-BCCD-DD822FFF0649@.microsoft.com...
> Hi
> I was writing script to defrag my indexes on a regular basis.
> I was checking the sysindexes table and found
> _WA_ indexes and I do no see a corresponding object for the sysobjects
> WHat are these indexes?
> Mangesh

_WA_ entries in sysindexes

Hi,
When I look at sysindexes, there are lot of _WA_% entries in there for my
database. These are constraints I believe, created by checking 'Auto create
statistics' option at the DB level. SOmewhere I read that if you see lot of
these constraints, it is better to create 'em as permanent indexes for better
performance.
1) Is that true ?
2) How do I extract the ddl for these constraints ?
TIA
KNM> When I look at sysindexes, there are lot of _WA_% entries in there for my
> database. These are constraints I believe
No, constraints is something entirely different.
> ...created by checking 'Auto create
> statistics' option at the DB level.
Correct. These entries are statistics, the same thing as when you execute the CREATE STATISTICS
command.
> SOmewhere I read that if you see lot of
> these constraints, it is better to create 'em as permanent indexes for better
> performance.
That is not necessarily the case. First, these are not indexes, it is statistics. Big difference.
Also, just because the optimizer feels like having statistics over a column doesn't mean that an
index would be beneficial (and an index comes with overhead). You should analyze what indexes your
queries would benefit from, and it is possible that some of these auto created statistics should be
indexes, but only you can know whether that is the case or not.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"MO" <MO@.discussions.microsoft.com> wrote in message
news:18235A22-6059-4F5E-B2A8-71121719E519@.microsoft.com...
> Hi,
> When I look at sysindexes, there are lot of _WA_% entries in there for my
> database. These are constraints I believe, created by checking 'Auto create
> statistics' option at the DB level. SOmewhere I read that if you see lot of
> these constraints, it is better to create 'em as permanent indexes for better
> performance.
> 1) Is that true ?
> 2) How do I extract the ddl for these constraints ?
> TIA
> KNM|||Thx for your info.
Dumb Q. How do I see what columns the stats is for ?
I know the stats name is say _WA_Sys_ord_billto_66F53242
But on what column the stats is built on ? What command will tell me that ?
TIA
Knm
"Tibor Karaszi" wrote:
> > When I look at sysindexes, there are lot of _WA_% entries in there for my
> > database. These are constraints I believe
> No, constraints is something entirely different.
>
> > ...created by checking 'Auto create
> > statistics' option at the DB level.
> Correct. These entries are statistics, the same thing as when you execute the CREATE STATISTICS
> command.
>
> > SOmewhere I read that if you see lot of
> > these constraints, it is better to create 'em as permanent indexes for better
> > performance.
> That is not necessarily the case. First, these are not indexes, it is statistics. Big difference.
> Also, just because the optimizer feels like having statistics over a column doesn't mean that an
> index would be beneficial (and an index comes with overhead). You should analyze what indexes your
> queries would benefit from, and it is possible that some of these auto created statistics should be
> indexes, but only you can know whether that is the case or not.
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://www.solidqualitylearning.com/
>
> "MO" <MO@.discussions.microsoft.com> wrote in message
> news:18235A22-6059-4F5E-B2A8-71121719E519@.microsoft.com...
> > Hi,
> > When I look at sysindexes, there are lot of _WA_% entries in there for my
> > database. These are constraints I believe, created by checking 'Auto create
> > statistics' option at the DB level. SOmewhere I read that if you see lot of
> > these constraints, it is better to create 'em as permanent indexes for better
> > performance.
> >
> > 1) Is that true ?
> >
> > 2) How do I extract the ddl for these constraints ?
> >
> > TIA
> > KNM
>|||> Dumb Q. How do I see what columns the stats is for ?
One method is to query the system table with a query like the following:
Try
SELECT
OBJECT_NAME(i.id) ,AS TableName
i.name AS StatisticsName,
c.name AS ColumnName
FROM sysindexes i
JOIN sysindexkeys k ON
k.id = i.id and k.indid = i.indid
JOIN syscolumns c on
c.id = k.id and c.colid = k.colid
WHERE INDEXPROPERTY(i.id, i.name, 'IsStatistics') = 1
ORDER BY
OBJECT_NAME(i.id),
i.name,
c.name
--
Hope this helps.
Dan Guzman
SQL Server MVP
"MO" <MO@.discussions.microsoft.com> wrote in message
news:80809AF6-100F-46E9-8CF3-A7F9B8D2E2AF@.microsoft.com...
> Thx for your info.
> Dumb Q. How do I see what columns the stats is for ?
> I know the stats name is say _WA_Sys_ord_billto_66F53242
> But on what column the stats is built on ? What command will tell me that
> ?
> TIA
> Knm
> "Tibor Karaszi" wrote:
>> > When I look at sysindexes, there are lot of _WA_% entries in there
>> > for my
>> > database. These are constraints I believe
>> No, constraints is something entirely different.
>>
>> > ...created by checking 'Auto create
>> > statistics' option at the DB level.
>> Correct. These entries are statistics, the same thing as when you execute
>> the CREATE STATISTICS
>> command.
>>
>> > SOmewhere I read that if you see lot of
>> > these constraints, it is better to create 'em as permanent indexes for
>> > better
>> > performance.
>> That is not necessarily the case. First, these are not indexes, it is
>> statistics. Big difference.
>> Also, just because the optimizer feels like having statistics over a
>> column doesn't mean that an
>> index would be beneficial (and an index comes with overhead). You should
>> analyze what indexes your
>> queries would benefit from, and it is possible that some of these auto
>> created statistics should be
>> indexes, but only you can know whether that is the case or not.
>> --
>> Tibor Karaszi, SQL Server MVP
>> http://www.karaszi.com/sqlserver/default.asp
>> http://www.solidqualitylearning.com/
>>
>> "MO" <MO@.discussions.microsoft.com> wrote in message
>> news:18235A22-6059-4F5E-B2A8-71121719E519@.microsoft.com...
>> > Hi,
>> > When I look at sysindexes, there are lot of _WA_% entries in there
>> > for my
>> > database. These are constraints I believe, created by checking 'Auto
>> > create
>> > statistics' option at the DB level. SOmewhere I read that if you see
>> > lot of
>> > these constraints, it is better to create 'em as permanent indexes for
>> > better
>> > performance.
>> >
>> > 1) Is that true ?
>> >
>> > 2) How do I extract the ddl for these constraints ?
>> >
>> > TIA
>> > KNM
>>|||If you know the table, you can use sp_helpstats
You can pull the table name from sysindexes with this:
select object_name(id)
--
HTH
Kalen Delaney, SQL Server MVP
www.solidqualitylearning.com
"MO" <MO@.discussions.microsoft.com> wrote in message
news:80809AF6-100F-46E9-8CF3-A7F9B8D2E2AF@.microsoft.com...
> Thx for your info.
> Dumb Q. How do I see what columns the stats is for ?
> I know the stats name is say _WA_Sys_ord_billto_66F53242
> But on what column the stats is built on ? What command will tell me that
> ?
> TIA
> Knm
> "Tibor Karaszi" wrote:
>> > When I look at sysindexes, there are lot of _WA_% entries in there
>> > for my
>> > database. These are constraints I believe
>> No, constraints is something entirely different.
>>
>> > ...created by checking 'Auto create
>> > statistics' option at the DB level.
>> Correct. These entries are statistics, the same thing as when you execute
>> the CREATE STATISTICS
>> command.
>>
>> > SOmewhere I read that if you see lot of
>> > these constraints, it is better to create 'em as permanent indexes for
>> > better
>> > performance.
>> That is not necessarily the case. First, these are not indexes, it is
>> statistics. Big difference.
>> Also, just because the optimizer feels like having statistics over a
>> column doesn't mean that an
>> index would be beneficial (and an index comes with overhead). You should
>> analyze what indexes your
>> queries would benefit from, and it is possible that some of these auto
>> created statistics should be
>> indexes, but only you can know whether that is the case or not.
>> --
>> Tibor Karaszi, SQL Server MVP
>> http://www.karaszi.com/sqlserver/default.asp
>> http://www.solidqualitylearning.com/
>>
>> "MO" <MO@.discussions.microsoft.com> wrote in message
>> news:18235A22-6059-4F5E-B2A8-71121719E519@.microsoft.com...
>> > Hi,
>> > When I look at sysindexes, there are lot of _WA_% entries in there
>> > for my
>> > database. These are constraints I believe, created by checking 'Auto
>> > create
>> > statistics' option at the DB level. SOmewhere I read that if you see
>> > lot of
>> > these constraints, it is better to create 'em as permanent indexes for
>> > better
>> > performance.
>> >
>> > 1) Is that true ?
>> >
>> > 2) How do I extract the ddl for these constraints ?
>> >
>> > TIA
>> > KNM
>>|||Thanks for the info. I looked at a table, it has 118 entries in sysindexes
for that table. 6 indexes and 112 contraints. I dropped those constraints to
see if they are being used, but they all got created in couple of min which
tells me that they are being used. So, my question is should I convert those
constraints to an index ?
What are the cons of keeping these as a constraint and not converting to an
index in the long run ?
TIA
MO
"Kalen Delaney" wrote:
> If you know the table, you can use sp_helpstats
> You can pull the table name from sysindexes with this:
> select object_name(id)
> --
> HTH
> Kalen Delaney, SQL Server MVP
> www.solidqualitylearning.com
>
> "MO" <MO@.discussions.microsoft.com> wrote in message
> news:80809AF6-100F-46E9-8CF3-A7F9B8D2E2AF@.microsoft.com...
> > Thx for your info.
> > Dumb Q. How do I see what columns the stats is for ?
> > I know the stats name is say _WA_Sys_ord_billto_66F53242
> > But on what column the stats is built on ? What command will tell me that
> > ?
> > TIA
> > Knm
> >
> > "Tibor Karaszi" wrote:
> >
> >> > When I look at sysindexes, there are lot of _WA_% entries in there
> >> > for my
> >> > database. These are constraints I believe
> >>
> >> No, constraints is something entirely different.
> >>
> >>
> >> > ...created by checking 'Auto create
> >> > statistics' option at the DB level.
> >>
> >> Correct. These entries are statistics, the same thing as when you execute
> >> the CREATE STATISTICS
> >> command.
> >>
> >>
> >> > SOmewhere I read that if you see lot of
> >> > these constraints, it is better to create 'em as permanent indexes for
> >> > better
> >> > performance.
> >>
> >> That is not necessarily the case. First, these are not indexes, it is
> >> statistics. Big difference.
> >> Also, just because the optimizer feels like having statistics over a
> >> column doesn't mean that an
> >> index would be beneficial (and an index comes with overhead). You should
> >> analyze what indexes your
> >> queries would benefit from, and it is possible that some of these auto
> >> created statistics should be
> >> indexes, but only you can know whether that is the case or not.
> >>
> >> --
> >> Tibor Karaszi, SQL Server MVP
> >> http://www.karaszi.com/sqlserver/default.asp
> >> http://www.solidqualitylearning.com/
> >>
> >>
> >> "MO" <MO@.discussions.microsoft.com> wrote in message
> >> news:18235A22-6059-4F5E-B2A8-71121719E519@.microsoft.com...
> >> > Hi,
> >> > When I look at sysindexes, there are lot of _WA_% entries in there
> >> > for my
> >> > database. These are constraints I believe, created by checking 'Auto
> >> > create
> >> > statistics' option at the DB level. SOmewhere I read that if you see
> >> > lot of
> >> > these constraints, it is better to create 'em as permanent indexes for
> >> > better
> >> > performance.
> >> >
> >> > 1) Is that true ?
> >> >
> >> > 2) How do I extract the ddl for these constraints ?
> >> >
> >> > TIA
> >> > KNM
> >>
> >>
>
>|||They are not constraints, bit difference. They are entries for SQL Server to hold statistics over
the data in a column of the table. Whether you should create such indexes, only you can tell. It is
likely that your queries can benefit from indexes on some over the columns that these statistics has
been created. OTOH, you most probably don't want to have 118 indexes on a table (imagine the
slowness of your modifications and storage requirements). Analyze your queries, their execution
plans and create indexes that makes sense.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"MO" <MO@.discussions.microsoft.com> wrote in message
news:AE7CA10C-4F2C-49D0-B64D-CA40728053CC@.microsoft.com...
> Thanks for the info. I looked at a table, it has 118 entries in sysindexes
> for that table. 6 indexes and 112 contraints. I dropped those constraints to
> see if they are being used, but they all got created in couple of min which
> tells me that they are being used. So, my question is should I convert those
> constraints to an index ?
> What are the cons of keeping these as a constraint and not converting to an
> index in the long run ?
> TIA
> MO
> "Kalen Delaney" wrote:
>> If you know the table, you can use sp_helpstats
>> You can pull the table name from sysindexes with this:
>> select object_name(id)
>> --
>> HTH
>> Kalen Delaney, SQL Server MVP
>> www.solidqualitylearning.com
>>
>> "MO" <MO@.discussions.microsoft.com> wrote in message
>> news:80809AF6-100F-46E9-8CF3-A7F9B8D2E2AF@.microsoft.com...
>> > Thx for your info.
>> > Dumb Q. How do I see what columns the stats is for ?
>> > I know the stats name is say _WA_Sys_ord_billto_66F53242
>> > But on what column the stats is built on ? What command will tell me that
>> > ?
>> > TIA
>> > Knm
>> >
>> > "Tibor Karaszi" wrote:
>> >
>> >> > When I look at sysindexes, there are lot of _WA_% entries in there
>> >> > for my
>> >> > database. These are constraints I believe
>> >>
>> >> No, constraints is something entirely different.
>> >>
>> >>
>> >> > ...created by checking 'Auto create
>> >> > statistics' option at the DB level.
>> >>
>> >> Correct. These entries are statistics, the same thing as when you execute
>> >> the CREATE STATISTICS
>> >> command.
>> >>
>> >>
>> >> > SOmewhere I read that if you see lot of
>> >> > these constraints, it is better to create 'em as permanent indexes for
>> >> > better
>> >> > performance.
>> >>
>> >> That is not necessarily the case. First, these are not indexes, it is
>> >> statistics. Big difference.
>> >> Also, just because the optimizer feels like having statistics over a
>> >> column doesn't mean that an
>> >> index would be beneficial (and an index comes with overhead). You should
>> >> analyze what indexes your
>> >> queries would benefit from, and it is possible that some of these auto
>> >> created statistics should be
>> >> indexes, but only you can know whether that is the case or not.
>> >>
>> >> --
>> >> Tibor Karaszi, SQL Server MVP
>> >> http://www.karaszi.com/sqlserver/default.asp
>> >> http://www.solidqualitylearning.com/
>> >>
>> >>
>> >> "MO" <MO@.discussions.microsoft.com> wrote in message
>> >> news:18235A22-6059-4F5E-B2A8-71121719E519@.microsoft.com...
>> >> > Hi,
>> >> > When I look at sysindexes, there are lot of _WA_% entries in there
>> >> > for my
>> >> > database. These are constraints I believe, created by checking 'Auto
>> >> > create
>> >> > statistics' option at the DB level. SOmewhere I read that if you see
>> >> > lot of
>> >> > these constraints, it is better to create 'em as permanent indexes for
>> >> > better
>> >> > performance.
>> >> >
>> >> > 1) Is that true ?
>> >> >
>> >> > 2) How do I extract the ddl for these constraints ?
>> >> >
>> >> > TIA
>> >> > KNM
>> >>
>> >>
>>sql

_WA_ entries in sysindexes

Hi,
When I look at sysindexes, there are lot of _WA_% entries in there for my
database. These are constraints I believe, created by checking 'Auto create
statistics' option at the DB level. SOmewhere I read that if you see lot of
these constraints, it is better to create 'em as permanent indexes for bette
r
performance.
1) Is that true ?
2) How do I extract the ddl for these constraints ?
TIA
KNM> When I look at sysindexes, there are lot of _WA_% entries in there for my">
> database. These are constraints I believe
No, constraints is something entirely different.

> ...created by checking 'Auto create
> statistics' option at the DB level.
Correct. These entries are statistics, the same thing as when you execute th
e CREATE STATISTICS
command.

> SOmewhere I read that if you see lot of
> these constraints, it is better to create 'em as permanent indexes for bet
ter
> performance.
That is not necessarily the case. First, these are not indexes, it is statis
tics. Big difference.
Also, just because the optimizer feels like having statistics over a column
doesn't mean that an
index would be beneficial (and an index comes with overhead). You should ana
lyze what indexes your
queries would benefit from, and it is possible that some of these auto creat
ed statistics should be
indexes, but only you can know whether that is the case or not.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"MO" <MO@.discussions.microsoft.com> wrote in message
news:18235A22-6059-4F5E-B2A8-71121719E519@.microsoft.com...
> Hi,
> When I look at sysindexes, there are lot of _WA_% entries in there for m
y
> database. These are constraints I believe, created by checking 'Auto creat
e
> statistics' option at the DB level. SOmewhere I read that if you see lot o
f
> these constraints, it is better to create 'em as permanent indexes for bet
ter
> performance.
> 1) Is that true ?
> 2) How do I extract the ddl for these constraints ?
> TIA
> KNM|||Thx for your info.
Dumb Q. How do I see what columns the stats is for ?
I know the stats name is say _WA_Sys_ord_billto_66F53242
But on what column the stats is built on ? What command will tell me that ?
TIA
Knm
"Tibor Karaszi" wrote:

> No, constraints is something entirely different.
>
> Correct. These entries are statistics, the same thing as when you execute
the CREATE STATISTICS
> command.
>
> That is not necessarily the case. First, these are not indexes, it is stat
istics. Big difference.
> Also, just because the optimizer feels like having statistics over a colum
n doesn't mean that an
> index would be beneficial (and an index comes with overhead). You should a
nalyze what indexes your
> queries would benefit from, and it is possible that some of these auto cre
ated statistics should be
> indexes, but only you can know whether that is the case or not.
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://www.solidqualitylearning.com/
>
> "MO" <MO@.discussions.microsoft.com> wrote in message
> news:18235A22-6059-4F5E-B2A8-71121719E519@.microsoft.com...
>|||> Dumb Q. How do I see what columns the stats is for ?
One method is to query the system table with a query like the following:
Try
SELECT
OBJECT_NAME(i.id) ,AS TableName
i.name AS StatisticsName,
c.name AS ColumnName
FROM sysindexes i
JOIN sysindexkeys k ON
k.id = i.id and k.indid = i.indid
JOIN syscolumns c on
c.id = k.id and c.colid = k.colid
WHERE INDEXPROPERTY(i.id, i.name, 'IsStatistics') = 1
ORDER BY
OBJECT_NAME(i.id),
i.name,
c.name
Hope this helps.
Dan Guzman
SQL Server MVP
"MO" <MO@.discussions.microsoft.com> wrote in message
news:80809AF6-100F-46E9-8CF3-A7F9B8D2E2AF@.microsoft.com...[vbcol=seagreen]
> Thx for your info.
> Dumb Q. How do I see what columns the stats is for ?
> I know the stats name is say _WA_Sys_ord_billto_66F53242
> But on what column the stats is built on ? What command will tell me that
> ?
> TIA
> Knm
> "Tibor Karaszi" wrote:
>|||If you know the table, you can use sp_helpstats
You can pull the table name from sysindexes with this:
select object_name(id)
HTH
Kalen Delaney, SQL Server MVP
www.solidqualitylearning.com
"MO" <MO@.discussions.microsoft.com> wrote in message
news:80809AF6-100F-46E9-8CF3-A7F9B8D2E2AF@.microsoft.com...[vbcol=seagreen]
> Thx for your info.
> Dumb Q. How do I see what columns the stats is for ?
> I know the stats name is say _WA_Sys_ord_billto_66F53242
> But on what column the stats is built on ? What command will tell me that
> ?
> TIA
> Knm
> "Tibor Karaszi" wrote:
>|||Thanks for the info. I looked at a table, it has 118 entries in sysindexes
for that table. 6 indexes and 112 contraints. I dropped those constraints to
see if they are being used, but they all got created in couple of min which
tells me that they are being used. So, my question is should I convert those
constraints to an index ?
What are the cons of keeping these as a constraint and not converting to an
index in the long run ?
TIA
MO
"Kalen Delaney" wrote:

> If you know the table, you can use sp_helpstats
> You can pull the table name from sysindexes with this:
> select object_name(id)
> --
> HTH
> Kalen Delaney, SQL Server MVP
> www.solidqualitylearning.com
>
> "MO" <MO@.discussions.microsoft.com> wrote in message
> news:80809AF6-100F-46E9-8CF3-A7F9B8D2E2AF@.microsoft.com...
>
>|||They are not constraints, bit difference. They are entries for SQL Server to
hold statistics over
the data in a column of the table. Whether you should create such indexes, o
nly you can tell. It is
likely that your queries can benefit from indexes on some over the columns t
hat these statistics has
been created. OTOH, you most probably don't want to have 118 indexes on a ta
ble (imagine the
slowness of your modifications and storage requirements). Analyze your queri
es, their execution
plans and create indexes that makes sense.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"MO" <MO@.discussions.microsoft.com> wrote in message
news:AE7CA10C-4F2C-49D0-B64D-CA40728053CC@.microsoft.com...[vbcol=seagreen]
> Thanks for the info. I looked at a table, it has 118 entries in sysindexes
> for that table. 6 indexes and 112 contraints. I dropped those constraints
to
> see if they are being used, but they all got created in couple of min whic
h
> tells me that they are being used. So, my question is should I convert tho
se
> constraints to an index ?
> What are the cons of keeping these as a constraint and not converting to a
n
> index in the long run ?
> TIA
> MO
> "Kalen Delaney" wrote:
>

_WA Statistics Error

Hello,
We have had a problem with a table recently where a load had stopped half
with through with an index problem.
After a bit of delving the problem seems to be causes by the system created
Statisitcs for a particial index or at least thats where the error message i
s
pointing to.
The database is set to auto update the statistics and we use this table to
do a lot of loads, truncates and deletes.
My question is this, has anyone seen a problem created by the System created
statisitics and what was the fix.
TIA
PatriciaParticia
What's version are you using?
Havu you ran DBCC SHOW_STATISTICS?
Also take a look at sp_createstats system stored procedure
"Patricia" <Patricia@.discussions.microsoft.com> wrote in message
news:2E80BF08-3146-4749-8142-CC7A7BC1F56D@.microsoft.com...
> Hello,
> We have had a problem with a table recently where a load had stopped half
> with through with an index problem.
> After a bit of delving the problem seems to be causes by the system
> created
> Statisitcs for a particial index or at least thats where the error message
> is
> pointing to.
> The database is set to auto update the statistics and we use this table to
> do a lot of loads, truncates and deletes.
> My question is this, has anyone seen a problem created by the System
> created
> statisitics and what was the fix.
> TIA
> Patricia

_WA Statistics Error

Hello,
We have had a problem with a table recently where a load had stopped half
with through with an index problem.
After a bit of delving the problem seems to be causes by the system created
Statisitcs for a particial index or at least thats where the error message is
pointing to.
The database is set to auto update the statistics and we use this table to
do a lot of loads, truncates and deletes.
My question is this, has anyone seen a problem created by the System created
statisitics and what was the fix.
TIA
PatriciaParticia
What's version are you using?
Havu you ran DBCC SHOW_STATISTICS?
Also take a look at sp_createstats system stored procedure
"Patricia" <Patricia@.discussions.microsoft.com> wrote in message
news:2E80BF08-3146-4749-8142-CC7A7BC1F56D@.microsoft.com...
> Hello,
> We have had a problem with a table recently where a load had stopped half
> with through with an index problem.
> After a bit of delving the problem seems to be causes by the system
> created
> Statisitcs for a particial index or at least thats where the error message
> is
> pointing to.
> The database is set to auto update the statistics and we use this table to
> do a lot of loads, truncates and deletes.
> My question is this, has anyone seen a problem created by the System
> created
> statisitics and what was the fix.
> TIA
> Patricia

_log.ldf - files

Hello,
Sometimes files that end with _log.ldf are left in the same directory as the
.ldf and .mdf-files of a SQL Server database file.
When this happens, the SQL Server files cannot be deleted, unless the
computer is booted up again.
What is the meaning of those files and how can they be removed without
having to reboot the computer?
Many thanks and greetings from Brugge (Bruges - Belgium),
MichelThey can't be deleted because something has them open.
I would, very carefuly, examine the Transaction log information for ALL of
your databases (database propertities) for the name(s) you are seeing.
Jay
"Michel" <Michel@.discussions.microsoft.com> wrote in message
news:7E996834-60E7-4954-9A5C-F7EBECB61224@.microsoft.com...
> Hello,
> Sometimes files that end with _log.ldf are left in the same directory as
> the
> .ldf and .mdf-files of a SQL Server database file.
> When this happens, the SQL Server files cannot be deleted, unless the
> computer is booted up again.
> What is the meaning of those files and how can they be removed without
> having to reboot the computer?
> Many thanks and greetings from Brugge (Bruges - Belgium),
> Michel
>|||Hello,
Thank you very much for your response.
Where do I find these Transaction log information?
Many thanks and greetings from Brugge (Bruges - Belgium),
Michel
"Jay" wrote:
> They can't be deleted because something has them open.
> I would, very carefuly, examine the Transaction log information for ALL of
> your databases (database propertities) for the name(s) you are seeing.
> Jay
> "Michel" <Michel@.discussions.microsoft.com> wrote in message
> news:7E996834-60E7-4954-9A5C-F7EBECB61224@.microsoft.com...
> > Hello,
> >
> > Sometimes files that end with _log.ldf are left in the same directory as
> > the
> > .ldf and .mdf-files of a SQL Server database file.
> > When this happens, the SQL Server files cannot be deleted, unless the
> > computer is booted up again.
> > What is the meaning of those files and how can they be removed without
> > having to reboot the computer?
> >
> > Many thanks and greetings from Brugge (Bruges - Belgium),
> >
> > Michel
> >
>
>|||Hello Michel,
Every database has at least an *.mdf and *.ldf files. If you delete a
database's ldf file, then you can not open that database again.
For more information about Transaction Log files, please check out the
following pages:
Understanding and Managing Transaction Logs:
http://msdn2.microsoft.com/en-us/library/ms345583.aspx
Ekrem Ã?nsoy
"Michel" <Michel@.discussions.microsoft.com> wrote in message
news:7E996834-60E7-4954-9A5C-F7EBECB61224@.microsoft.com...
> Hello,
> Sometimes files that end with _log.ldf are left in the same directory as
> the
> .ldf and .mdf-files of a SQL Server database file.
> When this happens, the SQL Server files cannot be deleted, unless the
> computer is booted up again.
> What is the meaning of those files and how can they be removed without
> having to reboot the computer?
> Many thanks and greetings from Brugge (Bruges - Belgium),
> Michel
>|||In the database propertities, Transaction log tab.
Are you on 2000, or 2005?
"Michel" <Michel@.discussions.microsoft.com> wrote in message
news:BAA804BF-DBCB-4BB6-B4E6-BF1A055710E0@.microsoft.com...
> Hello,
> Thank you very much for your response.
> Where do I find these Transaction log information?
> Many thanks and greetings from Brugge (Bruges - Belgium),
> Michel
>
> "Jay" wrote:
>> They can't be deleted because something has them open.
>> I would, very carefuly, examine the Transaction log information for ALL
>> of
>> your databases (database propertities) for the name(s) you are seeing.
>> Jay
>> "Michel" <Michel@.discussions.microsoft.com> wrote in message
>> news:7E996834-60E7-4954-9A5C-F7EBECB61224@.microsoft.com...
>> > Hello,
>> >
>> > Sometimes files that end with _log.ldf are left in the same directory
>> > as
>> > the
>> > .ldf and .mdf-files of a SQL Server database file.
>> > When this happens, the SQL Server files cannot be deleted, unless the
>> > computer is booted up again.
>> > What is the meaning of those files and how can they be removed without
>> > having to reboot the computer?
>> >
>> > Many thanks and greetings from Brugge (Bruges - Belgium),
>> >
>> > Michel
>> >
>>

_hypmv error

I just tried to update a column type from varchar(32) to varchar(64) in a
table,but got some dependency error like:
The object '_hypmv_0' is dependent on column 'EMAILREFERENCE'.
The object '_hypmv_0_9625' is dependent on column 'EMAILREFERENCE'.
The object '_hypmv_0_7898' is dependent on column 'EMAILREFERENCE'.
The object '_hypmv_0_6539' is dependent on column 'EMAILREFERENCE'.
But,in the dependency listing for the table I cant view any of the above,but
I have
got admin access.What are these dependecies for?any pointer will be greatly
appreciated.
A wild guess is that someone has been running Index Tuning izard which has created "Hypothetical
Materialized Views" (called Indexed Views), and these from some reason haven't been dropped. I'd
check if these are views and if your applications aren't using these, consider dropping them, using
DROP VIEW command.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"c_ani" <cani@.discussions.microsoft.com> wrote in message
news:53B89EB6-C82A-49B2-96C2-84A98CB02FC0@.microsoft.com...
>I just tried to update a column type from varchar(32) to varchar(64) in a
> table,but got some dependency error like:
> The object '_hypmv_0' is dependent on column 'EMAILREFERENCE'.
> The object '_hypmv_0_9625' is dependent on column 'EMAILREFERENCE'.
> The object '_hypmv_0_7898' is dependent on column 'EMAILREFERENCE'.
> The object '_hypmv_0_6539' is dependent on column 'EMAILREFERENCE'.
> But,in the dependency listing for the table I cant view any of the above,but
> I have
> got admin access.What are these dependecies for?any pointer will be greatly
> appreciated.
sql

_hypmv error

I just tried to update a column type from varchar(32) to varchar(64) in a
table,but got some dependency error like:
The object '_hypmv_0' is dependent on column 'EMAILREFERENCE'.
The object '_hypmv_0_9625' is dependent on column 'EMAILREFERENCE'.
The object '_hypmv_0_7898' is dependent on column 'EMAILREFERENCE'.
The object '_hypmv_0_6539' is dependent on column 'EMAILREFERENCE'.
But,in the dependency listing for the table I cant view any of the above,but
I have
got admin access.What are these dependecies for?any pointer will be greatly
appreciated.A wild guess is that someone has been running Index Tuning izard which has created "Hypothetical
Materialized Views" (called Indexed Views), and these from some reason haven't been dropped. I'd
check if these are views and if your applications aren't using these, consider dropping them, using
DROP VIEW command.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"c_ani" <cani@.discussions.microsoft.com> wrote in message
news:53B89EB6-C82A-49B2-96C2-84A98CB02FC0@.microsoft.com...
>I just tried to update a column type from varchar(32) to varchar(64) in a
> table,but got some dependency error like:
> The object '_hypmv_0' is dependent on column 'EMAILREFERENCE'.
> The object '_hypmv_0_9625' is dependent on column 'EMAILREFERENCE'.
> The object '_hypmv_0_7898' is dependent on column 'EMAILREFERENCE'.
> The object '_hypmv_0_6539' is dependent on column 'EMAILREFERENCE'.
> But,in the dependency listing for the table I cant view any of the above,but
> I have
> got admin access.What are these dependecies for?any pointer will be greatly
> appreciated.

][SQL Server]Cannot sort a row of size

Cannot sort a row of size 8155, which is greater than the
allowable maximum of 8094.][SQL Server 7.0]
Does anybody known how to fix this'"Jorge Balzo" <jbalzo@.eclac.cl> wrote:
> Cannot sort a row of size 8155, which is greater than the
> allowable maximum of 8094.][SQL Server 7.0]
> Does anybody known how to fix this'
--
Hi Jorge,
You have reached the maximum row size allowed in a select statement. You
need to either modify your view or table to include varchar() columns or
remove some of the columns so that the total datalength of the data row
doesn't exceed 8094 bytes that requires sorting.
Hope this helps,
--
Eric Cárdenas
SQL Server support|||You could try the ROBUST PLAN optimizer hint. I'm not sure whether it will help in your particular
situation, though.
--
Tibor Karaszi, SQL Server MVP
Archive at: http://groups.google.com/groups?oi=djq&as_ugroup=microsoft.public.sqlserver
"Jorge Balzo" <jbalzo@.eclac.cl> wrote in message news:022601c3b9e1$ed8c7050$a501280a@.phx.gbl...
> Cannot sort a row of size 8155, which is greater than the
> allowable maximum of 8094.][SQL Server 7.0]
> Does anybody known how to fix this'
>

\minint\system32\biosinfo.inf error code 263

I have an HP with Windows XP. I've been gone for a few days and when i came home i tried to start up my PC, but I got:

A disk read error occurred

press ctrl+alt+del to restart

when i do i tap the f10 for system restore, and get the message in the subject line.

When i tap that it send me back to the a disk read error....

I'm not computer literate, but could follow directions or turn it over to my son who is an IT guy.

help, Deuby

Hi,

First of all if you could refer BIOS setting , are you able to see the HDD ? Reset BIOS to default. Check for the Data Cable also.

Hemantgiri S. Goswami

|||

How is this related to SQL Server Security?

Will try to move to a different forum.

Laurentiu

|||

Try the following in order, one at a time - no multi tasking. This was taken from another Forum and has worked at different points on different machines with the same error.

Safest and easiest to try (in order of ease)
-:
*(1) Reset BIOS with "safe" defaults
(2) Yank BIOS battery for about 10 minutes
(3) Disable HD S.M.A.R.T. setting in BIOS
*(4) Disable bus mastering in BIOS
*(5) Disable Ultra DMA (UDMA) moder in BIOS (or at least change the UDMA mode)
(6) Set correct memory settings in BIOS
(7) Test memory to see if it is faulty (MemTest86 from memtest.org is free)
(8) Set HD jumper(s) to Master rather than Cable Select (or even Master w/Slave Present)
(9) Replace HD cable
*(10) Update BIOS
(11) Use FIXBOOT utility on Win XP recovery
*(12) Use chkdsk /r /p
(13) Virus scan (good luck, because that probably isn't the problem)

Medium difficulty and some danger of Data Loss

*(14) Defragment (requires use of second computer or boot to defrag program on CD)
*(15) Use Partition Table Doctor from the Ultimate Boot CD (search on Google)
(16) Use FIXMBR utility on Win XP recovery (DO NOT use if utility indicates non-standard partition if you want to preserve your data!)
(17) Change drive ID from 1 to 0 (if it is 1) or vice versa (personally I don't think this is a good idea); if problem with drive ID, reset ID by powering system on while HD cable is plugged but power unplugged
(18) Resize NTFS Clusters to 4K using partition manager
*(19) Change NTFS to FAT32 using partition manager (and optionally change back to NTFS--although this may cause the problem to recur)

Time-consuming and may not work; definite data loss:

(20) Resize partition below 137 Gb
(21) Perform low-level format on HD (using manufacturer's tools)

Good Luck.

\minint\system32\biosinfo.inf error code 263

I have an HP with Windows XP. I've been gone for a few days and when i came home i tried to start up my PC, but I got:

A disk read error occurred

press ctrl+alt+del to restart

when i do i tap the f10 for system restore, and get the message in the subject line.

When i tap that it send me back to the a disk read error....

I'm not computer literate, but could follow directions or turn it over to my son who is an IT guy.

help, Deuby

Hi,

First of all if you could refer BIOS setting , are you able to see the HDD ? Reset BIOS to default. Check for the Data Cable also.

Hemantgiri S. Goswami

|||

How is this related to SQL Server Security?

Will try to move to a different forum.

Laurentiu

|||

Try the following in order, one at a time - no multi tasking. This was taken from another Forum and has worked at different points on different machines with the same error.

Safest and easiest to try (in order of ease)
-:
*(1) Reset BIOS with "safe" defaults
(2) Yank BIOS battery for about 10 minutes
(3) Disable HD S.M.A.R.T. setting in BIOS
*(4) Disable bus mastering in BIOS
*(5) Disable Ultra DMA (UDMA) moder in BIOS (or at least change the UDMA mode)
(6) Set correct memory settings in BIOS
(7) Test memory to see if it is faulty (MemTest86 from memtest.org is free)
(8) Set HD jumper(s) to Master rather than Cable Select (or even Master w/Slave Present)
(9) Replace HD cable
*(10) Update BIOS
(11) Use FIXBOOT utility on Win XP recovery
*(12) Use chkdsk /r /p
(13) Virus scan (good luck, because that probably isn't the problem)

Medium difficulty and some danger of Data Loss

*(14) Defragment (requires use of second computer or boot to defrag program on CD)
*(15) Use Partition Table Doctor from the Ultimate Boot CD (search on Google)
(16) Use FIXMBR utility on Win XP recovery (DO NOT use if utility indicates non-standard partition if you want to preserve your data!)
(17) Change drive ID from 1 to 0 (if it is 1) or vice versa (personally I don't think this is a good idea); if problem with drive ID, reset ID by powering system on while HD cable is plugged but power unplugged
(18) Resize NTFS Clusters to 4K using partition manager
*(19) Change NTFS to FAT32 using partition manager (and optionally change back to NTFS--although this may cause the problem to recur)

Time-consuming and may not work; definite data loss:

(20) Resize partition below 137 Gb
(21) Perform low-level format on HD (using manufacturer's tools)

Good Luck.

\Backup directories - remove safely?

I've successfully applied SP4 to an MSDE 2000 installation on a
Windows 2000 Professional system. Now I've notived several \Backup
subdirectories in the "Microsoft SLQ Server" directory. Since I don't
want to go back to any previous version, these subdirectories appear
to be no longer required. May I safely remove them?
Heinz Wehner
(Karlsruhe, Germany)
Hi,
No problems. You can delete that directory.
Thanks
Hari
SQL Server MVP
"Heinz Wehner" <hwehner@.hotmail.com> wrote in message
news:c215e1ppe9k9vqim24ckphf0eukkgr6n5a@.4ax.com...
> I've successfully applied SP4 to an MSDE 2000 installation on a
> Windows 2000 Professional system. Now I've notived several \Backup
> subdirectories in the "Microsoft SLQ Server" directory. Since I don't
> want to go back to any previous version, these subdirectories appear
> to be no longer required. May I safely remove them?
> Heinz Wehner
> (Karlsruhe, Germany)
|||Thanks Hari.

> On Sun, 24 Jul 2005 19:32:03 +0530,
> Hari Prasad <hari_prasad_k@.hotmail.com> wrote:
> Hi,
> No problems. You can delete that directory.
> Thanks
> Hari
> SQL Server MVP
>
> Heinz Wehner <hwehner@.hotmail.com>
> wrote in message news:c215e1ppe9k9vqim24ckphf0eukkgr6n5a@.4ax.com...
> I've successfully applied SP4 to an MSDE 2000 installation on a
> Windows 2000 Professional system. Now I've notived several \Backup
> subdirectories in the "Microsoft SLQ Server" directory. Since I don't
> want to go back to any previous version, these subdirectories appear
> to be no longer required. May I safely remove them?
> Heinz Wehner
> (Karlsruhe, Germany)
sql