Invalid Column Name does not cause error

Hi,
I have a SQL Server 2000 sproc that selects data into a temporary table.
If certain conditions are met, the sproc then uses a join on the temporary
table to update an other table.
In the join for this update, the join column on the temporary table is named
incorrectly.
This code is called as part of a sequence of calls to hundreds of sprocs.
The thing is the code has never raised an error, the successful execution of
the sproc is logged to another table. I would expect the code to raise
something like
Server: Msg 207, Level 16, State 3, Line ..
Invalid column name 'dddddddd'.
I am aware of deferred name resolution but I think that when SQL Server
compiles the procedure the error should be raised.
Of course I can edit the sproc but the client requires evidence of
malfunction. Any help appreciated.Could you please post the DDL of the offending procedure?
ML|||The table is created with a column rt_pol_num. The join is the non-existent
column num_pol_dcrt. I have called the sproc with the recompile option but
the error is not raised.
BEGIN
SELECT DISTINCT
rt_pol_num = DCAM.num_pol_dcrt
Blah, Blah …
INTO #tdcam_t
FROM dcam_t dcam
WHERE dcam.stge_rec_err_ind <> 'Y' AND
dcam.prces_act_cd IN('ISRT') AND
EXISTS
(
SELECT src_key_vlu_txt
FROM alternate_payee_t
WHERE alternate_payee_t.src_key_vlu_txt = 'DCAM' +
DCAM.num_pol_dcrt +
DCAM.num_cert_dcrt +
DCAM.ctlnum_reg_cntrl_number +
UPPER(REPLACE(CONVERT(CHAR(11), DCAM.dte_alt_mail_eff_dcam, 106),
' ', ''))
)
SELECT @.vErrNum = @.@.ERROR, @.vIsrtRecCount = @.@.ROWCOUNT, @.vStatrcTblNm =
'dcam_t'
IF @.vErrNum <> 0
BEGIN
SELECT @.vErrLocNm = 'cannot select from dcam_t into #tdcam_t',
@.vErrTblNm = 'dcam_t',
@.vStatDsc = 'procedure failed'
GOTO ON_ERROR
END
ELSE
SELECT @.vDropTmp = 'DROP TABLE #tdcam_t'
IF @.vIsrtRecCount > 0
BEGIN
IF @.pWriteTable <> 'N'
BEGIN
UPDATE dcam_t
SET stge_rec_err_ind = 'Y'
WHERE EXISTS
(
SELECT stge_rec_err_ind
FROM #tdcam_t TT
WHERE TT.num_pol_dcrt = dcam_t.num_pol_dcrt
)
SELECT @.vErrNum = @.@.ERROR, @.vUpdtRecCount = @.@.ROWCOUNT, @.vStatrcTblNm =
'dcam_t'
IF @.vErrNum <> 0
BEGIN
SELECT @.vErrLocNm = 'cannot update dcam_t',
@.vErrTblNm = 'dcam_t',
@.vStatDsc = 'procedure failed'
GOTO ON_ERROR
END|||Non-existing Tables are not schema validated. If the parser notifies a
table which exists the columns are checked for existence, but not if
the table isn=B4t present during compilation time (like in your case)
CREATE PROCEDURE Testproc
AS
BEGIN
CREATE TABLE #testtable
(
SomeColumn int
)
Select somenotexsitingcolumn from #testtable
END
--VS
CREATE TABLE testtable
(
SomeColumn int
)
CREATE PROCEDURE Testproc2
AS
BEGIN
Select somenotexsitingcolumn from testtable
END
HTH, Jens Suessmeyer.|||The OP also states there are no errors at execution.
ML|||Hi,
The error is not raised because during compilation the temporary table does
not exist and SQL Server defers examination of the statement until run-time.
@.vIsrtRecCount > 0
is always false and so the code is never entered. If
@.vIsrtRecCount > 0
is true, the error 'Invalid column name' occurs.
Thanks to all who replied.

Introducing (NOLOCK) into production code for Selects

