|
|
Posted by Carsten on 07/23/07 12:56
Thanks a lot guys,
I followed your notes with great interest.
What I will take from this is that you people, who (probably) are more
experienced than me on the SQL server technology, confirmed this
behaviour and agree with me that is not documented.
In order to embed these nested calls most elegantly into my queries I
really needed it the way I had it planned but I'm sure I will find a
suitable workaround. I'll keep the remarks on cost in mind, thank you
very much.
The thing is that these and other similar subqueries occur quite often
in my code base. My code base consist of hundreds of procs, some of
them used by some application modules, some of them used by reporting
modules, some of them probably not used at all...;-) Also this
codebase is a good few years old and had many different people working
it. So between all these hundreds of procs these subqueries are often
implemented differently (just a bit) which not only accounts for
undesired non-matching results (between different modules of the
application/reports) but this also makes the codebase difficult to
maintain. So my idea is to put these reoccuring blocks of inner joins
(thats what they are in my real world) into functions to make sure
that all the procs, all the applications logic retrieves - say-
transactions for a given quarter in the very same way. As I said there
is similar stuff on other tables and joins in my code and I was hoping
that once I found a suitbale way of replacing such stuff I could
consolidate the codebase entirely.
This has been very helpful nonetheless and I'm sure I'll find a way
around this. Thank you.
Carsten
Navigation:
[Reply to this message]
|