So when writing scripts to create tables you might often include some SQL like below to first assess whether or not the table exists before dropping it.
This might be because you are still testing data and want a table with a different structure to be created or to exist and be populated with different data while using the same table name. So it’s the right thing to do in that circumstance but you may be wrongly carrying that thinking forward into creating stored procedures and user defined functions.
By dropping an SP or UDF you are also breaking any securities or permissions associated with that SP or UDF meaning these permissions etc. will have to be created again.
But for SPs and UDFs you don’t actually need to drop the SP or UDF you just want to change it if it exists. In which case you use Alter rather than Create. However what if you are unaware as to whether the SP or UDF actually exists?
I propose creating dummy SP’s or UDF’s in their place which will simply be over written as demonstrated below.
Probably the best way to log whether your stored procedure ran correctly or threw an error during its run is to create another stored procedure to capture the events of the run.
This example although basic captures the primary data you would want to keep a record of regarding a procedures run.
- The name of the stored procedure
- The start time of the stored procedure
- The time the stored procedure finished/errored
- A user comment/error message
- An assigned Log ID
Below is a pre-baked example requiring just a change to the DatabaseName, and if you wish SP_Name, text fields, as instructed in the comments of the SQL below, to test run the script.
This will create a SP_Log table and the stored procedure InsertRunIntoSpLog which can be reused over and over again when making stored procedures for other jobs to log the success/failure of these jobs.
Step 3 is an example stored procedure, which can be renamed as something other than SP_Name, which simply displays the date time. Once created whenever the following is executed, EXEC dbo.SP_Name, the current date time will be returned and a record of the procedures run will be added to a row in the SP_Log table.
Although as stated above this is a basic example it is a very powerful foundation which can be built upon for very comprehensive event and transaction logging.
When a developer is asked to create a business report it always involves a meeting of two disciplines.
The developer has the technical knowledge of pulling raw data, manipulating it and presenting interpreted data as information to be consumed by an end user. They may also know the location and source of the data to be used and how regularly this source is refreshed or updated with new data.
The Requester of the report will usually be the person with business domain knowledge. They understand the business rules which need to be applied to the data to transform it into information.
An obvious example for this is the relationship between a SQL developer working in an accounting environment. The developer is not an account and the account is not a developer but the two need to be able to collaborate and communicate to ensure that a report eventually outputs the correct information at the require period reliably.
Failure in achieving this goal can have disastrous consequences. For example projecting further revenue based on faulty data.
A good start for creating a foundation for effective communication and collaboration is for the developer and requester to step through a requirements template. This gives the report a structure and focus while also serving as a means of documenting the creation of the report from a business perspective and a future resource from a development perspective, i.e. the requirement of a future developer new to the report updating and modifying the report.
Attached is an example Template.
The Requirements sheet deals with questions like:
Who is the requester?
Why is the report needed?
What information will the report return?
This sheet will primarily be filled in by the requester.
The Report Fields sheet tries to plug the gap in knowledge between the requester and the developer by exploring what is the information required and what fields, calculations correspond to this information. The developer and requester may need to step through this sheet together to ensure their intended outcomes align.
It’s common practice to set a database to UTC time. Coordinated Universal Time, abbreviated as UTC, is the primary time standard by which the world regulates clocks and time. For most purposes, UTC is considered interchangeable with GMT, but GMT is no longer precisely defined by the scientific community. If you don’t believe me then I refer you to the following link.
This creates problems however as UTC does not observe daylight saving time. So if you were to prepare a report regarding a company’s call data calls may show as having occurred at seven in the morning before offices had opened. When daylight savings is taken into account the calls actually occurred at eight.
SQL Server has no inbuilt conversion process to deal with this but a simple function can be created to deal with this as below.
My example deals with Ireland specifically. As countries differ in when they implement daylight savings if the company is not based in Ireland you will have to adjust the logic below to suit your needs.
I would recommend searching online and creating a table containing previous and future year values of daylight savings times and then plugging these values into the script below.