Showing posts with label decide. Show all posts
Showing posts with label decide. Show all posts

Thursday, March 22, 2012

Combined or separate?

We are trying to decide wether to place SQL Server 2000 on the IIS box or
another separate box.
What are the pros and cons of doing this? I'm thinking something like
performance (shared memory vs. TCP),
memory/cpu consumption of the SQL server. Currently the IIS box has an
average CPU usage of ~10%
without having SQL Server 2000 installed.
CasperIf the box can handle the memory and extra proc, then physically no
problem...
However, it is generally not a good practice to put your SQL on the IIS box
because of the security risk... If someone is able to hack into your IIS
box, then they also get SQL for free...
Hope this helps.
Wayne Snyder, MCDBA, SQL Server MVP
Mariner, Charlotte, NC
www.mariner-usa.com
(Please respond only to the newsgroups.)
I support the Professional Association of SQL Server (PASS) and it's
community of SQL Server professionals.
www.sqlpass.org
"Casper Hornstrup" <msdn@.csite.com> wrote in message
news:OVJ0i2POFHA.2384@.tk2msftngp13.phx.gbl...
> We are trying to decide wether to place SQL Server 2000 on the IIS box or
> another separate box.
> What are the pros and cons of doing this? I'm thinking something like
> performance (shared memory vs. TCP),
> memory/cpu consumption of the SQL server. Currently the IIS box has an
> average CPU usage of ~10%
> without having SQL Server 2000 installed.
> Casper
>|||In general the only time this is a good idea, is when implementing a web
farm, and the load on the SQL functionality is a bottleneck to the web
application, and the SQL funtionality (from web app) is read-only.
Say in the case of something like a searh, where the write (update)
functionality is implemented through some kind of publishing on a scheduled,
recurring basis, and the web site (IIS) only reading the local database...
Then the idea of having multiple local copies of the Database, one on each
IIS box in the web farm, can allow you to scale out to any degree
necessary...
"Casper Hornstrup" wrote:

> We are trying to decide wether to place SQL Server 2000 on the IIS box or
> another separate box.
> What are the pros and cons of doing this? I'm thinking something like
> performance (shared memory vs. TCP),
> memory/cpu consumption of the SQL server. Currently the IIS box has an
> average CPU usage of ~10%
> without having SQL Server 2000 installed.
> Casper
>
>|||So, is this because using shared memory don't make a significant difference
in performance or because there are other divantages that outweigh that
performance increase?
Casper
"CBretana" <cbretana@.areteIndNOSPAM.com> wrote in message
news:8395D217-1EAD-42D0-BB69-4BB617A2F5C4@.microsoft.com...
> In general the only time this is a good idea, is when implementing a web
> farm, and the load on the SQL functionality is a bottleneck to the web
> application, and the SQL funtionality (from web app) is read-only.
> Say in the case of something like a searh, where the write (update)
> functionality is implemented through some kind of publishing on a
scheduled,
> recurring basis, and the web site (IIS) only reading the local database...
> Then the idea of having multiple local copies of the Database, one on each
> IIS box in the web farm, can allow you to scale out to any degree
> necessary...|||I would suggest that there are many reasons to separate SQL
and IIS onto different machines. As Wayne said, there is a
security risk with putting SQL on the same machine as IIS.
There is also the issue of licenses if you have multiple web
servers (and thus multiple SQL Server instances). Then there
is the idea of isolating the bottlenecks. If IIS is the
bottleneck, you can upgrade your IIS servers with more
memory, for example, without having to touch your SQL boxes.
If SQL's drive array is the bottleneck, you can upgrade one
array (assuming one SQL Server and multiple IIS machines)
without having to update all of your IIS machines. If SQL's
memory and/or CPU are the bottleneck, you can again upgrade
the SQL box while using inexpensive servers for your IIS
servers. If you need better read scalability, then you can
create a shared-none cluster of SQL servers separately from
how you handle IIS.
In short, I would suggest that only in the simplest designs
or most extreme, esoteric reasons should anyone consider
putting SQL on the same box as IIS.
Thomas
"Casper Hornstrup" <msdn@.csite.com> wrote in message
news:OVJ0i2POFHA.2384@.tk2msftngp13.phx.gbl...
> We are trying to decide wether to place SQL Server 2000 on
> the IIS box or
> another separate box.
> What are the pros and cons of doing this? I'm thinking
> something like
> performance (shared memory vs. TCP),
> memory/cpu consumption of the SQL server. Currently the
> IIS box has an
> average CPU usage of ~10%
> without having SQL Server 2000 installed.
> Casper
>|||Shared memory is not the issue, unless the database is very small, the data
will be on disk at least part of the time... The issue, is that in any
production system, there is a chance that you will need more performace as
the business grows, and f your database system proovides OLTP (OnLine
Transaction Processing) functionality, which requires large numbers of
read/write operations, then you cannot <easily> scale up the performance whe
n
the database is "Copies" in multiple places. The "Writes" become a massive
issue. Reads are no problem, because you can replicate the data to multiple
instances...
So if you design and architect your system around having IIS AND SQL On the
same box, and your company never needs morethan one IIS/SQL box to service
it's business, then you're fine... But if yu need to increase performance, a
s
soon as you need to add another IIS box, (and create a web farm) you will
need to put the SQL on it's own separate box...
Again, the exception is if the SQL functionality used by the web app is
readonly...
"Casper Hornstrup" wrote:

