|
|
|
SSC-Enthusiastic
      
Group: General Forum Members
Last Login: Friday, April 26, 2013 6:18 AM
Points: 129,
Visits: 205
|
|
|
|
|
|
Valued Member
      
Group: General Forum Members
Last Login: Yesterday @ 1:49 PM
Points: 54,
Visits: 249
|
|
How can I see the contents of the TXT files? When I click on the link to the TXT files, I get a SQL Server Central page with the contents saying that it could not find the file. This is the case for both TXT files. I am curious to see what code you added, since I am working on this type of problem now.
Mike
|
|
|
|
|
SSC-Enthusiastic
      
Group: General Forum Members
Last Login: Friday, April 26, 2013 6:18 AM
Points: 129,
Visits: 205
|
|
i did sent email to steve jones
|
|
|
|
|
SSC-Dedicated
           
Group: Administrators
Last Login: Yesterday @ 1:47 PM
Points: 31,406,
Visits: 13,722
|
|
|
|
|
|
SSC Rookie
      
Group: General Forum Members
Last Login: Saturday, September 15, 2012 1:55 PM
Points: 31,
Visits: 34
|
|
I noticed that the author uses this statement to grab the newly inserted identity:
set @INSERTED_IDENTITY_ID = IDENT_CURRENT('HIST_ERROR_LOG');
I think he meant to specify the table 'ERROR_LOG', not 'HIST_ERROR_LOG'.
Also, IDENT_CURRENT will return the identity value of the table provided across all sessions, meaning you could get a value that some other thread generated. I usually rely on scope_identity(), which works all the time, except if you have a trigger on the table in which you're inserting into and that trigger happens to be inserting into yet another table with an identity (not a common scenario).
Another confusing point of the article is the author's variable naming conventions, prefix of: '@$'. You only need to use @ to indicate something's a variable. I couldn't find any reference as to what the $ would stand for. My guess it's a remnant of an older style when variables were prefixed with $ (e.g. environment variables in a shell).
|
|
|
|
|
SSC-Enthusiastic
      
Group: General Forum Members
Last Login: Friday, April 26, 2013 6:18 AM
Points: 129,
Visits: 205
|
|
pvoutov (7/7/2008) I noticed that the author uses this statement to grab the newly inserted identity:
set @INSERTED_IDENTITY_ID = IDENT_CURRENT('HIST_ERROR_LOG');
I think he meant to specify the table 'ERROR_LOG', not 'HIST_ERROR_LOG'. (Correct)
Also, IDENT_CURRENT will return the identity value of the table provided across all sessions, meaning you could get a value that some other thread generated. I usually rely on scope_identity(), which works all the time, except if you have a trigger on the table in which you're inserting into and that trigger happens to be inserting into yet another table with an identity (not a common scenario).
Another confusing point of the article is the author's variable naming conventions, prefix of: '@$'. You only need to use @ to indicate something's a variable. I couldn't find any reference as to what the $ would stand for. My guess it's a remnant of an older style when variables were prefixed with $ (e.g. environment variables in a shell).
You are right about Error_Log table name. $ is to distinguish templated variables from lately declared by developer's variables
|
|
|
|
|
Say Hey Kid
      
Group: General Forum Members
Last Login: Friday, April 26, 2013 11:57 AM
Points: 708,
Visits: 660
|
|
| Thanks Leo for the article, the information was very interesting. Your English is pretty good, though there were plenty of grammar errors. I would have thought your editor would have caught them. Keep practicing. I look forward to your next article.
|
|
|
|
|
SSCarpal Tunnel
       
Group: General Forum Members
Last Login: 2 days ago @ 2:50 AM
Points: 4,785,
Visits: 1,334
|
|
Nice article. You have really encouraged lot of people to write. We may see lot of articles from new bies.....:)
|
|
|
|
|
Mr or Mrs. 500
      
Group: General Forum Members
Last Login: Tuesday, November 27, 2012 9:57 AM
Points: 502,
Visits: 212
|
|
Thanks for the article Leo. It seems well suited to function in the environment you propose. I want to know why I never see anybody use the SAVE TRAN statement. In my research and testing, this is the only way to isolate a transaction within a stored procedure, so that it can be independently rolled back without regards to the transaction state before the procedure was called. ?? Has anybody else used SAVE TRAN?
|
|
|
|
|
Forum Newbie
      
Group: General Forum Members
Last Login: Thursday, September 18, 2008 11:56 AM
Points: 1,
Visits: 1
|
|
| Pity there are no autonomous transactions in SQL Server. Has anyone used a CLR to accomplish autonomous transactions?
|
|
|
|