Really strange behaviour concerning stored procedures

I have an application which comprises a VB6 client/server with a SQL
server back end. All the queries that the application uses are in
stored procedures which are initially created and occasionally
recreated by the application itself. The application does this by
building a CREATE PROCEDURE... SQL statement and then executing this
via the execute method of an ADO connection.
Any stored procs that involve 'Activities' are quite database intensive
as they use a view which is a multi-union view from lots of tables.
However, until now, once these stored procedures are compiled they run
pretty fast (typically 1 or 2 seconds).
Here's the problem (which has just started happening): when the
application creates (or recreates) a stored procedure involving
Activities, the query now takes about 10 seconds (instead of the
previous 1 or 2 seconds). However (and this is the really strange
part) when I get the procedure definition SQL from the stored proc and
execute it in Query Analyzer to recreate the SP, it creates a stored
proc that executes quickly (i.e. back to the 1 - 2 seconds of before).
This is consistent (to a point) - each time I rebuild a stored proc
through the application the SP executes slowly and each time I create
it via Query Analyzer it executes quickly. In addition to this (just
to complicate things further!) after I've been testing it repeatedly
for a while it sometimes starts behaving ok - i.e. the stored proc runs
fast all the time regardless of whether it is created via the
application or via Query Analyzer.
I have tried this on our development SQL server and on a local MSDE
instance and I have tried it with different copies of the database -
the problem occurs in all tests so it doesn't seem to be db or server
related. I've noticed that the execution plan differs depending on how
the stored proc is created so I guess this is what's causing the big
time difference but the question is why should it matter how the stored
proc is created? The data is unchanged between tests and the stored
procedure text is the same - the only thing that changes is how the SP
is created (i.e. my application or Query Analyzer).
I have been tearing my hair out on this - can anyone please offer a
suggestion that might assist?
IanRead up on the SQL Server "procedure cache" and see if this would play a
role in what you are observing. Using SQL Profiler, you can trace
SP:CacheMiss, SP:CacheHit and other cache related events to determine what
is going on behind the scenes when your SP is being created or executed.
<ian__@.hotmail.com> wrote in message
news:1116345172.130396.298070@.g44g2000cwa.googlegroups.com...
> I have an application which comprises a VB6 client/server with a SQL
> server back end. All the queries that the application uses are in
> stored procedures which are initially created and occasionally
> recreated by the application itself. The application does this by
> building a CREATE PROCEDURE... SQL statement and then executing this
> via the execute method of an ADO connection.
> Any stored procs that involve 'Activities' are quite database intensive
> as they use a view which is a multi-union view from lots of tables.
> However, until now, once these stored procedures are compiled they run
> pretty fast (typically 1 or 2 seconds).
> Here's the problem (which has just started happening): when the
> application creates (or recreates) a stored procedure involving
> Activities, the query now takes about 10 seconds (instead of the
> previous 1 or 2 seconds). However (and this is the really strange
> part) when I get the procedure definition SQL from the stored proc and
> execute it in Query Analyzer to recreate the SP, it creates a stored
> proc that executes quickly (i.e. back to the 1 - 2 seconds of before).
> This is consistent (to a point) - each time I rebuild a stored proc
> through the application the SP executes slowly and each time I create
> it via Query Analyzer it executes quickly. In addition to this (just
> to complicate things further!) after I've been testing it repeatedly
> for a while it sometimes starts behaving ok - i.e. the stored proc runs
> fast all the time regardless of whether it is created via the
> application or via Query Analyzer.
> I have tried this on our development SQL server and on a local MSDE
> instance and I have tried it with different copies of the database -
> the problem occurs in all tests so it doesn't seem to be db or server
> related. I've noticed that the execution plan differs depending on how
> the stored proc is created so I guess this is what's causing the big
> time difference but the question is why should it matter how the stored
> proc is created? The data is unchanged between tests and the stored
> procedure text is the same - the only thing that changes is how the SP
> is created (i.e. my application or Query Analyzer).
> I have been tearing my hair out on this - can anyone please offer a
> suggestion that might assist?
> Ian
>|||Hi
Why do you need to re-create the stored procedures all the time? Usually
stored procedures are static code and you just change the values of the
parameters passed to them!
John
"ian__@.hotmail.com" wrote:

