> Also, I don't think the problem has to do with a returned
> record set but with SQL Server returning some other meta-data
> and information (i.e., X rows inserted/affected, etc.).
which your client shouldn't confuse with a recordset. I'm not saying
that all clients behave properly, though
Janet MacKay wrote:
> I believe it. It works for me without SET NOCOUNT in 7.0.2. But I
> seem to recall using some version or combination where it didn't work
> without using SET NOCOUNT. CF would report #queryName.columnName# was
> undefined. I don't know enough about the inner workings to say
Dave Watts wrote:
> It's worked fine for me with ODBC and JDBC. The INSERT doesn't return a
> recordset, the SELECT does. I may well have just been extremely lucky,
> I guess, but I wouldn't think this is required. You are aliasing the
> @@IDENTITY value, right?
Dave:
Yes, aliasing it as follows:
>It's worked fine for me with ODBC and JDBC. The INSERT doesn't return a
>recordset, the SELECT does. I may well have just been extremely lucky, I
>guess, but I wouldn't think this is required. You are aliasing the
>@@IDENTITY value, right?
Yes, I was using an alias. I think what I'm remembering
back @@Identity. I've been
doing it since CF 4.x. But perhaps I just borrowed it from Query analyzer or
a stored proc or something.
-Mark
-Original Message-
From: Dave Watts [mailto:[EMAIL PROTECTED]
Sent: Friday, October 26, 2007 12:03 PM
To: CF-Talk
Subject: RE: CFQueryParam apostrop
> It could be that you're using ODBC. I usually use jdbc and
> most versions I've used won't return the second SELECT to
> cfquery unless I use SET NOCOUNT. I assume its because
> cfquery detects the first resultset (ie rows affected by the
> insert) and ignores any further resultsets. Perhaps
October 26, 2007 10:11 AM
To: CF-Talk
Subject: RE: CFQueryParam apostrophe problem when using SET NOCOUNT
> Interestingly enough, I tried running the query without SET NOCOUNT
> and it seems to be working fine (with @@IDENTITY and
> SCOPE_IDENTITY() ). So now I'm confused by the nee
>I've never had to use SET NOCOUNT with @@IDENTITY or SCOPE_IDENTITY(). I've
>been using INSERT INTO followed by SELECT ... @@IDENTITY since SQL Server
>6.5 and CF 1.5.
I believe it. It works for me without SET NOCOUNT in 7.0.2. But I seem to
recall using some version or combination where it di
> Interestingly enough, I tried running the query without SET
> NOCOUNT and it seems to be working fine (with @@IDENTITY and
> SCOPE_IDENTITY() ). So now I'm confused by the need for it.
> Have later versions of CF learned how to deal the extra data?
I've never had to use SET NOCOUNT with @@I
>Interestingly enough, I tried running the query without SET NOCOUNT and it
>seems to be working fine (with @@IDENTITY and SCOPE_IDENTITY() ). So now
>I'm confused by the need for it. Have later versions of CF learned how to
>deal the extra data?
It could be that you're using ODBC. I usually us
Janet MacKay wrote:
> What version are you using? I don't notice the problem with mx 7.0.2
ColdFusion Server Developer 7,0,2,142559 on SQL Server 9.0.3054 via ODBC
connection.
Dave Watts wrote:
> >Why do you have SET NOCOUNT in the first place?
>
> The resulset generated by the insert can preven
What version are you using? I don't notice the problem with mx 7.0.2
>Why do you have SET NOCOUNT in the first place?
The resulset generated by the insert can prevent cfquery from picking up the
SELECT @@identity statement. SET NOCOUNT supresses the insert's resulset.
Though they should be usi
> With this setup, what I noticed was, when I insert an item,
> any apostrophes get stripped from string values. However,
> when I update the item, the apostrophes stayed put.
> Additionally, when I removed everything but the actual
> SQL/CFQueryParam code from the insert query, the apostroph
13 matches
Mail list logo
