> Has anyone got an example of a wish list request coming into the
> language/server?
>
> Not being flippant, just interested is all.
I can think of quite a few. Recently, the support of CFQUERYPARAM with
cached queries, for example.
Dave Watts, CTO, Fig Leaf Software
http://www.figleaf.com/
Fi
Jochem van Dieten wrote:
> ColdFusion comes with DataDirect 3.x.
>
> http://adobe.com/go/wish/
or you might give jTDS a spin.
~|
Adobe® ColdFusion® 8 software 8 is the most important and dramatic release to
date
Get the Free T
Has anyone got an example of a wish list request coming into the
language/server?
Not being flippant, just interested is all.
Adrian
> -Original Message-
> From: Jochem van Dieten [mailto:joch...@gmail.com]
> Sent: 17 February 2009 16:41
> To: cf-talk
> Subject: Re: May
On Tue, Feb 17, 2009 at 5:33 PM, Rick Root wrote:
> On Sat, Feb 14, 2009 at 6:45 PM, Paul Hastings wrote:
>>
>> ..or you might look to a newer JDBC driver that knows about "n" datatypes.
>> it's
>> not cf, its the db driver.
>
> I find it hard to believe that CF8's database drivers don't know abo
On Sat, Feb 14, 2009 at 6:45 PM, Paul Hastings wrote:
>
> Rick Root wrote:
>> It would seem that way. My rule of thumb is now:
>>
>> Always use nchar even if you know it will NEVER have unicode data in
>> it (like you're storing a coldfusion UUID) because CF will do all
>> unicode or all non-uni
On Sat, Feb 14, 2009 at 10:42 PM, Rick Root wrote:
> It would seem that way. My rule of thumb is now:
>
> Always use nchar even if you know it will NEVER have unicode data in
> it (like you're storing a coldfusion UUID) because CF will do all
> unicode or all non-unicode.
If you need to use MS S
On Sat, Feb 14, 2009 at 2:38 PM, Al Musella, DPM wrote:
> I didn't know that. So would it be safer to use all nchar fields
> in the database instead of char, then no matter what the paramater
> came in as, it is faster to convert the parameter to unicode once
> than to convert every value in th
Original Message
Subject: Re: Maybe I need a SQL Service Consultant...
From: Judah McAuley
Date: Sat, February 14, 2009 6:41 pm
To: cf-talk
So you are saying it wasn't that the index was a different codepage
than the column but rather that the data stream had to be converted
be
So you are saying it wasn't that the index was a different codepage
than the column but rather that the data stream had to be converted
because the data was coming in as Unicode?
I can see that. Obscure but I can see it.
Judah
On Fri, Feb 13, 2009 at 10:41 PM, Brad Wood wrote:
>
> This isn't a
Rick Root wrote:
> It would seem that way. My rule of thumb is now:
>
> Always use nchar even if you know it will NEVER have unicode data in
> it (like you're storing a coldfusion UUID) because CF will do all
> unicode or all non-unicode.
..or you might look to a newer JDBC driver that knows ab
On Sat, Feb 14, 2009 at 8:38 AM, Al Musella, DPM
wrote:
>
> I didn't know that. So would it be safer to use all nchar fields
> in the database instead of char, then no matter what the paramater
> came in as, it is faster to convert the parameter to unicode once
> than to convert every value in
Wow!
I didn't know that. So would it be safer to use all nchar fields
in the database instead of char, then no matter what the paramater
came in as, it is faster to convert the parameter to unicode once
than to convert every value in the index?
At 01:41 AM 2/14/2009, you wrote:
>This is
This isn't a bug in SQL Server. Rick said that his primary key column was a
char field and so was the index. Since Unicode support was enabled,
parameters were coming in as nchars or nvarchars.
SQL Server cannot compare a char to an nchar so it must convert one so the
data types match.
http:
That's fascinating. But why would sql server create an index in a
codeset that didn't match the column? You'd think that the index would
match the declared type of the column automatically. I would think of
that as a bug in sql server.
We're moving some applications to do more multilingual suppor
On Thu, Feb 12, 2009 at 11:34 AM, Brad Wood wrote:
>
>> resolving the way my database driver was configured
>> helped clear up a lot of problems by reducing the # of reads we were
>> doing.
>
> @Rick, can you provide any specifics on the above change? What did he
> change? How did it reduce rea
> resolving the way my database driver was configured
> helped clear up a lot of problems by reducing the # of reads we were
> doing.
@Rick, can you provide any specifics on the above change? What did he
change? How did it reduce reads?
Thanks.
~Brad
~~
Final update on this issue for future generations
Our SQL expert helped pinpoint some query issues and updated a few
indexes for us... resolving the way my database driver was configured
helped clear up a lot of problems by reducing the # of reads we were
doing. HOWEVER, the server slowdowns
Well, using perfmon I was able to see significant amounts of disk read
and write on the SQL Box during these times... but I still didn't
really know what that meant.
We've contracted a 4 hour block of time from a sql server tuning
expoert and in conversations with him, just based on that informat
> SQL Server 2000 (we don't have a lot of money and the licence was
> cheaper... but we are planning to upgrade sometime soon)
Ok. 2000 doesn't give you near the info 2005 does, but it will give you
quite a bit.
First you need to keep an eye on when your performance spikes hit (which I
think y
Contention deadlocks can be a royal pain to troubleshoot. You're going
to need to find out what query was being run under that PID to see
what it is causing it.
A couple things here: Do you only have one application hitting that
database or are there multiple? If two different applications are
co
SQL Server 2000 (we don't have a lot of money and the licence was
cheaper... but we are planning to upgrade sometime soon)
Anyway.. I just noticed the drive configuration on the server is C:
and D: on one RAID array, and E: and F: on the second. Which means my
data files and OS files are all on
hough I
think you said you had fusion reactor.)
When it comes to diagnosing slow downs-- you can only be as good as your
ability to look under the hood and know what's going on.
~Brad
Original Message ----
Subject: Maybe I need a SQL Service Consultant...
From: Rick Root
Date:
So I've mentioned it before... I have this site that's experiencing
15-20 seconds of "slow" every 12-17 minutes... depending on how busy
the site is. It's not "standardized" enough for me to think it's
related to any kind of scheduled tasks on either the CF server or the
DB server.
Normally, eac
23 matches
Mail list logo