It often happens when reading bulk information that dates get treated as text to minimise the amount of conversion errors on the import. I have seen a lot of intricate algorythms to verify the validity of such a string as a date. I have seen people cutting it up by explicitly searching for the separator, storing each part in a different variable, rearranging those variables and then convert the amalgamated strings into a new string which, hopefully, yields a date. I've seen code where the dates get split up, stuck in a table and then rearranged with selects. I believe there is an easier way which simply reads as follows.

 
SET dateformat dmy
 
SELECT 'It''s a date, cap''n!'
FROM tblImport
WHERE ISDATE(someDateField) = 1
 

By using "set dateformat dmy", we tell SQL Server to analyse any possible date by assuming that first part of any date is the day of month, the second is the month and the last part is the year. There are drawbacks, however. You must use either a hyphen or a slash as a separator. You cannot use concatenated date strings or other separators such as periods or blanks.

Still, for us in continental Western-Europe, this solves a lot of problems when reading from bulk imports.

---

 
IF @pCode = 'AA' or @pCode = 'AB' or @pCode = 'BA' or @pCode = 'XY'
	SET @actionType = 'single'
ELSE
	SET @actionType = 'combined'
 

You can recode this to SQL to make it more readable.

The second option will be slower - about four times slower - but on my stone-age development system, it still performed 20000 iterations in under 200ms. That's 100000 comparisons per second.

 
SELECT
	@actionType = 'combined'
 
SELECT
	@actionType = 'single'
WHERE
	@pCode in
		(
			'AA',
			'AB',
			'BA',
			'XY'
		)
 

---