Oracle FAQ | Your Portal to the Oracle Knowledge Grid |
![]() |
![]() |
Home -> Community -> Usenet -> c.d.o.server -> Re: SQL Server 2005 - Still not upto it
You code adapted for SQL Server:
create table t(t_pk int not null primary key,name varchar(40));
create procedure invalid_proc AS
insert into t(wrong_column,wrong_column_again) values (1,'Arun');
Above fails with error:
Server: Msg 207, Level 16, State 1, Procedure invalid_proc, Line 2
Invalid column name 'wrong_column'.
-- Tibor Karaszi, SQL Server MVP http://www.karaszi.com/sqlserver/default.asp http://www.solidqualitylearning.com/ http://www.sqlug.se/ "Arun Mathur" <themathurs_at_gmail.com> wrote in message news:1111519291.575794.188420_at_f14g2000cwb.googlegroups.com...Received on Tue Mar 22 2005 - 13:36:01 CST
> Not trying to go off a tangent, but when I think SQL*Server, I remember
> the importance of semantics, as does Oracle. See my SQL*Plus session
> below::
>
> SQL> drop table t;
>
> Table dropped.
>
> SQL> create table t(t_pk number(11) not null primary key,name
> varchar2(40));
>
> Table created.
>
>
> SQL> create or replace procedure invalid_proc
> 2 is
> 3 begin
> 4 insert into t(wrong_column,wrong_column_again) values (1,'Arun');
> 5 end;
> 6 /
>
> Warning: Procedure created with compilation errors.
>
> SQL> show errors
> Errors for PROCEDURE INVALID_PROC:
>
> LINE/COL ERROR
> --------
> -----------------------------------------------------------------
> 4/1 PL/SQL: SQL Statement ignored
> 4/28 PL/SQL: ORA-00904: "WRONG_COLUMN_AGAIN": invalid identifier
>
> This behavior is expected. However, when I worked with SQL*Server a
> few years ago, it wouldn't check for semantics. So, the above procedure
> would actually compile in SQL*Server, and I wouldn't know this
> procedure is wrong until I call it.
>
> I posted my observation on one of Tom Kyte's useful discussions,
> http://asktom.oracle.com/pls/ask/f?p=4950:61:::::P61_ID:3512483632553
> , hoping someone would chime in and say "You're wrong. SQL*Server does
> check for semantics". Instead, someone posted
> saying this behavior still exists in SQL Server 2000.
>
> So, optimization aside, how about an engine that can compile?
>
> Regards,
> Arun
>
![]() |
![]() |