Bug in Query Analyzer

Execute this in Query Analyzer:
SELECT CONVERT(varchar(8),0x0131) as A, 'X' as B
You will get the expected results if you choose "Results in text", but
if you choose "Results in grid" you will get nothing in column A and
'1' in column B.
Is there anyone at MS reading this ?
Is there any other place I should report this bug ?
Razvan Socol
I can report this as a bug. It does appear taht the grid does not return
the correct information, or atleast does not interpret it correctly.
Rand
This posting is provided "as is" with no warranties and confers no rights.
|||This inserts two characters into A: 0x01 and 0x31. 0x31 is, of course, an
ASCII '1'.
Now you know that 0x01 is the character that QA uses to separate columns
into the grid.
So, the grid has two columns defined by the select, but when populating the
columns QA sees three columns of data: NULL, '1', and 'X'. This causes the
final column of data not to have a home.
So, is this a bug? If Microsoft is willing to think so, that is great, but
I would consider this a behavior instead of a bug.
Russell Fields
"Razvan Socol" <rsocol@.fx.ro> wrote in message
news:60f52b8b.0406090141.7a9f61d7@.posting.google.c om...
> Execute this in Query Analyzer:
> SELECT CONVERT(varchar(8),0x0131) as A, 'X' as B
> You will get the expected results if you choose "Results in text", but
> if you choose "Results in grid" you will get nothing in column A and
> '1' in column B.
> Is there anyone at MS reading this ?
> Is there any other place I should report this bug ?
> Razvan Socol
|||I definitely think that it's a bug. I specifically simplified the
query to this form (the situation I encountered was more complex). I
understood all that you explained before I posted, but it's good that
you did explain it, so that other readers understand.
Razvan
"Russell Fields" <RussellFields@.NoMailPlease.Com> wrote:
> This inserts two characters into A: 0x01 and 0x31. 0x31 is, of course, an
> ASCII '1'.
> Now you know that 0x01 is the character that QA uses to separate columns
> into the grid.
> So, the grid has two columns defined by the select, but when populating the
> columns QA sees three columns of data: NULL, '1', and 'X'. This causes the
> final column of data not to have a home.
> So, is this a bug? If Microsoft is willing to think so, that is great, but
> I would consider this a behavior instead of a bug.
> Russell Fields

BPA issues

BPA (SQL Best practices analyzer) issues
First off, great idea!
-Dead Logons should scavange better. The app locked up on a long operations and when I logged back in it told me I was already logged in. I went into the repository via EM and axed the row out of active_conns and everything was good again. Point being,
the average user might not know to do this and the app won't do anything if you can't logon.
-I get the following 2 lines in the Cursor usage detail when using FAST_FORWARD for my cursor in a sproc. According to BOL FAST_FORWARD = FORWARD_ONLY + READ_ONLY (which is NOT updatable)
-This cursor is declared as updatable, however it doesn't seem to be updated.
-This cursor does not specify explicit updatability information (FOR UPDATE clause or READ_ONLY clause).
-6 exceptions for resutls when running all the rules
Hi Sean
Thanks for your feedback. Some comments inlined.
- Christian
___________________________
Christian Kleinerman
Program Manager, SQL Engine
This posting is provided "AS IS" with no warranties, and confers no rights.
"Sean B" <anonymous@.discussions.microsoft.com> wrote in message
news:C250B186-9486-4BA6-877F-F7C928CCC6DC@.microsoft.com...
> BPA (SQL Best practices analyzer) issues
> First off, great idea!
> -Dead Logons should scavange better. The app locked up on a long
operations and when I logged back in it told me I was already logged in. I
went into the repository via EM and axed the row out of active_conns and
everything was good again. Point being, the average user might not know to
do this and the app won't do anything if you can't logon.
Yes, this was annoying. It has been fixed in later builds.

> -I get the following 2 lines in the Cursor usage detail when using
FAST_FORWARD for my cursor in a sproc. According to BOL FAST_FORWARD =
FORWARD_ONLY + READ_ONLY (which is NOT updatable)
> -This cursor is declared as updatable, however it doesn't seem to be
updated.
> -This cursor does not specify explicit updatability information (FOR
UPDATE clause or READ_ONLY clause).
Fixed this one too, making both, fast_forward and static be treated as read
only cursors.

> -6 exceptions for resutls when running all the rules
>
Do you have more information here?
Thanks for your feedback.
- Christian