> I have an application which comprises a VB6 client/server with a SQL
> server back end. All the queries that the application uses are in
> stored procedures which are initially created and occasionally
> recreated by the application itself. The application does this by
> building a CREATE PROCEDURE... SQL statement and then executing this
> via the execute method of an ADO connection.
> Any stored procs that involve 'Activities' are quite database intensive
> as they use a view which is a multi-union view from lots of tables.
> However, until now, once these stored procedures are compiled they run
> pretty fast (typically 1 or 2 seconds).
> Here's the problem (which has just started happening): when the
> application creates (or recreates) a stored procedure involving
> Activities, the query now takes about 10 seconds (instead of the
> previous 1 or 2 seconds). However (and this is the really strange
> part) when I get the procedure definition SQL from the stored proc and
> execute it in Query Analyzer to recreate the SP, it creates a stored
> proc that executes quickly (i.e. back to the 1 - 2 seconds of before).
> This is consistent (to a point) - each time I rebuild a stored proc
> through the application the SP executes slowly and each time I create
> it via Query Analyzer it executes quickly. In addition to this (just
> to complicate things further!) after I've been testing it repeatedly
> for a while it sometimes starts behaving ok - i.e. the stored proc runs
> fast all the time regardless of whether it is created via the
> application or via Query Analyzer.
> I have tried this on our development SQL server and on a local MSDE
> instance and I have tried it with different copies of the database -
> the problem occurs in all tests so it doesn't seem to be db or server
> related. I've noticed that the execution plan differs depending on how
> the stored proc is created so I guess this is what's causing the big
> time difference but the question is why should it matter how the stored
> proc is created? The data is unchanged between tests and the stored
> procedure text is the same - the only thing that changes is how the SP
> is created (i.e. my application or Query Analyzer).
> I have been tearing my hair out on this - can anyone please offer a
> suggestion that might assist?
> Ian
>|||Are them being created with the same schema or owner in both cases (app and
QA)?
AMB
"ian__@.hotmail.com" wrote:

> I have an application which comprises a VB6 client/server with a SQL
> server back end. All the queries that the application uses are in
> stored procedures which are initially created and occasionally
> recreated by the application itself. The application does this by
> building a CREATE PROCEDURE... SQL statement and then executing this
> via the execute method of an ADO connection.
> Any stored procs that involve 'Activities' are quite database intensive
> as they use a view which is a multi-union view from lots of tables.
> However, until now, once these stored procedures are compiled they run
> pretty fast (typically 1 or 2 seconds).
> Here's the problem (which has just started happening): when the
> application creates (or recreates) a stored procedure involving
> Activities, the query now takes about 10 seconds (instead of the
> previous 1 or 2 seconds). However (and this is the really strange
> part) when I get the procedure definition SQL from the stored proc and
> execute it in Query Analyzer to recreate the SP, it creates a stored
> proc that executes quickly (i.e. back to the 1 - 2 seconds of before).
> This is consistent (to a point) - each time I rebuild a stored proc
> through the application the SP executes slowly and each time I create
> it via Query Analyzer it executes quickly. In addition to this (just
> to complicate things further!) after I've been testing it repeatedly
> for a while it sometimes starts behaving ok - i.e. the stored proc runs
> fast all the time regardless of whether it is created via the
> application or via Query Analyzer.
> I have tried this on our development SQL server and on a local MSDE
> instance and I have tried it with different copies of the database -
> the problem occurs in all tests so it doesn't seem to be db or server
> related. I've noticed that the execution plan differs depending on how
> the stored proc is created so I guess this is what's causing the big
> time difference but the question is why should it matter how the stored
> proc is created? The data is unchanged between tests and the stored
> procedure text is the same - the only thing that changes is how the SP
> is created (i.e. my application or Query Analyzer).
> I have been tearing my hair out on this - can anyone please offer a
> suggestion that might assist?
> Ian
>|||>> All the queries that the application uses are in stored procedures
which are initially created and occasionally recreated by the
application itself. The application does this by building a CREATE
PROCEDURE... SQL statement and then executing this via the execute
method of an ADO connection. <<
So you are such a bad SQL programmer that a random front end user
should be able to re-arrange the database. How did you expect to have
any data integrity?
If you had followed basic software engineering principles, the stored
procedures would be written, controlled and executed in the database
and not by the front end. This has nothing to do with SQL. This is
the foundations of all programming.
You need to start over, get a book on basic software engineering and
re-write what you have. As a rule of thumb, when you have "a
multi-union view from lots of tables", you usually have serious schema
design flaws.
Read about procedure casches, too. That is why dynamic things vary in
speed.|||On 17 May 2005 08:52:52 -0700, ian__@.hotmail.com wrote:
(snip)
>I have been tearing my hair out on this - can anyone please offer a
>suggestion that might assist?
Hi Ian,
First, let me state that I fully agree with the doubts expressed by John
Bell and Joe Celko regarding your design. I also agree with the possible
causes brought forward by JT and Alejandro Mesa.
But another possible explanation is this: check out the settings for the
options SET QUOTED_IDENTIFIER and SET ANSI_NULLS when creating the
procedure from QA or when creating it from ADO. These settings are saved
with the procedure when it's created (or rather: they are encoded into
the execution plan). A different value for one or both of these options
can result in a different execution plan.
Best, Hugo
--
(Remove _NO_ and _SPAM_ to get my e-mail address)|||Firstly, thanks to those who responded in a constructive and courteous
manner to my question - there's always a danger when posting that
small-minded individuals are going to respond with a load of unhelpful
and ill-informed comments. I really don't know how people can post
spiteful criticism based on assumption!
For the record, the application is of an extremely sophisticated nature
and is designed to enable the end-users to create their own, very
complex and powerful queries using a comparatively simple user
interface. These queries are created as stored procedures as they do
not change often and are executed frequently. The application ensures
data integrity but perhaps the notion of such an advanced design is
beyond people like CELKO?
Ian|||Thanks and congrats to Hugo! ANSI_NULLS were on in QA and off in the
ADO connection. I have amended the application code to set on before
rebuilding the stored procedure and the problem is fixed - I'm very
happy!
The reason this only started happening was due to a recent patch where
ANSI_NULLS were set OFF - this was not explicitly set before that
patch.
CELKO, see what can happen when you try to be helpful?
Ian|||On 18 May 2005 01:08:36 -0700, ian__@.hotmail.com wrote:

>For the record, the application is of an extremely sophisticated nature
>and is designed to enable the end-users to create their own, very
>complex and powerful queries using a comparatively simple user
>interface. These queries are created as stored procedures as they do
>not change often and are executed frequently. The application ensures
>data integrity but perhaps the notion of such an advanced design is
>beyond people like CELKO?
Hi Ian,
Actually, I think that Joe Celko has seen enough designs like this, AND
the results from it to make him very wary of this design.
Of course, Joe only sees the cases that have gone wrong (you don't pay
his rates to review a database that appears to be working fine), and
your situation might well be an exception, but still...
If you're allowing end users to write queries, then how do you gaurd
against the risk of injection of bad code? What do you do to prevent
someone including "DELETE FROM Customers WHERE 1 = 1" or "SHUTDOWN WITH
NOWAIT" or "EXEC sp_addrolemember 'System Administrators', 'Jeff'"?
Also, how do you gaurd against queries that run for hours, bringing the
database to it's knees or holding locks for so long that all concurrency
is lost?
If your end users are all developers and can be trusted not to do silly,
stupid, or even malevolent things, then why don't you simply grant them
the rights to add stored procedures and views, or to execute ad-hoc
queries against the database?
If your end users don't fall into this category, then you should not
give them a way to do development work they're not qualifeid for.
As I said - your situation might well be the exception. Not all
situations where designs like this have been implemented have
experienced the unwanteed side effects. But many do. I do hope that
you'll take Joe Celko's warning to heart - and that you seriously
consider other options.
(Since the queries don't change often, I'd set up a change request
system where the end users write stored procedures, sent them to a
skilled DBA or developer for review, and the latter executed the CREATE
(or ALTER) PROCEDURE script if the query is okay, or proposes
improvements and discusses them with the submitter of the query.)
Best, Hugo
--
(Remove _NO_ and _SPAM_ to get my e-mail address)|||>> The application ensures data integrity but perhaps the notion of
such an advanced design is beyond people like CELKO? <<
LOL!! Of course you have always and will for the entire life of the
database, hire only *perfect* programmers. In the thousands and
thousands of lines of code they will write over time, nobody will
forget any business rules. Not one single rule! Amazing.
All the application code will use *exactly* the same algorithms. Never
mind that different programming languages use different truncation,
rounding, MOD() functions, string comparisons and so forth. The
perfect programmers will change the compilers or write their own
functions exactly the same way.
All third party packages will follow all of our business rules. How
they are going to do this when those rules are spread over thousands
and thousands of lines of application code, I don't know. Perhaps you
can tell me.
And when -- not if -- one of these integrity rules changes, the perfect
programmers will instantly propagate the changes in thousands and
thousands of lines of application code. And they will verify these
changes instantly.
And finally only perfect programmers will get to use QA or other tools
that go directly to the database without application code.
Advanced design? This is a return to a very primitive file systems
architecture. Talk to an old COBOL Programmer. The redundancy and
total lack of data integrity in those file systems are some of the
reasons we moved to DBMS and finally to RDBMS. You have re-discovered
1950's style ADP!

