Parse Identifier

hi
how can i configure the SQL server & inforce to parse & excute ONLY if he
found an specific identifier, i.e: ;(semicolon)
within default SQL server configurations one space is enough to seperate
between statement while parsing & excuting.
examples:
* current situation:
select * from t1 select * from t2 -- it will consider two statements &
excute both
* I need something like this:
select * from t1 select * from t2; -- it will give error , it will consider
it as one statement
any help '> * I need something like this:
> select * from t1 select * from t2; -- it will give error , it will
> consider
> it as one statement
The SQL parser is not configurable like this. Semi-colons are optional
statement delimiters (in most cases).
May I ask why you have this need?
Hope this helps.
Dan Guzman
SQL Server MVP
"Bashar Naffa" <BasharNaffa@.discussions.microsoft.com> wrote in message
news:BE4B5FDD-3963-4B3E-8400-6E8E9008A8CB@.microsoft.com...
> hi
> how can i configure the SQL server & inforce to parse & excute ONLY if he
> found an specific identifier, i.e: ;(semicolon)
> within default SQL server configurations one space is enough to seperate
> between statement while parsing & excuting.
> examples:
> * current situation:
> select * from t1 select * from t2 -- it will consider two statements &
> excute both
> * I need something like this:
> select * from t1 select * from t2; -- it will give error , it will
> consider
> it as one statement
> any help '|||Hi Dan,
let's say we have aready an legacy development framework, which allow the
user/developer build the criteria completely [ not paramterized value] n
o he
can build complete sql criteria & the framework attach this criteria to the
original sql statemnt & excute on SQL server.
what are we trying to do is to prevent any additional sql statement that may
run after the original one [ prevent sql injection] . we can't control t
he
the coming values. we just recieve sql criterias. so i'm trying to depend on
the delimiter to excute this statement as one statment & for sure get SQL
error instead of escuting it.
it's little bit messy, but again this legacy system
"Dan Guzman" wrote:

> The SQL parser is not configurable like this. Semi-colons are optional
> statement delimiters (in most cases).
> May I ask why you have this need?
> --
> Hope this helps.
> Dan Guzman
> SQL Server MVP
> "Bashar Naffa" <BasharNaffa@.discussions.microsoft.com> wrote in message
> news:BE4B5FDD-3963-4B3E-8400-6E8E9008A8CB@.microsoft.com...
>|||SQL Server will always allow multi-statement batches regardless of how
individual statements are terminated. Aside from minimal permissions, there
isn't much that can be done on the server side to prevent SQL injection
since injection is essentially a client-side issue.
Hope this helps.
Dan Guzman
SQL Server MVP
"Bashar Naffa" <BasharNaffa@.discussions.microsoft.com> wrote in message
news:2D4E196C-DA3B-4278-AD6F-9C293EF9ADB6@.microsoft.com...[vbcol=seagreen]
> Hi Dan,
> let's say we have aready an legacy development framework, which allow the
> user/developer build the criteria completely [ not paramterized value]
no
> he
> can build complete sql criteria & the framework attach this criteria to
> the
> original sql statemnt & excute on SQL server.
> what are we trying to do is to prevent any additional sql statement that
> may
> run after the original one [ prevent sql injection] . we can't control
the
> the coming values. we just recieve sql criterias. so i'm trying to depend
> on
> the delimiter to excute this statement as one statment & for sure get SQL
> error instead of escuting it.
> it's little bit messy, but again this legacy system
>
> --
> "Dan Guzman" wrote:
>