> So, is this because using shared memory don't make a significant differenc
e
> in performance or because there are other divantages that outweigh that
> performance increase?
> Casper
> "CBretana" <cbretana@.areteIndNOSPAM.com> wrote in message
> news:8395D217-1EAD-42D0-BB69-4BB617A2F5C4@.microsoft.com...
> scheduled,
>
>

Friday, February 10, 2012

Collation Properties

Hi,
I want to specify case sensitivity for my database, but at the same time i
want let customer decide the sort order.
What i mean is: take the following collation property
SQL_Latin1_general_cs_as
in the above property, i want to specify only CS, and let cusotmer decide
what to (example: what sort order) specify.
Is it possible? How to do this? I hope this is a very natural requirement,
but could find help in MS documents for this
Thanks,
Venkat
The collation determines the sort rules, so you cannot specify a Collation
and apply different sort rules.
Consider two other important issues:
- a collation applied to a single database involves problems regarding the
collation of the other databases of the same instance (eg. master, msdb, etc).
To resolve this issue is better apply a specific collation to the table
columns (very tedious but...).
the Latin1_general_cs_as sorts upper case and lower case separately but in a
different way among Latin1_General_BIN;I don't remember exactly which one,
but one sorts all the upper cases together separately among the lower case,
the other sorts instead A with a, B with b and so on.
Remeber furthermore tha the new collation does'nt convert the collation of
data already present in your tables.
"Venkat" wrote:

> Hi,
> I want to specify case sensitivity for my database, but at the same time i
> want let customer decide the sort order.
> What i mean is: take the following collation property
> SQL_Latin1_general_cs_as
> in the above property, i want to specify only CS, and let cusotmer decide
> what to (example: what sort order) specify.
> Is it possible? How to do this? I hope this is a very natural requirement,
> but could find help in MS documents for this
> Thanks,
> Venkat
>
>
|||Hi,
I would like to understand your statement:
" collation applied to a single database involves problems regarding the
collation of the other databases of the same instance (eg. master, msdb,
etc)."
What is the problem if my database is in diffrent collaiton than the master
database?
I am sure this is possible and there would be no issuees with this.
There might be issues with tempdb, so you can specify collation when you are
creating temp tables.
Can you tell me what is the problems you are expecting if master database
and user database is in diffrent collation?
Other thing you said is: sorting, case sensitivity, accent sensitivity (I
call them as collaiton properties) have to be specified together only?
the reason you said is: all these properties together forms as sort rules?
If so, then when the properties: Latin1, General going to be used and what
purpose they are for? (asume that i have Unicode database)
comments?
Regards,
Venkat
"Gilberto Zampatti" <GilbertoZampatti@.discussions.microsoft.com> wrote in
message news:7E4D942B-9CEE-46E8-805B-F64233738B04@.microsoft.com...[vbcol=seagreen]
> The collation determines the sort rules, so you cannot specify a Collation
> and apply different sort rules.
> Consider two other important issues:
> - a collation applied to a single database involves problems regarding the
> collation of the other databases of the same instance (eg. master, msdb,
> etc).
> To resolve this issue is better apply a specific collation to the table
> columns (very tedious but...).
> the Latin1_general_cs_as sorts upper case and lower case separately but in
> a
> different way among Latin1_General_BIN;I don't remember exactly which one,
> but one sorts all the upper cases together separately among the lower
> case,
> the other sorts instead A with a, B with b and so on.
> Remeber furthermore tha the new collation does'nt convert the collation
> of
> data already present in your tables.
>
> "Venkat" wrote:
|||Hi,
i wrote about issues in generic terms: having objects in different
collations COULD be an issue, but not necessarily IS. Surely some (very
little) overhead due to internal conversion is more probable in presence of
more than one collation.
More: the sort order is implicit in the collation you select: BIN (binary)
sort is different among CS_AS or CI_AS or CI_AI etc.
So the Properties Latin1, General are "complementary" with the CS, CI, AS,
AI, KS (etc.) properties: the sort order could be different among each
available combination.
The concept of collation involves not only sort rules but also character set
consideration.
You cannot define o sort order apart from the selected collation.
"Venkat" wrote:

> Hi,
> I would like to understand your statement:
> " collation applied to a single database involves problems regarding the
> collation of the other databases of the same instance (eg. master, msdb,
> etc)."
> What is the problem if my database is in diffrent collaiton than the master
> database?
> I am sure this is possible and there would be no issuees with this.
> There might be issues with tempdb, so you can specify collation when you are
> creating temp tables.
> Can you tell me what is the problems you are expecting if master database
> and user database is in diffrent collation?
> Other thing you said is: sorting, case sensitivity, accent sensitivity (I
> call them as collaiton properties) have to be specified together only?
> the reason you said is: all these properties together forms as sort rules?
> If so, then when the properties: Latin1, General going to be used and what
> purpose they are for? (asume that i have Unicode database)
> comments?
> Regards,
> Venkat
> "Gilberto Zampatti" <GilbertoZampatti@.discussions.microsoft.com> wrote in
> message news:7E4D942B-9CEE-46E8-805B-F64233738B04@.microsoft.com...
>
>
|||Hi,
I would like to restate what you said about "complimentary" properties like
Latin, General etc.,
As per my understanding these complimentary properties are useful for non
unicode database.
Beucase as per my guess these properties (Latin, General etc.,) specifies
how the data can be stored: in which character set for non unicode database.
Where as these complimnetary properties are of no use (but we still need to
specify) for unicode database.
You have any comments on my understanding?
Regards,
Venkat
"Gilberto Zampatti" <GilbertoZampatti@.discussions.microsoft.com> wrote in
message news:BF5A2E30-5D28-4129-B025-487DB4F6949D@.microsoft.com...[vbcol=seagreen]
> Hi,
> i wrote about issues in generic terms: having objects in different
> collations COULD be an issue, but not necessarily IS. Surely some (very
> little) overhead due to internal conversion is more probable in presence
> of
> more than one collation.
> More: the sort order is implicit in the collation you select: BIN (binary)
> sort is different among CS_AS or CI_AS or CI_AI etc.
> So the Properties Latin1, General are "complementary" with the CS, CI, AS,
> AI, KS (etc.) properties: the sort order could be different among each
> available combination.
> The concept of collation involves not only sort rules but also character
> set
> consideration.
> You cannot define o sort order apart from the selected collation.
>
> "Venkat" wrote:
|||No comments about your understanding.
The question is:
Apart (in unicode evironment) from "localizations" given by the different
available collations (Latin, Japanese, etc), the sort rules are different
between CS, CI, AS, AI,or any combination of them you'll like to select and
the BIN option: anyway, you can make just one choice: so you will provide a
"binary" sort criteria or a case, accent and/or katana sensitivity (or
insensitivity) sorto criteria, depending on the collation you'll set for your
Server, database or column
Regards
Gilberto
"Venkat" wrote:

> Hi,
> I would like to restate what you said about "complimentary" properties like
> Latin, General etc.,
> As per my understanding these complimentary properties are useful for non
> unicode database.
> Beucase as per my guess these properties (Latin, General etc.,) specifies
> how the data can be stored: in which character set for non unicode database.
> Where as these complimnetary properties are of no use (but we still need to
> specify) for unicode database.
> You have any comments on my understanding?
> Regards,
> Venkat
> "Gilberto Zampatti" <GilbertoZampatti@.discussions.microsoft.com> wrote in
> message news:BF5A2E30-5D28-4129-B025-487DB4F6949D@.microsoft.com...
>
>

Collation Properties

