in RuleSamples/AvoidWaitForDelayRule.cs [86:127]
public override IList<SqlRuleProblem> Analyze(SqlRuleExecutionContext ruleExecutionContext)
{
IList<SqlRuleProblem> problems = new List<SqlRuleProblem>();
TSqlObject modelElement = ruleExecutionContext.ModelElement;
// this rule does not apply to inline table-valued function
// we simply do not return any problem in that case.
if (IsInlineTableValuedFunction(modelElement))
{
return problems;
}
string elementName = RuleUtils.GetElementName(ruleExecutionContext, modelElement);
// The rule execution context has all the objects we'll need, including the fragment representing the object,
// and a descriptor that lets us access rule metadata
TSqlFragment fragment = ruleExecutionContext.ScriptFragment;
RuleDescriptor ruleDescriptor = ruleExecutionContext.RuleDescriptor;
// To process the fragment and identify WAITFOR DELAY statements we will use a visitor
//
WaitForDelayVisitor visitor = new WaitForDelayVisitor();
fragment.Accept(visitor);
IList<WaitForStatement> waitforDelayStatements = visitor.WaitForDelayStatements;
// Create problems for each WAITFOR DELAY statement found
foreach (WaitForStatement waitForStatement in waitforDelayStatements)
{
// When creating a rule problem, always include the TSqlObject being analyzed. This is used to determine
// the name of the source this problem was found in and a best guess as to the line/column the problem was found at
//
// In addition if you have a specific TSqlFragment that is related to the problem also include this
// since the most accurate source position information (start line and column) will be read from the fragment
SqlRuleProblem problem = new SqlRuleProblem(
String.Format(CultureInfo.CurrentCulture, ruleDescriptor.DisplayDescription, elementName),
modelElement,
waitForStatement);
problems.Add(problem);
}
return problems;
}