I have a large application that is multi-user and quite transactional,
driven by a VB
front end. It uses mostly stored procedures for retrieving data. I was
running into locking
contention on tables with 300,000 to 2 million records that are read and
updated by all users.
We allow the users to see the top 1000 rows from a table in "browse" mode in
VB (as a disconnected recordset), from which they can select a single record
to edit and update (also disconnected during editing).
I have read in Kalens book that we should use a lock hint for our Selects
(NOLOCK). But the only example given is like this:
SELECT <field list> FROM <table> (NOLOCK) WHERE .......
This is followed by the explanation that any Lock Hint needs to be wrapped
in a BEGIN TRAN/COMMIT.
Or IMPLICIT_TRANSACTIONS must be set on.
My application has thousands of lines of code, and the implications of
IMPLICIT_TRANSACTIONS seem quite capable of causing breakage in a production
app.
Can a simple Select issue a NOLOCK without being wrapped in an explicit
transaction?
I am trying to find an easy way to modify hundreds of stored procs that
retrieve data just for browsing without creating a Shared Lock. Most of the
parameterized Procs do some decision making before issuing a single Select.
For example (abbreviated to save space)
If @.Account_Type = 'P'
Select <some fields> from <view>
Else
Select <other fields> from <view>
Which begs another question, can NOLOCK be used when selecting from a view?
As in:
If @.Account_Type = 'P'
Select <some fields> from <view> (NOLOCK)
Else
Select <other fields> from <view> (NOLOCK)
Thanks for your input.On Fri, 11 Nov 2005 21:15:11 -0500, "jkotuby" <jkotuby@.snet.net>
wrote:
>Can a simple Select issue a NOLOCK without being wrapped in an explicit
>transaction?
Yes.
What Kalen says about lock hints in transactions (I don't have her
book here) may hold for locks, but doesn't apply to nolocks!
I've seen tons of production code done the way you want.
Not sure I approve of it, but it does what it does.
J.|||As I stated in an earlier post, NOLOCK will make your queries return
incorrect results at lightning speed. You must weigh the risk of returning
wrong answers against the performance benefits. Don't use it if the results
will be used in an INSERT or UPDATE.
"jkotuby" <jkotuby@.snet.net> wrote in message
news:OaQvt7y5FHA.1276@.TK2MSFTNGP09.phx.gbl...
> I have a large application that is multi-user and quite transactional,
> driven by a VB
> front end. It uses mostly stored procedures for retrieving data. I was
> running into locking
> contention on tables with 300,000 to 2 million records that are read and
> updated by all users.
> We allow the users to see the top 1000 rows from a table in "browse" mode
> in
> VB (as a disconnected recordset), from which they can select a single
> record
> to edit and update (also disconnected during editing).
> I have read in Kalens book that we should use a lock hint for our Selects
> (NOLOCK). But the only example given is like this:
> SELECT <field list> FROM <table> (NOLOCK) WHERE .......
> This is followed by the explanation that any Lock Hint needs to be wrapped
> in a BEGIN TRAN/COMMIT.
> Or IMPLICIT_TRANSACTIONS must be set on.
> My application has thousands of lines of code, and the implications of
> IMPLICIT_TRANSACTIONS seem quite capable of causing breakage in a
> production
> app.
> Can a simple Select issue a NOLOCK without being wrapped in an explicit
> transaction?
> I am trying to find an easy way to modify hundreds of stored procs that
> retrieve data just for browsing without creating a Shared Lock. Most of
> the
> parameterized Procs do some decision making before issuing a single
> Select.
> For example (abbreviated to save space)
> If @.Account_Type = 'P'
> Select <some fields> from <view>
> Else
> Select <other fields> from <view>
> Which begs another question, can NOLOCK be used when selecting from a
> view? As in:
>
> If @.Account_Type = 'P'
> Select <some fields> from <view> (NOLOCK)
> Else
> Select <other fields> from <view> (NOLOCK)
>
> Thanks for your input.
>|||Locking hints in general are not required to be wrapped in a transaction.
Some hints may require a transaction to get the desired overall result.
These would be things that need to hold the lock for the duration of or
across several statements. But NOLOCK is not one of them. The correct way
to use it would be to include the previously optional WITH as shown:
SELECT * FROM Table WITH (NOLOCK)
Just be aware that using NOLOCK will potentially give you dirty reads. If
that is OK for your application then fine but be aware of what implications
it may have. Reads in general are compatible with there reads. So if you
are being blocked a lot you may have transactions open for too long a period
of time and see what you can do to reduce that. A lack of proper indexes
will increase the time it takes for a DML operation along with the number of
rows affected.
Andrew J. Kelly SQL MVP
"jkotuby" <jkotuby@.snet.net> wrote in message
news:OaQvt7y5FHA.1276@.TK2MSFTNGP09.phx.gbl...
> I have a large application that is multi-user and quite transactional,
> driven by a VB
> front end. It uses mostly stored procedures for retrieving data. I was
> running into locking
> contention on tables with 300,000 to 2 million records that are read and
> updated by all users.
> We allow the users to see the top 1000 rows from a table in "browse" mode
> in
> VB (as a disconnected recordset), from which they can select a single
> record
> to edit and update (also disconnected during editing).
> I have read in Kalens book that we should use a lock hint for our Selects
> (NOLOCK). But the only example given is like this:
> SELECT <field list> FROM <table> (NOLOCK) WHERE .......
> This is followed by the explanation that any Lock Hint needs to be wrapped
> in a BEGIN TRAN/COMMIT.
> Or IMPLICIT_TRANSACTIONS must be set on.
> My application has thousands of lines of code, and the implications of
> IMPLICIT_TRANSACTIONS seem quite capable of causing breakage in a
> production
> app.
> Can a simple Select issue a NOLOCK without being wrapped in an explicit
> transaction?
> I am trying to find an easy way to modify hundreds of stored procs that
> retrieve data just for browsing without creating a Shared Lock. Most of
> the
> parameterized Procs do some decision making before issuing a single
> Select.
> For example (abbreviated to save space)
> If @.Account_Type = 'P'
> Select <some fields> from <view>
> Else
> Select <other fields> from <view>
> Which begs another question, can NOLOCK be used when selecting from a
> view? As in:
>
> If @.Account_Type = 'P'
> Select <some fields> from <view> (NOLOCK)
> Else
> Select <other fields> from <view> (NOLOCK)
>
> Thanks for your input.
>