Hi,
I want to specify case sensitivity for my database, but at the same time i
want let customer decide the sort order.
What i mean is: take the following collation property
SQL_Latin1_general_cs_as
in the above property, i want to specify only CS, and let cusotmer decide
what to (example: what sort order) specify.
Is it possible? How to do this? I hope this is a very natural requirement,
but could find help in MS documents for this
Thanks,
VenkatThe collation determines the sort rules, so you cannot specify a Collation
and apply different sort rules.
Consider two other important issues:
- a collation applied to a single database involves problems regarding the
collation of the other databases of the same instance (eg. master, msdb, etc
).
To resolve this issue is better apply a specific collation to the table
columns (very tedious but...).
the Latin1_general_cs_as sorts upper case and lower case separately but in a
different way among Latin1_General_BIN;I don't remember exactly which one,
but one sorts all the upper cases together separately among the lower case,
the other sorts instead A with a, B with b and so on.
Remeber furthermore tha the new collation does'nt convert the collation of
data already present in your tables.
"Venkat" wrote:

> Hi,
> I want to specify case sensitivity for my database, but at the same time i
> want let customer decide the sort order.
> What i mean is: take the following collation property
> SQL_Latin1_general_cs_as
> in the above property, i want to specify only CS, and let cusotmer decide
> what to (example: what sort order) specify.
> Is it possible? How to do this? I hope this is a very natural requirement,
> but could find help in MS documents for this
> Thanks,
> Venkat
>
>|||Hi,
I would like to understand your statement:
" collation applied to a single database involves problems regarding the
collation of the other databases of the same instance (eg. master, msdb,
etc)."
What is the problem if my database is in diffrent collaiton than the master
database?
I am sure this is possible and there would be no issuees with this.
There might be issues with tempdb, so you can specify collation when you are
creating temp tables.
Can you tell me what is the problems you are expecting if master database
and user database is in diffrent collation?
Other thing you said is: sorting, case sensitivity, accent sensitivity (I
call them as collaiton properties) have to be specified together only?
the reason you said is: all these properties together forms as sort rules?
If so, then when the properties: Latin1, General going to be used and what
purpose they are for? (asume that i have Unicode database)
comments?
Regards,
Venkat
"Gilberto Zampatti" <GilbertoZampatti@.discussions.microsoft.com> wrote in
message news:7E4D942B-9CEE-46E8-805B-F64233738B04@.microsoft.com...[vbcol=seagreen]
> The collation determines the sort rules, so you cannot specify a Collation
> and apply different sort rules.
> Consider two other important issues:
> - a collation applied to a single database involves problems regarding the
> collation of the other databases of the same instance (eg. master, msdb,
> etc).
> To resolve this issue is better apply a specific collation to the table
> columns (very tedious but...).
> the Latin1_general_cs_as sorts upper case and lower case separately but in
> a
> different way among Latin1_General_BIN;I don't remember exactly which one,
> but one sorts all the upper cases together separately among the lower
> case,
> the other sorts instead A with a, B with b and so on.
> Remeber furthermore tha the new collation does'nt convert the collation
> of
> data already present in your tables.
>
> "Venkat" wrote:
>|||Hi,
i wrote about issues in generic terms: having objects in different
collations COULD be an issue, but not necessarily IS. Surely some (very
little) overhead due to internal conversion is more probable in presence of
more than one collation.
More: the sort order is implicit in the collation you select: BIN (binary)
sort is different among CS_AS or CI_AS or CI_AI etc.
So the Properties Latin1, General are "complementary" with the CS, CI, AS,
AI, KS (etc.) properties: the sort order could be different among each
available combination.
The concept of collation involves not only sort rules but also character set
consideration.
You cannot define o sort order apart from the selected collation.
"Venkat" wrote:

> Hi,
> I would like to understand your statement:
> " collation applied to a single database involves problems regarding the
> collation of the other databases of the same instance (eg. master, msdb,
> etc)."
> What is the problem if my database is in diffrent collaiton than the maste
r
> database?
> I am sure this is possible and there would be no issuees with this.
> There might be issues with tempdb, so you can specify collation when you a
re
> creating temp tables.
> Can you tell me what is the problems you are expecting if master database
> and user database is in diffrent collation?
> Other thing you said is: sorting, case sensitivity, accent sensitivity (I
> call them as collaiton properties) have to be specified together only?
> the reason you said is: all these properties together forms as sort rules?
> If so, then when the properties: Latin1, General going to be used and what
> purpose they are for? (asume that i have Unicode database)
> comments?
> Regards,
> Venkat
> "Gilberto Zampatti" <GilbertoZampatti@.discussions.microsoft.com> wrote in
> message news:7E4D942B-9CEE-46E8-805B-F64233738B04@.microsoft.com...
>
>|||Hi,
I would like to restate what you said about "complimentary" properties like
Latin, General etc.,
As per my understanding these complimentary properties are useful for non
unicode database.
Beucase as per my guess these properties (Latin, General etc.,) specifies
how the data can be stored: in which character set for non unicode database.
Where as these complimnetary properties are of no use (but we still need to
specify) for unicode database.
You have any comments on my understanding?
Regards,
Venkat
"Gilberto Zampatti" <GilbertoZampatti@.discussions.microsoft.com> wrote in
message news:BF5A2E30-5D28-4129-B025-487DB4F6949D@.microsoft.com...[vbcol=seagreen]
> Hi,
> i wrote about issues in generic terms: having objects in different
> collations COULD be an issue, but not necessarily IS. Surely some (very
> little) overhead due to internal conversion is more probable in presence
> of
> more than one collation.
> More: the sort order is implicit in the collation you select: BIN (binary)
> sort is different among CS_AS or CI_AS or CI_AI etc.
> So the Properties Latin1, General are "complementary" with the CS, CI, AS,
> AI, KS (etc.) properties: the sort order could be different among each
> available combination.
> The concept of collation involves not only sort rules but also character
> set
> consideration.
> You cannot define o sort order apart from the selected collation.
>
> "Venkat" wrote:
>|||No comments about your understanding.
The question is:
Apart (in unicode evironment) from "localizations" given by the different
available collations (Latin, Japanese, etc), the sort rules are different
between CS, CI, AS, AI,or any combination of them you'll like to select and
the BIN option: anyway, you can make just one choice: so you will provide a
"binary" sort criteria or a case, accent and/or katana sensitivity (or
insensitivity) sorto criteria, depending on the collation you'll set for you
r
Server, database or column
Regards
Gilberto
"Venkat" wrote:

> Hi,
> I would like to restate what you said about "complimentary" properties lik
e
> Latin, General etc.,
> As per my understanding these complimentary properties are useful for non
> unicode database.
> Beucase as per my guess these properties (Latin, General etc.,) specifies
> how the data can be stored: in which character set for non unicode databas
e.
> Where as these complimnetary properties are of no use (but we still need t
o
> specify) for unicode database.
> You have any comments on my understanding?
> Regards,
> Venkat
> "Gilberto Zampatti" <GilbertoZampatti@.discussions.microsoft.com> wrote in
> message news:BF5A2E30-5D28-4129-B025-487DB4F6949D@.microsoft.com...
>
>

Collation Properties

