Originally posted by AtW
- Visitors can check out the Forum FAQ by clicking this link. You have to register before you can post: click the REGISTER link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. View our Forum Privacy Policy.
- Want to receive the latest contracting news and advice straight to your inbox? Sign up to the ContractorUK newsletter here. Every sign up will also be entered into a draw to WIN £100 Amazon vouchers!
Reply to: SQL Help with a simple Stored Procedure
Collapse
You are not logged in or you do not have permission to access this page. This could be due to one of several reasons:
- You are not logged in. If you are already registered, fill in the form below to log in, or follow the "Sign Up" link to register a new account.
- You may not have sufficient privileges to access this page. Are you trying to edit someone else's post, access administrative features or some other privileged system?
- If you are trying to post, the administrator may have disabled your account, or it may be awaiting activation.
Logging in...
Previously on "SQL Help with a simple Stored Procedure"
Collapse
-
It is a very bad practice to have such "spec" - if you don't know what columns you going to have, what's good for you to select *?
Back to exile now!
Leave a comment:
-
get back to generalOriginally posted by AtWIt's a ver..blah zzzzzzzzzzzzzzzz
couldn't list the column names as they were not provided in the spec
Leave a comment:
-
It's a very bad practice too - in case of changes to table bugs may appear in code and re-compilation won't find them because you were doing select * rather than select specific columns.Originally posted by WeltchyLikewise, shame on both of you for using SELECT *. Thats lazy. Fieldnames please!!!!
Leave a comment:
-
Guessing at the execution plan that would come out for both SQL Statements, I'd hazard a guess that the first would probably suit a smaller table, record-wise, whilst the second would perform better with a large table, especially if that column had an index against it!!! The first statement would not make best use of an index on eventtype as its nested within a case statement.Originally posted by SpacecadetTsk, 4 selects when 1 will do
Likewise, shame on both of you for using SELECT *. Thats lazy. Fieldnames please!!!!
Leave a comment:
-
A BIG public THANK YOU is for all who have replied is required here Power to UKcontractor indeed
I know that we are all contractors who charge by the hour - but this is a personal private project that I working on and SQL is not really my area of expertise. So I appreciate the time and effort that people have given to help me out.
Often thanks is not given when help is required – but I am not that sort of person – so again many thanks for helping me out.
PS if you ever find yourselves in the Village of Rothey, Leicestershire – the beers ore on me down at the “Woodies”
Leave a comment:
-
I get paid by the hour!Originally posted by SpacecadetTsk, 4 selects when 1 will do
Leave a comment:
-
Or use UNION ALL to join simple selects:
HTHPHP Code:SELECT *
FROM eventsTable
WHERE @_hail = 1 and [eventType] = 'HAIL'
UNION ALL
SELECT *
FROM eventsTable
WHERE @_tornado = 1 and [eventType] = 'TORNADO'
UNION ALL
SELECT *
FROM eventsTable
WHERE @_funnel = 1 and [eventType] = 'FUNNEL'
UNION ALL
SELECT *
FROM eventsTable
WHERE @_downburst = 1 and [eventType] = 'DOWNBURST'
Leave a comment:
-
Rob, yours looks wrong , ANDs and ORs are mixed up
needs changing to this:
heres another way with less boolean:PHP Code:SELECT
*
FROM
eventsTable
WHERE
(
@_hail = 1
and
[eventType] = 'HAIL'
)
or
(
@_tornado = 1
and
[eventType] = 'TORNADO'
)
etc...
PHP Code:SELECT * from eventsTable
WHERE
[eventType] = case when @_hail =1 then 'HAIL' else 'NO MATCH' end
or [eventType] = case when @_tornado =1 then 'TORNADO' else 'NO MATCH' end
or [eventType] = case when @_funnel =1 then 'FUNNEL' else 'NO MATCH' end
or [eventType] = case when @_downburt =1 then 'DOWNBURT' else 'NO MATCH' end
Last edited by Spacecadet; 8 May 2007, 12:22.
Leave a comment:
-
SQL Help with a simple Stored Procedure
This should be basic – but it driving me nuts on how to do it so any help would be much appreciated.
I have a column that contains [eventType] as follows
HAIL
TORNADO
FUNNEL
DOWNBURST
I want to pass to the Proc parameters to filter on [eventType] depending on weather check boxes on the web page are selected.
EXEC MyProc @_hail =1, @_tornado =1, @_ funnel=0, @ _downburt=0
MyProc
@_hail BIT,
@_tornado BIT,
@_ funnel BIT,
@ _downburt BIT
SELECT * from eventsTable
WHERE [eventType] = HAIL
OR [eventType] = TORNADO
I am not sure how to do the dynamic WHERE clause.Tags: None
- Home
- News & Features
- First Timers
- IR35 / S660 / BN66
- Employee Benefit Trusts
- Agency Workers Regulations
- MSC Legislation
- Limited Companies
- Dividends
- Umbrella Company
- VAT / Flat Rate VAT
- Job News & Guides
- Money News & Guides
- Guide to Contracts
- Successful Contracting
- Contracting Overseas
- Contractor Calculators
- MVL
- Contractor Expenses
Advertisers
Contractor Services
CUK News
- Umbrella company winding-up petitions in 2026: the practical guide for contractors Today 05:29
- Payments on Account deadline: what contractors must do before July 31st — maybe for the final few times Yesterday 08:01
- Andy Burnham's first 100 days: five things contractors need from the new PM Jul 27 00:53
- Starmer vs Burnham on housing: What their rival plans mean for your contractor mortgage Jul 22 00:59
- Burnham's housing vision vs. Starmer's home-buying reforms: what it means for your contractor mortgage Jul 22 00:59
- In Khalil v Innovate Transport, a limited company contractor wasn’t a worker and was on £2.30 — not £230 Jul 21 07:58
- Andy Burnham is PM: 5 new IT policies set to shape UK tech and its contractors Jul 20 06:29
- Taxed on money I haven't earned yet? Bold move, HMRC Jul 17 08:36
- The Fair Work Agency has got zero hours in its sights. Do you? Jul 16 08:44
- Cookie Policy Jul 15 11:50

Leave a comment: