Error handling in SQL Server breaks down into two very distinct situations: you’re handling errors because you’re in SQL Server 2005 or you’re not handling errors because you’re in SQL Server 2000. What’s worse, not all errors in SQL Server, either version, can be handled. I’ll specify where these types of errors come up in each version.<\/p>\n
The different types of error handling will be addressed in two different sections. ‘ll be using two different databases for the scripts as well, I’ve broken down the scripts and descriptions into sections. Here is a Table of Contents to allow you to quickly move to the piece of code you’re interested in. Each piece of code will lead with the server version on which it is being run. In this way you can find the section and the code you want quickly and easily.<\/p>\n As always, the intent is that you load this workbench into Query Analyser or Management Studio and try it out for yourself! The workbench script is available in the downloads at the bottom of the article. <\/p>\n <\/code><\/p>\n The error message provides several pieces of information: <\/p>\n The severity level of the error. <\/p>\n Error messages are defined and stored in the system table SQL Server 2000 does not allow us to stop this error being returned, but we can try to deal with it in some fashion. The core method for determining if a statement has an error in SQL Server 2000 is the If the value equals The following TSQL will result in the statement ‘A constraint error has occurred’ being printed,as well as the error.<\/p>\n You will see the error number as returned by the The problem is, while the In order to catch and keep these errors, you need to capture the Now we can capture the error number and refer to it as often as needed within the code. <\/p>\n While This allows us to finally begin to perform real error trapping.<\/p>\n While there is an error encountered in the code, none is returned to the calling function. In fact, all that will happen in this case is the string We have actually performed the function of error trapping within TSQL.<\/p>\n There are a number of issues around the use of Consider this example:<\/p>\n The second error is handled, but the first one is not and we would see this error returned to client application: <\/p>\n To eliminate this problem place multiple statements within the The To execute You also choose the severity of the error raised. Severity levels used in You can format the message to use variables. This makes it more useful for communicating errors:<\/p>\n You can use a variety of different variables. You simply have to declare them by data type and remember that, even with variables, you have a 400 character limit. You also have some formatting options. <\/p>\n A few notes about severity and status. Status can be any number up to 127 and you can make use of it on your client apps. Setting the Status to 127 will cause ISQL and OSQL to return the error number to the operating environment. <\/p>\n The function of Because of the new error handling capabilities, Stored procedures, by default, return the success of execution as either zero or a number representing the failure of execution, but not necessarily the error number encountered. <\/p>\n This will cause an error and the This time the In order to appropriately handle errors you to know what they are. You may also want to return the errors to the calling application. A number of new functions have been created so that you can appropriately deal with different errors, and log, report, anything you need, the errors that were generated. <\/p>\n When you run the code above, you should receive this on the client, in the message, with a non-zero number in the result set: <\/p>\n In other words, everything you need to actually deal with errors as they occur.<\/p>\n You’ll also notice that the procedure returned an error value (non-zero) even though we didn’t specify a return code. You can still specify a return value as before if you don’t want to leave it up to the engine.<\/p>\n The one area of control we do have in SQL Server 2000 is around the transaction. In SQL Server 2000 you can decide to rollback or not, those are your only options. You need to make decision regarding whether or not to use Modify the procedure to handle transactions:<\/p>\n \nSince the above code will generate an error on the second statement, the transaction is rolled back as a unit. Switch to the results in order to see that the zip code is, in fact, still 90210. If we wanted to control each update as a seperate statement, in order to get one of them to complete, we could encapsulate each statement in a transaction:\n<\/p>\n In this case then, the return value will be ‘90210’ since the first update statement will complete successfully. Be sure that whatever mechanism you use to call procedures does not itself begin a transaction as part of the call or the error generated will result in a rollback, regardless of the commit within the procedure. In the next example, we’ll create a transaction that wraps the other two transactions, much as a calling program would. If we then check for errors and commit or rollback based on the general error state, it’s as if the inner transaction that was successful never happened, as the outer transaction rollback undoes all the work within it. <\/p>\n The new error handling changes how transactions are dealt with. You can now check the transaction state using From there, you can make a decision as to whether or not a transaction is committed or rolled back. With the new Grant Fritchey steps into the workbench arena, with an example-fuelled examination of catching and gracefully handling errors in SQL 2000 and 2005, including worked examples of the new [pubs]<\/code> for SQL Server 2000 and [AdventureWorks]<\/code> for SQL Server 2005.<\/p>\n<\/p>\n\n
SQL Server 2000 – GENERATING AN ERROR <\/h2>\n
\r\nUSE pubs \r\nGO \r\nUPDATE dbo.authors \r\nSET zip = '!!!' \r\nWHERE au_id = '807-91-6654' \r\n\r\n\/* This will generate an error: \r\nMsg 547, Level 16, State 0, Line 1 \r\nThe UPDATE statement conflicted with the CHECK constraint \r\n \"CK__authors__zip__7F60ED59\". \r\nThe conflict occurred in database \"pubs\", \r\n table \"dbo.authors\", column 'zip'. \r\n <\/pre>\n
SQL Server 2005 – GENERATING AN ERROR <\/h2>\n
\r\nUSE AdventureWorks; \r\nGO \r\nUPDATE HumanResources.Employee \r\nSET MaritalStatus = 'H' \r\nWHERE EmployeeID = 100; \r\n\r\n\/* This generates a familiar error: \r\nMsg 547, Level 16, State 0, Line 1 \r\nThe UPDATE statement conflicted with the CHECK constraint \r\n \"CK_Employee_MaritalStatus\". \r\nThe conflict occurred in database \"AdventureWorks\", \r\n table \"HumanResources.Employee\", column 'MaritalStatus'. \r\nThe statement has been terminated. \r\n<\/pre>\n
SQL Server 2000 AND 2005 – ERROR SEVERITY AND EXCEPTION TYPE<\/h2>\n
\n
\n
sysmessages<\/code>.<\/p>\nSQL Server 2000 – CATCH AN ERROR<\/h2>\n
@@ERROR<\/code> value. When a statement completes, this value is set.<\/p>\nzero(0)<\/code>, no error occured. Any other value was the result of an error.<\/p>\n\r\nUSE pubs \r\nGO \r\nUPDATE dbo.authors \r\nSET zip = '!!!' \r\nWHERE au_id = '807-91-6654' \r\nIF @@ERROR = 547 \r\n PRINT 'A constraint error has occurred' \r\nGO \r\n<\/pre>\n
@@ERROR<\/code> is reset by each and every statement as it occurs. This means that if we use the exact same code as above, but check the @@ERROR<\/code> function a second time, it will be different. <\/p>\n\r\nUPDATE dbo.authors \r\nSET zip = '!!!' \r\nWHERE au_id = '807-91-6654' \r\nIF @@ERROR = 547 \r\n PRINT 'A constraint error has occurred. Error Number:' \r\n + CAST(@@ERROR AS VARCHAR) \r\nGO \r\n<\/pre>\n
@@ERROR<\/code> statement as being zero(0), despite the fact that we just had a clearly defined error.<\/p>\nUPDATE<\/code> statement did in fact error out, the IF<\/code> statement executed flawlessly and @@ERROR<\/code> is reset after each and every statement in SQL Server.<\/p>\n@@ERROR<\/code> value after each execution.<\/p>\n\r\nDECLARE @err INT \r\nUPDATE dbo.authors \r\nSET zip = '!!!' \r\nWHERE au_id = '807-91-6654' \r\nSET @err = @@ERROR \r\nIF @err = 547 \r\n PRINT 'A constraint error has occurred. Error Number:' \r\n + CAST(@err AS VARCHAR) \r\nGO \r\n<\/pre>\n
SQL Server 2005 – CATCH AN ERROR<\/h2>\n
@@ERROR<\/code> is still available in SQL Server 2005, a new syntax has been added to the T-SQL language, as implemented by Microsoft: TRY... CATCH<\/code>.<\/p>\n\r\nBEGIN TRY \r\n UPDATE HumanResources.Employee \r\n SET MaritalStatus = 'H' \r\n WHERE EmployeeID = 100; \r\nEND TRY \r\nBEGIN CATCH \r\n PRINT 'Error Handled'; \r\nEND CATCH \r\n<\/pre>\n
'Error Handled'<\/code> is returned to the client.<\/p>\nTRY...CATCH<\/code> that have to be dealt with, which we will cover later. For example, simply having a TRY...CATCH<\/code> statement is not enough.<\/p>\n\r\n\r\n UPDATE HumanResources.Employee \r\n SET ContactID = 19978 \r\n WHERE EmployeeID = 100; \r\nBEGIN TRY \r\n UPDATE HumanResources.Employee \r\n SET MaritalStatus = 'H' \r\n WHERE EmployeeID = 100; \r\nEND TRY \r\nBEGIN CATCH \r\n PRINT 'Error Handled'; \r\nEND CATCH \r\n<\/pre>\n
\r\nMsg 547, LEVEL 16, State 0, Line 1 \r\nThe UPDATE statement conflicted WITH the FOREIGN KEY CONSTRAINT \r\n \"FK_Employee_Contact_ContactID\" \r\nThe conflict occurred IN DATABASE \"AdventureWorks\" \r\n TABLE \"Person.Contact\" COLUMN 'ContactID'. \r\n <\/pre>\n
TRY<\/code> statement.<\/p>\n SQL Server 2000 – USING RAISERROR<\/h2>\n
RAISERROR<\/code> function is a mechanism for returning to calling applications errors with your own message. It can use system error messages or custom error messages. The basic syntax is easy: <\/p>\n\r\nRAISERROR ('You made a HUGE mistake',10,1) \r\n<\/pre>\nRAISERROR<\/code> you’ll either generate a string, up to 400 characters long, for the message, or you’ll access a message by message id from the master.dbo.sysmessages<\/code> table.<\/p>\nRAISERROR<\/code> will behave exactly as if the engine itself had generated the error. This means that a SEVERITY<\/code> of 20 or above will terminate the connection. The last number is an arbitrary value that has to be between 1 and 127.<\/p>\n\r\nRAISERROR('You broke the server: %s',10,1,@@SERVERNAME) \r\n<\/pre>\n\r\n--Unsigned Integer \r\nRAISERROR('The current error number: %u',10,1,@@ERROR) \r\n\r\n--String \r\nRAISERROR('The server is: %s',10,1,@@SERVERNAME) \r\n\r\n--Compound String & Integer & limit length of string to first 5 \r\n--characters \r\nRAISERROR('The server is: %.5s. The error is: %u',10,1, \r\n @@SERVERNAME,@@ERROR) \r\n\r\n--String with a minimum and maximum length and formatting to left \r\nRAISERROR('The server is: %-7.3s',10,1,@@SERVERNAME) \r\n<\/pre>\n\r\n-- To get the error into the SQL Server Error Log \r\nRAISERROR('You encountered an error',18,1) WITH LOG \r\n\r\n-- To immediately return the error to the application \r\nRAISERROR('You encountered an error',10,1) WITH NOWAIT \r\n\r\n-- That also flushes the output buffer so any pending PRINT statements, \r\n-- etc., are cleared. \r\n\r\n-- To use RAISERROR as a debug statement \r\nRAISERROR('I made it to this part of the code',0,1) \r\n<\/pre>\nSQL SERVER 2005 – USING RAISERROR<\/h2>\n
RAISERROR<\/code> in SQL Server 2005 is largely the same as for SQL 2000. However, instead of 400 characters, you have 2047. If you use 2048 or more, then 2044 are displayed along with an ellipsis.<\/p>\nRAISERROR<\/code> will cause the code to jump from the TRY<\/code> to the CATCH<\/code> block.<\/p>\nRAISERROR<\/code> can be called in a more efficient manner in SQL Server 2005. This from the Books Online:<\/p>\n\r\nBEGIN TRY \r\n RAISERROR('Major error in TRY block.',16,1); \r\nEND TRY \r\nBEGIN CATCH \r\n DECLARE @ErrorMessage NVARCHAR(4000), \r\n @ErrorSeverity INT, \r\n @ErrorState INT; \r\n\r\n SET @ErrorMessage = ERROR_MESSAGE(); \r\n SET @ErrorSeverity = ERROR_SEVERITY(); \r\n SET @ErrorState = ERROR_STATE(); \r\n\r\n RAISERROR(@ErrorMessage,@ErrorSeverity,@ErrorState); \r\nEND CATCH; \r\n<\/pre>\n SQL Server 2000 – RETURNING ERROR CODES FROM STORED PROCEDURES<\/h2>\n
\r\nCREATE PROCEDURE dbo.GenError \r\nAS \r\nUPDATE dbo.authors \r\nSET zip = '!!!' \r\nWHERE au_id = '807-91-6654' \r\nGO \r\n\r\nDECLARE @err INT \r\nEXEC @err = GenError \r\nSELECT @err \r\n<\/pre>\n
SELECT<\/code> statement will return a non-zero value. On my machine, -6. In order take control of this, modify the procedure as follows: <\/p>\n\r\nALTER PROCEDURE dbo.GenError \r\nAS \r\nDECLARE @err INT \r\nUPDATE dbo.authors \r\nSET zip = '!!!' \r\nWHERE au_id = '807-91-6654' \r\nSET @err = @@ERROR \r\nIF @err <> 0 \r\n RETURN @err \r\nELSE \r\n RETURN 0 \r\nGO \r\n\r\nDECLARE @err INT \r\nEXEC @err = GenError \r\nSELECT @err \r\n<\/pre>\n
SELECT @err<\/code> statement will return the 547 error number in the results. With that, you can begin to create a more appropriate error handling routine that will evolve into a coding best practice within your organization. <\/p>\n\r\nALTER PROCEDURE dbo.GenError \r\nAS \r\nDECLARE @err INT \r\nUPDATE dbo.authors \r\nSET zip = '!!!' \r\nWHERE au_id = '807-91-6654' \r\nSET @err = @@ERROR \r\nIF @err <> 0 \r\n BEGIN \r\n IF @err = 547 \r\n RAISERROR('Check Constraint Error occurred',16,1) \r\n ELSE \r\n RAISERROR('An unspecified error has occurred.',10,1) \r\n RETURN @err \r\n END \r\nELSE \r\n RETURN 0 \r\nGO \r\n<\/pre>\nSQL Server 2005 – RETURNING ERROR CODES FROM STORED PROCEDURES<\/h2>\n
\r\nCREATE PROCEDURE GenErr \r\nAS \r\n BEGIN TRY \r\n UPDATE HumanResources.Employee \r\n SET ContactID = 19978 \r\n WHERE EmployeeID = 100; \r\n END TRY \r\n BEGIN CATCH \r\n PRINT 'Error Number: ' + CAST(ERROR_NUMBER() AS VARCHAR); \r\n PRINT 'Error Message: ' + ERROR_MESSAGE(); \r\n PRINT 'Error Severity: ' + CAST(ERROR_SEVERITY() AS VARCHAR); \r\n PRINT 'Error State: ' + CAST(ERROR_STATE() AS VARCHAR); \r\n PRINT 'Error Line: ' + CAST(ERROR_LINE() AS VARCHAR); \r\n PRINT 'Error Proc: ' + ERROR_PROCEDURE(); \r\n END CATCH \r\nGO \r\n\r\nDECLARE @err INT; \r\nEXEC @err = GenErr; \r\nSELECT @err; \r\n<\/pre>\n
\r\n(0 row(s) affected) \r\nError Number: 547 \r\nError Message: The UPDATE statement conflicted WITH the \r\n FOREIGN KEY CONSTRAINT \r\n \"FK_Employee_Contact_ContactID\" \r\n The conflict occurred IN DATABASE \r\n \"AdventureWorks\" TABLE \"Person.Contact\" \r\n COLUMN 'ContactID'. \r\nError Severity: 16 \r\nError State: 0 \r\nError Line: 4 \r\nError Proc: GenErr \r\n<\/pre>\n
SQL Server 2000 – TRANSACTIONS AND ERROR TRAPPING<\/h2>\n
XACT_ABORT<\/code>. Setting it to ON<\/code> will cause an entire transaction to terminate and rollback in the event of any runtime error. if you set it to OFF<\/code>, then in some cases you can rollback the individual statement within the transaction as opposed to the entire transaction.<\/p>\n\r\nALTER PROCEDURE dbo.GenError \r\nAS \r\nDECLARE @err INT \r\n\r\nBEGIN TRANSACTION \r\n\r\n UPDATE dbo.authors \r\n SET zip = '90210' \r\n WHERE au_id = '807-91-6654' \r\n SET @err = @@ERROR \r\n IF @err <> 0 \r\n BEGIN \r\n IF @err = 547 \r\n PRINT 'A constraint error has occurred.' \r\n ELSE \r\n PRINT 'An unspecified error has occurred.' \r\n ROLLBACK TRANSACTION \r\n RETURN @err \r\n END \r\n \r\n UPDATE dbo.authors \r\n SET zip = '!!!' \r\n WHERE au_id = '807-91-6654' \r\n SET @err = @@ERROR \r\n IF @err <> 0 \r\n BEGIN \r\n IF @err = 547 \r\n PRINT 'A constraint error has occurred.' \r\n ELSE \r\n PRINT 'An unspecified error has occurred.' \r\n ROLLBACK TRANSACTION \r\n RETURN @err \r\n END \r\n ELSE \r\n BEGIN \r\n COMMIT TRANSACTION \r\n RETURN 0 \r\n END \r\nGO \r\n\r\nDECLARE @err INT \r\nEXEC @err = GenError \r\n\r\nSELECT zip \r\nFROM dbo.authors \r\nWHERE au_id = '807-91-6654' \r\n<\/pre>\n
\r\nALTER PROCEDURE dbo.GenError \r\nAS \r\nDECLARE @err INT \r\n\r\nBEGIN TRANSACTION \r\n\r\n UPDATE dbo.authors \r\n SET zip = '90210' \r\n WHERE au_id = '807-91-6654' \r\n SET @err = @@ERROR \r\n IF @err <> 0 \r\n BEGIN \r\n IF @err = 547 \r\n PRINT 'A constraint error has occurred.' \r\n ELSE \r\n PRINT 'An unspecified error has occurred.' \r\n ROLLBACK TRANSACTION \r\n RETURN @err \r\n END \r\n ELSE \r\n COMMIT TRANSACTION \r\n\r\nBEGIN TRANSACTION \r\n UPDATE dbo.authors \r\n SET zip = '!!!' \r\n WHERE au_id = '807-91-6654' \r\n SET @err = @@ERROR \r\n IF @err <> 0 \r\n BEGIN \r\n IF @err = 547 \r\n PRINT 'A constraint error has occurred.' \r\n ELSE \r\n PRINT 'An unspecified error has occurred.' \r\n ROLLBACK TRANSACTION \r\n RETURN @err \r\n END \r\n ELSE \r\n BEGIN \r\n COMMIT TRANSACTION \r\n RETURN 0 \r\n END \r\nGO \r\n\r\nDECLARE @err INT \r\nEXEC @err = GenError \r\n\r\nSELECT zip \r\nFROM dbo.authors \r\nWHERE au_id = '807-91-6654' \r\n<\/pre>\n
\r\nALTER PROCEDURE dbo.GenError \r\nAS \r\nDECLARE @err1 INT \r\nDECLARE @err2 INT \r\n\r\nBEGIN TRANSACTION \r\n BEGIN TRANSACTION \r\n\r\n UPDATE dbo.authors \r\n SET zip = '90211' \r\n WHERE au_id = '807-91-6654' \r\n SET @err1 = @@ERROR \r\n IF @err1 <> 0 \r\n BEGIN \r\n IF @err1 = 547 \r\n PRINT 'A constraint error has occurred.' \r\n ELSE \r\n PRINT 'An unspecified error has occurred.' \r\n ROLLBACK TRANSACTION \r\n RETURN @err1 \r\n END \r\n ELSE \r\n COMMIT TRANSACTION \r\n\r\n BEGIN TRANSACTION \r\n UPDATE dbo.authors \r\n SET zip = '!!!' \r\n WHERE au_id = '807-91-6654' \r\n SET @err2 = @@ERROR \r\n IF @err2 <> 0 \r\n BEGIN \r\n IF @err2 = 547 \r\n PRINT 'A constraint error has occurred.' \r\n ELSE \r\n PRINT 'An unspecified error has occurred.' \r\n ROLLBACK TRANSACTION \r\n RETURN @err2 \r\n END \r\n ELSE \r\n BEGIN \r\n COMMIT TRANSACTION \r\n RETURN 0 \r\n END \r\nIF (@err1 <> 0) OR (@err2 <> 0) \r\n ROLLBACK TRANSACTION \r\nELSE \r\n COMMIT TRANSACTION \r\nGO \r\n\r\nDECLARE @err INT \r\nEXEC @err = GenError \r\n\r\nSELECT zip \r\nFROM dbo.authors \r\nWHERE au_id = '807-91-6654' \r\n<\/pre>\n
SQL Server 2005 – TRANSACTIONS AND ERROR TRAPPING<\/h2>\n
XACT_STATE()<\/code> function. Transactions can be: <\/p>\n\n
XACT_ABORT<\/code> works the same way. <\/p>\n\r\nALTER PROCEDURE GenErr \r\nAS \r\n BEGIN TRY \r\n BEGIN TRAN \r\n UPDATE HumanResources.Employee \r\n SET ContactID = 1\/0 \r\n WHERE EmployeeID = 100; \r\n COMMIT TRAN \r\n END TRY \r\n BEGIN CATCH \r\n IF (XACT_STATE()) = -1 \r\n BEGIN \r\n ROLLBACK TRAN; \r\n RETURN ERROR_NUMBER(); \r\n END \r\n ELSE IF (XACT_STATE()) = 1 \r\n BEGIN \r\n --it now depends on the type of error or possibly the line number \r\n --of the error \r\n IF ERROR_NUMBER() = 8134 \r\n BEGIN \r\n ROLLBACK TRAN; \r\n RETURN ERROR_NUMBER(); \r\n END \r\n ELSE \r\n BEGIN \r\n COMMIT TRAN; \r\n RETURN ERROR_NUMBER(); \r\n END \r\n END \r\n END CATCH \r\nGO \r\n\r\nDECLARE @err INT; \r\nEXEC @err = GenErr; \r\nSELECT @err; \r\n<\/pre>\n
SQL Server 2005 – EXTENDED 2005 ERROR TRAPPING<\/h2>\n
TRY...CATCH<\/code> construct, it’s finally possible to do things about errors, other than just return them. Take for example the dreaded deadlock. Prior to SQL Server 2005, the best you could hope for was to walk through the error messages stored in the log recorded by setting TRACEFLAG<\/code> values. Now, instead, you can set up a retry mechanism to attempt the query more than once. <\/p>\n\r\nALTER PROCEDURE GenErr \r\nAS \r\nDECLARE @retry AS tinyint, \r\n @retrymax AS tinyint, \r\n @retrycount AS tinyint; \r\n\r\nSET @retrycount = 0; \r\nSET @retrymax = 2; \r\nSET @retry = 1; \r\n\r\nWHILE @retry = 1 AND @retrycount <= @retrymax \r\nBEGIN \r\n SET @retry = 0; \r\n BEGIN TRY \r\n UPDATE HumanResources.Employee \r\n SET ContactID = ContactID \r\n WHERE EmployeeID = 100; \r\n END TRY \r\n BEGIN CATCH \r\n IF (ERROR_NUMBER() = 1205) \r\n BEGIN \r\n SET @retrycount = @retrycount + 1; \r\n SET @retry = 1; \r\n END \r\n END CATCH \r\nEND \r\nGO \r\n\r\nDECLARE @err INT; \r\nEXEC @err = GenErr; \r\nSELECT @err;\r\n<\/pre>\n","protected":false},"excerpt":{"rendered":"TRY..CATCH<\/code> capabilities.…<\/p>\n","protected":false},"author":221792,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[143531],"tags":[4178,4669,4671,4672,4150,4151,4668,4252,5778,4460],"coauthors":[6785],"class_list":["post-228","post","type-post","status-publish","format-standard","hentry","category-t-sql-programming-sql-server","tag-bi","tag-exceptions","tag-raiseerror","tag-severity-levels","tag-sql","tag-sql-server","tag-sql-server-error-handling","tag-t-sql-programming","tag-try-catch","tag-workbench"],"acf":[],"_links":{"self":[{"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/posts\/228","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/users\/221792"}],"replies":[{"embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/comments?post=228"}],"version-history":[{"count":9,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/posts\/228\/revisions"}],"predecessor-version":[{"id":66386,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/posts\/228\/revisions\/66386"}],"wp:attachment":[{"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/media?parent=228"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/categories?post=228"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/tags?post=228"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/coauthors?post=228"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}