Showing posts with label experience. Show all posts
Showing posts with label experience. Show all posts

Monday, March 26, 2012

Outer Join syntax

I am now working on SQL Server 2000 having had previous experience on
a different database. Both of the OUTER JOIN syntaxes is different
from what I am used to and I am finding it slightly confusing.

For example, given two tables :

wipm_tbl_mi
wipm_tbl_wi (which may not have data in it for a specific record that
exists in the first table.)

If I use the old style syntax :

SELECT mi.workitemid, wi.datavalue
FROM wipm_tbl_mi mi , wipm_tbl_wi wi
WHERE mi.workitemid *= wi.workitemid
AND mi.workitemid = 1
AND wi.dataname = 'XXX'

I get back

1,NULL

when there is no matching record in wipm_tbl_wi, which is what I
expect.

However, if I try to use the SQL-92 syntax

SELECT mi.workitemid, wi.datavalue
FROM wipm_tbl_mi mi
LEFT OUTER JOIN wipm_tbl_wi wi
ON mi.workitemid = wi.workitemid
WHERE mi.workitemid = 1
AND wi.dataname = 'XXX'

I don't get anything back. Please can someone help me understand what
is wrong with the bottom query.

Thank you,

Martin"Martin" <cook_ml@.hotmail.com> wrote in message
news:ac63e8cd.0401300807.25d1f38f@.posting.google.c om...
> I am now working on SQL Server 2000 having had previous experience on
> a different database. Both of the OUTER JOIN syntaxes is different
> from what I am used to and I am finding it slightly confusing.
> For example, given two tables :
> wipm_tbl_mi
> wipm_tbl_wi (which may not have data in it for a specific record that
> exists in the first table.)
> If I use the old style syntax :
> SELECT mi.workitemid, wi.datavalue
> FROM wipm_tbl_mi mi , wipm_tbl_wi wi
> WHERE mi.workitemid *= wi.workitemid
> AND mi.workitemid = 1
> AND wi.dataname = 'XXX'
> I get back
> 1,NULL
> when there is no matching record in wipm_tbl_wi, which is what I
> expect.
> However, if I try to use the SQL-92 syntax
> SELECT mi.workitemid, wi.datavalue
> FROM wipm_tbl_mi mi
> LEFT OUTER JOIN wipm_tbl_wi wi
> ON mi.workitemid = wi.workitemid
> WHERE mi.workitemid = 1
> AND wi.dataname = 'XXX'
> I don't get anything back. Please can someone help me understand what
> is wrong with the bottom query.
> Thank you,
> Martin

*= is the obsolete proprietary syntax used for outer joins by SQL Server
prior to version 6.5. OUTER JOIN is the Standard SQL way of doing
outer joins and should always be used. However, it's not simply syntactically
different but semantically different than *=. With outer joins, the join condition
must be evaluated separate from the condition applied to the rows resulting
from the join. The Standard SQL solution allows for this by being able to
specifiy the join condition for the outer join in the FROM clause and
the condition to be applied to the resulting rows of the outer join in the
WHERE clause. The *= syntax at best doesn't make this clear and at
worst won't allow you to specify the result you're looking for since both
kinds of conditions, for the join and the restriction of subsequent rows,
are specified in the WHERE clause.

It's always helpful to provide sample data in the form of INSERT
statements so a proposed solution can be tested, but try

SELECT mi.workitemid, wi.datavalue
FROM wipm_tbl_mi mi
LEFT OUTER JOIN
wipm_tbl_wi wi
ON mi.workitemid = wi.workitemid AND
wi.dataname = 'XXX'
WHERE mi.workitemid = 1

From the LEFT OUTER JOIN condition, every row of mi will be joined to
all rows in wi where mi.workitemid = wi.workitemid and wi.dataname = 'XXX'.
All rows of mi that don't satisfy this condition are joined to a single row
of all NULL values to indicate that there's no matching row from wi.
From the resulting outer join, the WHERE clause only keeps those rows
where mi.workitemid = 1. This will keep rows where wi.dataname is 'XXX'
or NULL, which is your desired result.

Regards,
jag|||Thank-you, Jag. Your explanation has helped me understand the general
point, and your suggested SQL has solved my specific problem.

Martin

Wednesday, March 7, 2012

osql batch processing without -i

Hi,
I have just started using MSSQL and the DOS environment at work. I have
a lot of experience with Sybase and the UNIX environment, but this is a
whole new ball of wax.
I'd like to use osql from a batch file to log into the dataserver and
run a fairly long list of SQL and then exit. I don't want to have a bunch
of SQL files sitting around that I have to use the -i option to run, and
I'd rather not create temporary SQL files like this.

echo "exec sp_who2" >tmp.sql
echo "select * from...... " >>tmp.sql
osql -E -S <DATASERVER> -n -w999 -i tmp.sql
del tmp.sql

I can't use the -Q option, of course because as I said, I'll be writing
quite a few lines of SQL, and it won't all fit on the one line, or at least
it wouldn't be pretty if I did.

In UNIX, I can simply execute the following from either the command line
or in
a script.

isql -S<DATASERVER> -U<USER> <<-EOF

sp_who
go
select * from ....
go
EOF --EOF is the isql session terminator exits me back to the command line.

This behavior does not appear to work with OSQL. There is a -O option
which help mentions, and that talks about disabling the EOF terminator for
batch processing, but I wasn't able to find any usage or examples on the net
where someone is using EOF to terminate their OSQL SQL batch.

This is what help listed.
[-O use Old ISQL behavior disables the following]
<EOF> batch processing
Auto console width scaling
Wide messages
default errorlevel is -1 vs 1

Any help you could offer would be appreciated. Thanks.

DarrenOn Mon, 16 Jan 2006 18:44:19 -0600, <dphillip79@.comcast.net> wrote:

(snip)
> In UNIX, I can simply execute the following from either the command line
>or in
>a script.
>isql -S<DATASERVER> -U<USER> <<-EOF
>sp_who
>go
>select * from ....
>go
>EOF --EOF is the isql session terminator exits me back to the command line.
> This behavior does not appear to work with OSQL.

Hi,

It's not OSQL, it's Windows/DOS that is causing the difference. In UNIX,
utilities take their input from STDIN, which is either the next line in
the script (if run from a script) or the next line entered on the
console (if run from a console).

The same thing happens if you create a script (testme.bat) with the
following content:

copy con test.txt
This won't work

Execute it. The copy con command is started and the console will wait
for your input. Type one or more lines, then type Ctrl-Z (the EOF
marker). You'll next see an error because "Thins won't work" is not a
valid DOS command.

An equivalent script in Unix would enter "This won't work" in the file
test.txt.

> Any help you could offer would be appreciated.

I think that you'll have to settle for either a bunch of commonly used
SQL script files, or for dynamically building the SQL script using a
bunch of redirected echo statements.

--
Hugo Kornelis, SQL Server MVP|||"Hugo Kornelis" <hugo@.perFact.REMOVETHIS.info> wrote in message
news:raiqs1pfephh7faud9sesnjot56c7tdng9@.4ax.com...
> On Mon, 16 Jan 2006 18:44:19 -0600, <dphillip79@.comcast.net> wrote:
> (snip)
> > In UNIX, I can simply execute the following from either the command
line
> >or in
> >a script.
> >isql -S<DATASERVER> -U<USER> <<-EOF
> >sp_who
> >go
> >select * from ....
> >go
> >EOF --EOF is the isql session terminator exits me back to the command
line.
> > This behavior does not appear to work with OSQL.
> Hi,
> It's not OSQL, it's Windows/DOS that is causing the difference. In UNIX,
> utilities take their input from STDIN, which is either the next line in
> the script (if run from a script) or the next line entered on the
> console (if run from a console).
> The same thing happens if you create a script (testme.bat) with the
> following content:
> copy con test.txt
> This won't work
> Execute it. The copy con command is started and the console will wait
> for your input. Type one or more lines, then type Ctrl-Z (the EOF
> marker). You'll next see an error because "Thins won't work" is not a
> valid DOS command.
> An equivalent script in Unix would enter "This won't work" in the file
> test.txt.
> > Any help you could offer would be appreciated.
> I think that you'll have to settle for either a bunch of commonly used
> SQL script files, or for dynamically building the SQL script using a
> bunch of redirected echo statements.

Thanks for the Info Hugo. I was afraid of that. I'm used being able to
do whatever I want in UNIX, so DOS seems to be a bit of a step back for me.
I did just download a version of sed for DOS, which I'm really excited
about. :) I also have a VB .net class next week, so I'm hoping to pick up
some tricks in there. Thanks again.

Darren

> --
> Hugo Kornelis, SQL Server MVP