Roy,

<< "The collation determines the sensitivity and thus whether the query is
optimized or not, but this doesn't mean it uses a temp file." >>

Yes, you are correct.  The sensitivity of the query has nothing to do with
its level of optimization, or vice-versa.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim,

> << "The collation determines the sensitivity and thus whether the query is
> optimized or not, but this doesn't mean it uses a temp file." >>
>
> Yes, you are correct.  The sensitivity of the query has nothing to do with
> its level of optimization, or vice-versa.

Thanks again! For the quote is mine and not Roy's. Not that this is very
important <BG> though nice, but Roy's statement is now not confirmed nor
denied by you and I guess he would like it to be confirmed.

Best regards,
Fons

Fons,

<< Thanks again! For the quote is mine and not Roy's. Not that this is very
important <BG> though nice, but Roy's statement is now not confirmed nor
denied by you and I guess he would like it to be confirmed. >>

Yes, I was confirming Roy's post.  Your original statement that was quoted
by Roy was incorrect.

Man, I really confused the heck out of that thread.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim,

> Yes, I was confirming Roy's post.  Your original statement that was quoted
> by Roy was incorrect.

There goes my 100% correct answer. Yep, now that I'm reading it again and
again and again ("The collation determines the sensitivity and thus whether
the query is optimized or not, but this doesn't mean it uses a temp file.")
it's not completely correct.

> Man, I really confused the heck out of that thread.

Same here. So let me rephrase the statement into "The collation (also)
determines whether a query is optimized or not, but this doesn't mean it
uses a temp file because the use of a temp file is related to sensitivity".
If this is not 100% correct, than I seriously need to study the manual <
anti BG>

Best regards,
Fons

Fons,

<< Same here. So let me rephrase the statement into "The collation (also)
determines whether a query is optimized or not, but this doesn't mean it
uses a temp file because the use of a temp file is related to sensitivity".
>>

Yes, that is correct.

The bottom line is that sensitivity <> optimizability.

--
Tim Young
Elevate Software
www.elevatesoft.com

Fons


If this get any worse we'll have to draft lawyers in to write the manuals <vbg>

Roy Lambert

Roy,

> If this get any worse we'll have to draft lawyers in to write the manuals
> <vbg>

I don't know how you do it, but you always manage to put a smile on my face


You have a real good sense of humor.

Best regards,
Fons

Thanks everyone.... I won't be using GUIDs any more! Flipped back to
integers, and saw what looks like about a 30% performance improvement on
avg.  :0



jr


"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in message
news:90FDF90F-0130-4FEF-B0A7-7D4D4D6114E3@news.elevatesoft.com...
> James,
>
> << I am using GUIDs as my primary keys in tables. For performance reasons
> & best/recommended practices with ElevateDB, does anyone know if they be
> case sensitive or case insensitive? >>
>
> Case-sensitive is faster when using the default collations: ANSI/UNI.
> With any other collations (Windows-based), it is actually faster to use
> case-insensitive collations (at least according to Microsoft).
>
> --
> Tim Young
> Elevate Software
> www.elevatesoft.com
>