Really need help w/ what should be simple question!

Hello,

Basically, all I am trying to do is create an SSIS pkg that will read a list of stored procedures from a table. I set up an EXECUTE SQL TASK to do this. I am saving the result set to a variable (type object).

Next, I call a FOREACHLOOP container, which references the variable from the EXECUTE SQL TASK.

But I'm not sure what to do next? I just want the FOR EACH LOOP to simply execute the stored procedure name as given by the first EXECUTE SQL TASK.

I was thinking to put another EXECUTE SQL TASK inside the FOR EACH LOOP, but I don't know how to reference the stored procedure name correctly, or if this is even allowable.

I am not a scripter :-)

Can you please offer me some advice on what to do next? I am desperately seeking a solution.

Thank you!!!

In the Variable Mappings tab of your For Each container, make sure that you are mapping the necessary columns (like the stored proc name) of your resultset to variables.

Create a new variable to hold the call to the stored procedure. In the properties for the variable, make sure EvaluateAsExpression is true. In the Expression property, construct the string for a call to the stored proc, using the variables you mapped in the For Each container. Add an Execute SQL task in your For Each container, and set the SQLSourceType to variable. Then pick the variable you created as the SourceVariable.

If you wait a bit, I'll post an example on my blog.

|||

Example:

http://agilebi.com/cs/blogs/jwelch/archive/2007/03/21/using-for-each-to-iterate-a-resultset.aspx

The sample package is attached to the post.

Hope this helps.

|||

Hi John,

I looked *everywhere*, and I honestly don't see where to set "EvaluateAsExpression" is true. That is, where in the world do I set the properties for the variable in the FOREACH containter editor? I really don't see this anywhere.

I also looked at your example from your post, and I don't see this anywhere, either?

Thanks

|||

Hi John,

I examined your example very carefully. However, I don't know what you mean by the statement:

There is a variable named "select". This variable uses an expression to build the following select statement: "SELECT ID, ParentID, ChildName FROM ChildTable WHERE ParentID = " + the "parentID" variable. The "select" variable is then used in another Execute SQL task.

Where are you building the expression? I don't see it.

Thanks

|||Select the variable in the variables window (not in the container editor) and hit F4. This should bring up the properties for the variable. EvaluateAsExpression is an option in that window. This is also where the expression is defined.|||

Are you talking about the DataObjectVariable under EnumeratorProperties in the Properties of the ForEachLoop container?

I see my the name of my ADO Object Source Variable (User::Reports) , but not the mapped column (User::report_name) > which contains the name of the stored procedure.

But hitting F4 does not bring up anything.

?

Thanks

|||

I think I may be getting "closer", in spite of things probably not being set correctly at this point.

So far I have an EXEC SQL task >> FOREACHLOOP >> EXEC SQL task.

And it appears it is actually trying to RUN the stored procedure names. But I am getting this error. Do you think this has to do with my not setting the EvaluateAsExpression? Or something else? Thanks!

SSIS package "Migration - Run Report Comparison.dtsx" starting.

Error: 0xC002F210 at Execute SQL Task, Execute SQL Task: Executing the query "MY_STORED_PROC" failed with the following error: "Parameter name is unrecognized.". Possible failure reasons: Problems with the query, "ResultSet" property not set correctly, parameters not set correctly, or connection not established correctly.

Task failed: Execute SQL Task