Hi,
I want to specify case sensitivity for my database, but at the same time i
want let customer decide the sort order.
What i mean is: take the following collation property
SQL_Latin1_general_cs_as
in the above property, i want to specify only CS, and let cusotmer decide
what to (example: what sort order) specify.
Is it possible? How to do this? I hope this is a very natural requirement,
but could find help in MS documents for this
Thanks,
VenkatThe collation determines the sort rules, so you cannot specify a Collation
and apply different sort rules.
Consider two other important issues:
- a collation applied to a single database involves problems regarding the
collation of the other databases of the same instance (eg. master, msdb, etc).
To resolve this issue is better apply a specific collation to the table
columns (very tedious but...).
the Latin1_general_cs_as sorts upper case and lower case separately but in a
different way among Latin1_General_BIN;I don't remember exactly which one,
but one sorts all the upper cases together separately among the lower case,
the other sorts instead A with a, B with b and so on.
Remeber furthermore tha the new collation does'nt convert the collation of
data already present in your tables.
"Venkat" wrote:
> Hi,
> I want to specify case sensitivity for my database, but at the same time i
> want let customer decide the sort order.
> What i mean is: take the following collation property
> SQL_Latin1_general_cs_as
> in the above property, i want to specify only CS, and let cusotmer decide
> what to (example: what sort order) specify.
> Is it possible? How to do this? I hope this is a very natural requirement,
> but could find help in MS documents for this
> Thanks,
> Venkat
>
>|||Hi,
I would like to understand your statement:
" collation applied to a single database involves problems regarding the
collation of the other databases of the same instance (eg. master, msdb,
etc)."
What is the problem if my database is in diffrent collaiton than the master
database?
I am sure this is possible and there would be no issuees with this.
There might be issues with tempdb, so you can specify collation when you are
creating temp tables.
Can you tell me what is the problems you are expecting if master database
and user database is in diffrent collation?
Other thing you said is: sorting, case sensitivity, accent sensitivity (I
call them as collaiton properties) have to be specified together only?
the reason you said is: all these properties together forms as sort rules?
If so, then when the properties: Latin1, General going to be used and what
purpose they are for? (asume that i have Unicode database)
comments?
Regards,
Venkat
"Gilberto Zampatti" <GilbertoZampatti@.discussions.microsoft.com> wrote in
message news:7E4D942B-9CEE-46E8-805B-F64233738B04@.microsoft.com...
> The collation determines the sort rules, so you cannot specify a Collation
> and apply different sort rules.
> Consider two other important issues:
> - a collation applied to a single database involves problems regarding the
> collation of the other databases of the same instance (eg. master, msdb,
> etc).
> To resolve this issue is better apply a specific collation to the table
> columns (very tedious but...).
> the Latin1_general_cs_as sorts upper case and lower case separately but in
> a
> different way among Latin1_General_BIN;I don't remember exactly which one,
> but one sorts all the upper cases together separately among the lower
> case,
> the other sorts instead A with a, B with b and so on.
> Remeber furthermore tha the new collation does'nt convert the collation
> of
> data already present in your tables.
>
> "Venkat" wrote:
>> Hi,
>> I want to specify case sensitivity for my database, but at the same time
>> i
>> want let customer decide the sort order.
>> What i mean is: take the following collation property
>> SQL_Latin1_general_cs_as
>> in the above property, i want to specify only CS, and let cusotmer decide
>> what to (example: what sort order) specify.
>> Is it possible? How to do this? I hope this is a very natural
>> requirement,
>> but could find help in MS documents for this
>> Thanks,
>> Venkat
>>|||Hi,
i wrote about issues in generic terms: having objects in different
collations COULD be an issue, but not necessarily IS. Surely some (very
little) overhead due to internal conversion is more probable in presence of
more than one collation.
More: the sort order is implicit in the collation you select: BIN (binary)
sort is different among CS_AS or CI_AS or CI_AI etc.
So the Properties Latin1, General are "complementary" with the CS, CI, AS,
AI, KS (etc.) properties: the sort order could be different among each
available combination.
The concept of collation involves not only sort rules but also character set
consideration.
You cannot define o sort order apart from the selected collation.
"Venkat" wrote:
> Hi,
> I would like to understand your statement:
> " collation applied to a single database involves problems regarding the
> collation of the other databases of the same instance (eg. master, msdb,
> etc)."
> What is the problem if my database is in diffrent collaiton than the master
> database?
> I am sure this is possible and there would be no issuees with this.
> There might be issues with tempdb, so you can specify collation when you are
> creating temp tables.
> Can you tell me what is the problems you are expecting if master database
> and user database is in diffrent collation?
> Other thing you said is: sorting, case sensitivity, accent sensitivity (I
> call them as collaiton properties) have to be specified together only?
> the reason you said is: all these properties together forms as sort rules?
> If so, then when the properties: Latin1, General going to be used and what
> purpose they are for? (asume that i have Unicode database)
> comments?
> Regards,
> Venkat
> "Gilberto Zampatti" <GilbertoZampatti@.discussions.microsoft.com> wrote in
> message news:7E4D942B-9CEE-46E8-805B-F64233738B04@.microsoft.com...
> > The collation determines the sort rules, so you cannot specify a Collation
> > and apply different sort rules.
> > Consider two other important issues:
> > - a collation applied to a single database involves problems regarding the
> > collation of the other databases of the same instance (eg. master, msdb,
> > etc).
> > To resolve this issue is better apply a specific collation to the table
> > columns (very tedious but...).
> >
> > the Latin1_general_cs_as sorts upper case and lower case separately but in
> > a
> > different way among Latin1_General_BIN;I don't remember exactly which one,
> > but one sorts all the upper cases together separately among the lower
> > case,
> > the other sorts instead A with a, B with b and so on.
> >
> > Remeber furthermore tha the new collation does'nt convert the collation
> > of
> > data already present in your tables.
> >
> >
> > "Venkat" wrote:
> >
> >> Hi,
> >> I want to specify case sensitivity for my database, but at the same time
> >> i
> >> want let customer decide the sort order.
> >> What i mean is: take the following collation property
> >> SQL_Latin1_general_cs_as
> >>
> >> in the above property, i want to specify only CS, and let cusotmer decide
> >> what to (example: what sort order) specify.
> >>
> >> Is it possible? How to do this? I hope this is a very natural
> >> requirement,
> >> but could find help in MS documents for this
> >>
> >> Thanks,
> >> Venkat
> >>
> >>
> >>
>
>|||Hi,
I would like to restate what you said about "complimentary" properties like
Latin, General etc.,
As per my understanding these complimentary properties are useful for non
unicode database.
Beucase as per my guess these properties (Latin, General etc.,) specifies
how the data can be stored: in which character set for non unicode database.
Where as these complimnetary properties are of no use (but we still need to
specify) for unicode database.
You have any comments on my understanding?
Regards,
Venkat
"Gilberto Zampatti" <GilbertoZampatti@.discussions.microsoft.com> wrote in
message news:BF5A2E30-5D28-4129-B025-487DB4F6949D@.microsoft.com...
> Hi,
> i wrote about issues in generic terms: having objects in different
> collations COULD be an issue, but not necessarily IS. Surely some (very
> little) overhead due to internal conversion is more probable in presence
> of
> more than one collation.
> More: the sort order is implicit in the collation you select: BIN (binary)
> sort is different among CS_AS or CI_AS or CI_AI etc.
> So the Properties Latin1, General are "complementary" with the CS, CI, AS,
> AI, KS (etc.) properties: the sort order could be different among each
> available combination.
> The concept of collation involves not only sort rules but also character
> set
> consideration.
> You cannot define o sort order apart from the selected collation.
>
> "Venkat" wrote:
>> Hi,
>> I would like to understand your statement:
>> " collation applied to a single database involves problems regarding the
>> collation of the other databases of the same instance (eg. master, msdb,
>> etc)."
>> What is the problem if my database is in diffrent collaiton than the
>> master
>> database?
>> I am sure this is possible and there would be no issuees with this.
>> There might be issues with tempdb, so you can specify collation when you
>> are
>> creating temp tables.
>> Can you tell me what is the problems you are expecting if master database
>> and user database is in diffrent collation?
>> Other thing you said is: sorting, case sensitivity, accent sensitivity (I
>> call them as collaiton properties) have to be specified together only?
>> the reason you said is: all these properties together forms as sort
>> rules?
>> If so, then when the properties: Latin1, General going to be used and
>> what
>> purpose they are for? (asume that i have Unicode database)
>> comments?
>> Regards,
>> Venkat
>> "Gilberto Zampatti" <GilbertoZampatti@.discussions.microsoft.com> wrote in
>> message news:7E4D942B-9CEE-46E8-805B-F64233738B04@.microsoft.com...
>> > The collation determines the sort rules, so you cannot specify a
>> > Collation
>> > and apply different sort rules.
>> > Consider two other important issues:
>> > - a collation applied to a single database involves problems regarding
>> > the
>> > collation of the other databases of the same instance (eg. master,
>> > msdb,
>> > etc).
>> > To resolve this issue is better apply a specific collation to the table
>> > columns (very tedious but...).
>> >
>> > the Latin1_general_cs_as sorts upper case and lower case separately but
>> > in
>> > a
>> > different way among Latin1_General_BIN;I don't remember exactly which
>> > one,
>> > but one sorts all the upper cases together separately among the lower
>> > case,
>> > the other sorts instead A with a, B with b and so on.
>> >
>> > Remeber furthermore tha the new collation does'nt convert the
>> > collation
>> > of
>> > data already present in your tables.
>> >
>> >
>> > "Venkat" wrote:
>> >
>> >> Hi,
>> >> I want to specify case sensitivity for my database, but at the same
>> >> time
>> >> i
>> >> want let customer decide the sort order.
>> >> What i mean is: take the following collation property
>> >> SQL_Latin1_general_cs_as
>> >>
>> >> in the above property, i want to specify only CS, and let cusotmer
>> >> decide
>> >> what to (example: what sort order) specify.
>> >>
>> >> Is it possible? How to do this? I hope this is a very natural
>> >> requirement,
>> >> but could find help in MS documents for this
>> >>
>> >> Thanks,
>> >> Venkat
>> >>
>> >>
>> >>
>>|||No comments about your understanding.
The question is:
Apart (in unicode evironment) from "localizations" given by the different
available collations (Latin, Japanese, etc), the sort rules are different
between CS, CI, AS, AI,or any combination of them you'll like to select and
the BIN option: anyway, you can make just one choice: so you will provide a
"binary" sort criteria or a case, accent and/or katana sensitivity (or
insensitivity) sorto criteria, depending on the collation you'll set for your
Server, database or column
Regards
Gilberto
"Venkat" wrote:
> Hi,
> I would like to restate what you said about "complimentary" properties like
> Latin, General etc.,
> As per my understanding these complimentary properties are useful for non
> unicode database.
> Beucase as per my guess these properties (Latin, General etc.,) specifies
> how the data can be stored: in which character set for non unicode database.
> Where as these complimnetary properties are of no use (but we still need to
> specify) for unicode database.
> You have any comments on my understanding?
> Regards,
> Venkat
> "Gilberto Zampatti" <GilbertoZampatti@.discussions.microsoft.com> wrote in
> message news:BF5A2E30-5D28-4129-B025-487DB4F6949D@.microsoft.com...
> > Hi,
> > i wrote about issues in generic terms: having objects in different
> > collations COULD be an issue, but not necessarily IS. Surely some (very
> > little) overhead due to internal conversion is more probable in presence
> > of
> > more than one collation.
> >
> > More: the sort order is implicit in the collation you select: BIN (binary)
> > sort is different among CS_AS or CI_AS or CI_AI etc.
> > So the Properties Latin1, General are "complementary" with the CS, CI, AS,
> > AI, KS (etc.) properties: the sort order could be different among each
> > available combination.
> > The concept of collation involves not only sort rules but also character
> > set
> > consideration.
> > You cannot define o sort order apart from the selected collation.
> >
> >
> > "Venkat" wrote:
> >
> >> Hi,
> >> I would like to understand your statement:
> >> " collation applied to a single database involves problems regarding the
> >> collation of the other databases of the same instance (eg. master, msdb,
> >> etc)."
> >>
> >> What is the problem if my database is in diffrent collaiton than the
> >> master
> >> database?
> >> I am sure this is possible and there would be no issuees with this.
> >> There might be issues with tempdb, so you can specify collation when you
> >> are
> >> creating temp tables.
> >>
> >> Can you tell me what is the problems you are expecting if master database
> >> and user database is in diffrent collation?
> >>
> >> Other thing you said is: sorting, case sensitivity, accent sensitivity (I
> >> call them as collaiton properties) have to be specified together only?
> >> the reason you said is: all these properties together forms as sort
> >> rules?
> >>
> >> If so, then when the properties: Latin1, General going to be used and
> >> what
> >> purpose they are for? (asume that i have Unicode database)
> >>
> >> comments?
> >>
> >> Regards,
> >> Venkat
> >>
> >> "Gilberto Zampatti" <GilbertoZampatti@.discussions.microsoft.com> wrote in
> >> message news:7E4D942B-9CEE-46E8-805B-F64233738B04@.microsoft.com...
> >> > The collation determines the sort rules, so you cannot specify a
> >> > Collation
> >> > and apply different sort rules.
> >> > Consider two other important issues:
> >> > - a collation applied to a single database involves problems regarding
> >> > the
> >> > collation of the other databases of the same instance (eg. master,
> >> > msdb,
> >> > etc).
> >> > To resolve this issue is better apply a specific collation to the table
> >> > columns (very tedious but...).
> >> >
> >> > the Latin1_general_cs_as sorts upper case and lower case separately but
> >> > in
> >> > a
> >> > different way among Latin1_General_BIN;I don't remember exactly which
> >> > one,
> >> > but one sorts all the upper cases together separately among the lower
> >> > case,
> >> > the other sorts instead A with a, B with b and so on.
> >> >
> >> > Remeber furthermore tha the new collation does'nt convert the
> >> > collation
> >> > of
> >> > data already present in your tables.
> >> >
> >> >
> >> > "Venkat" wrote:
> >> >
> >> >> Hi,
> >> >> I want to specify case sensitivity for my database, but at the same
> >> >> time
> >> >> i
> >> >> want let customer decide the sort order.
> >> >> What i mean is: take the following collation property
> >> >> SQL_Latin1_general_cs_as
> >> >>
> >> >> in the above property, i want to specify only CS, and let cusotmer
> >> >> decide
> >> >> what to (example: what sort order) specify.
> >> >>
> >> >> Is it possible? How to do this? I hope this is a very natural
> >> >> requirement,
> >> >> but could find help in MS documents for this
> >> >>
> >> >> Thanks,
> >> >> Venkat
> >> >>
> >> >>
> >> >>
> >>
> >>
> >>
>
>