The perils of stubbing out methods
I only have a single-thread brain. Sad, but true. I can only really concentrate on one thing at a time.
For example, when I'm writing, I like to stub out sections of code so I can some back and flesh them out when I've finished something else. Take thei example of some code in process:
Public Function GetString(AllTheString as Boolean) as String
If AllTheString Then
Return "You asked for all the string"
Else
'Add the 'Not-All-The-String' in a minute.
'Why not make a coffee?
End If
You get the point. I can deal with the other path the code can take at some point in time. Perhaps after a coffee. However, this approach doesn't work in SQL Server 2000. I'm sure it's well documented and whatnot, but it really did give me some grief earlier today. Take this example:
CREATE PROCEDURE ThisIsATest
(@TestValue int)
AS
IF EXISTS(SELECT TheKey FROM TheTable WHERE TheKey = @TestValue
BEGIN
INSERT INTO AuditTable(Event, Time)
VALUES ('This value was found: ' + @TestValue, GETDATE())
END
ELSE
BEGIN
/*I'll worry about this part in a minute
I quite feel like a coffee roundabout now...*/
END
Hit the 'Validate SQL' button, and it'll return an error. A nice error? A helpful error? An error that might vaguely suggest that you might have a code path that doesn't actually so anything? No. What does it come back with?
Incorrect syntax near the keyword 'END'
Pointing at the last line of the script.
Took me ages of sifting through a long SPROC before I realised that was what it was trying to tell me. Bugger. All I was trying to dso was vlidate the SQL I had writen so I could move on to the other part.
Just wanted to share. Apologies for irrelevance and brevity, but it's late. All because of this very thing!
No comments:
Post a Comment