Warning: 0x80019002 at Foreach Loop Container: SSIS Warning Code DTS_W_MAXIMUMERRORCOUNTREACHED. The Execution method succeeded, but the number of errors raised (1) reached the maximum allowed (1); resulting in failure. This occurs when the number of errors reaches the number specified in MaximumErrorCount. Change the MaximumErrorCount or fix the errors.

Warning: 0x80019002 at Migration - Run Report Comparison: SSIS Warning Code DTS_W_MAXIMUMERRORCOUNTREACHED. The Execution method succeeded, but the number of errors raised (1) reached the maximum allowed (1); resulting in failure. This occurs when the number of errors reaches the number specified in MaximumErrorCount. Change the MaximumErrorCount or fix the errors.

|||No, I'm talking about the window where you originally define the variable. On the menu bar for Visual Studio, choose SSIS..Variables, and you should see a list of variables defined in your package. You may need to click the "Show All Variables" button, as some variables may be scoped to specific items in the package.|||

Yes, I see it now, thanks so much for explaining this. I am very new to SSIS and packages in general.

So I set the variable which contains the stored procedure name EvaluateAsExpression as True.

However, I am still getting aforementioned error.

|||

Ha!

Figured it out. The devil is in the details as they say!

What was missing was that in the Parameter Mapping tab of the 2nd EXEC SQL TASK was that I needed to set the Parameter Name to 0.

I still don't fully understand the meaning of all the 0's, although I think it has something do with how OLEDB does things.

Anyhow, it's working... now onto step 2 - write outputs of sp's to name files.

Thanks again

Your example was very useful!!

|||

Could you mark the question as answered? Makes it easier for others to find answers for similar questions.

Thanks.

really large stored procedures

i'm not much of a sql developer, most of my exposure to it comes from
needing to get data for my web applications.
i've been kinda wondering, is it abnormal to have stored procs that are
over 500 lines long?
the business requirements seem to warrant such a long procedure and it
doesn't seem to have any absurd inefficiencies, but at the same time is
it very unusual?
in the object oriented world, this would be considered horrible style,
yet i can't really find any guidelines on the topic, so i thought i'd
ask.
TIAnot necessarily - in sql, typically it's the size of the statements, e.g.
select name from sysobjects where xtype='U'
and
select
name
from
sysobjects
where
xtype = 'U'
are the same statement, but one is 1 line and the other is 6 lines.
however, many statements often indicates that you've got a lot of
procedural code and not much relational (set-based) code.
in the oo world, you have no choice - e.g., if you want to update all
rows in a resultset to have the same StatusCode, you have to loop
through it and set it.
but in sql, you wouldn't need a cursor to do this -- you would just need
a single update statement, e.g.
update mytable
set status = 'P'
where <conditions>
so, the [well, my] answer is -- line count is not intrinsically
indicative of a bad proc. bad code is.
vortep@.gmail.com wrote:
> i'm not much of a sql developer, most of my exposure to it comes from
> needing to get data for my web applications.
> i've been kinda wondering, is it abnormal to have stored procs that are
> over 500 lines long?
> the business requirements seem to warrant such a long procedure and it
> doesn't seem to have any absurd inefficiencies, but at the same time is
> it very unusual?
> in the object oriented world, this would be considered horrible style,
> yet i can't really find any guidelines on the topic, so i thought i'd
> ask.
> TIA
>|||T-SQL is not object oriented, so 500 or more is very common. When I write a
SQL statement, I use a style that breaks each selected column onto a
seperate line (and I typically select a lot of columns when developing
reports or fact tables for OLAP cubes), so my procedures and views tend to
be 100s or even 1000s of lines becuase of this.
<vortep@.gmail.com> wrote in message
news:1136407727.493541.163990@.g44g2000cwa.googlegroups.com...
> i'm not much of a sql developer, most of my exposure to it comes from
> needing to get data for my web applications.
> i've been kinda wondering, is it abnormal to have stored procs that are
> over 500 lines long?
> the business requirements seem to warrant such a long procedure and it
> doesn't seem to have any absurd inefficiencies, but at the same time is
> it very unusual?
> in the object oriented world, this would be considered horrible style,
> yet i can't really find any guidelines on the topic, so i thought i'd
> ask.
> TIA
>|||vortep@.gmail.com wrote:
> i'm not much of a sql developer, most of my exposure to it comes from
> needing to get data for my web applications.
> i've been kinda wondering, is it abnormal to have stored procs that
> are over 500 lines long?
> the business requirements seem to warrant such a long procedure and it
> doesn't seem to have any absurd inefficiencies, but at the same time
> is it very unusual?
> in the object oriented world, this would be considered horrible style,
> yet i can't really find any guidelines on the topic, so i thought i'd
> ask.
> TIA
No. 500 lines is fine as long as you are not experiencing Recompiles or
allowing extended locks on tables during production hours. If you see
recompiles (SQL 2000), break out the code causing the recompile or
eliminate it if possible. SQL 2005 implements statement recompilation,
which eliminates most of the recompile overhead. In any case, recompiles
hurt performance, so eliminate them if possible. You can check for them
using Profiler and the SP:Recompile event (SQL 2000) and the
SQL:StmtRecompile for SQL 2005.
David Gugick
Quest Software
www.quest.com|||(vortep@.gmail.com) writes:
> i'm not much of a sql developer, most of my exposure to it comes from
> needing to get data for my web applications.
> i've been kinda wondering, is it abnormal to have stored procs that are
> over 500 lines long?
> the business requirements seem to warrant such a long procedure and it
> doesn't seem to have any absurd inefficiencies, but at the same time is
> it very unusual?
> in the object oriented world, this would be considered horrible style,
> yet i can't really find any guidelines on the topic, so i thought i'd
> ask.
A database is not an object-oriented world.
A 500-line stored procedure is not a small baby, but we have quite a
few of that size in our database. I think our longest is around 3000
lines.
Partly this is due to the fact that T-SQL is not well aimed of breaking
things into pieces. You can write procedures and pass parameters, but
these are scalar, and in SQL your rather work with tables. You can share
tables between stored procedures, but it is a bit kludgy.
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pr...oads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodin...ions/books.mspx|||Coming from an OO background I also wondered about the efficiencies of
large stored procs when transitioning to SQL Server development (as you
I had some exposure to it but from a front-end / middle-tier
perspective only).
I think that if you want to evaluate your stored proc and maybe
consider rewriting them you should definitly read up on set-based vs.
procedural. There's tons of info in this newsgroup for you to lap up in
any case.
regards,
Gerard|||From my own point of view is very common to have this kind of sp in a
production environment.
"Gerard" wrote:

> Coming from an OO background I also wondered about the efficiencies of
> large stored procs when transitioning to SQL Server development (as you
> I had some exposure to it but from a front-end / middle-tier
> perspective only).
> I think that if you want to evaluate your stored proc and maybe
> consider rewriting them you should definitly read up on set-based vs.
> procedural. There's tons of info in this newsgroup for you to lap up in
> any case.
> regards,
> Gerard
>|||Not at all abnormal. Bear in mind that in SQL, unlike in other
languages, there can be two reasons for a stored procedure being long:
a) Large number of statements
b) Large number of lines - long statements running over multiple lines.
Long statements are more common in SQL than in other languages due to
the sheer complexity of single SELECT statements, which may include a
long list of columns, references to multiple tables joined together,
and complex WHERE clauses. A long statement doesn't necessary mean a
long processing time, as long as joins are well-designed and tables are
indexed. Just switched windows to a stored procedure containing
multiple 80-line SQL statements - processing time is under a second.
The things to watch for for efficiency's sake are the things that SQL
Server is slow at: I've found that DELETE operations, and looping
through cursors are the worst for this.
Seb|||thanks guys,
i definately use one line for every "word" and don't use cursors unless
absolutely necessary
general format i use is
select
blah1,
blah2,
blah3
from
tablesmth
inner join
someothertable
on
somefield
=someotherfield
where
stuff
=stuff2
and
stuff3
=stuff4|||Line breaks are a renewable resource, so use them whereever you feel they
are useful.
<vortep@.gmail.com> wrote in message
news:1136488641.467676.117480@.z14g2000cwz.googlegroups.com...
> thanks guys,
> i definately use one line for every "word" and don't use cursors unless
> absolutely necessary
> general format i use is
> select
> blah1,
> blah2,
> blah3
> from
> tablesmth
> inner join
> someothertable
> on
> somefield
> =someotherfield
> where
> stuff
> =stuff2
> and
> stuff3
> =stuff4
>