Хранимая процедура

я застрял в создании хранимой процедуры, которая должна ежедневно обновлять вычисляемый столбец. К сожалению, мои знания о хранимых процедурах ограничены, но, похоже, это правильное место. Я пытаюсь дать больше справочной информации:

Основная таблица хранит заявки и называется tabData. Он имеет столбец «IsReturn» с битом типа данных (логическим).

1.Rule: заявка является возвратом, если ее значение столбца fimaxActionCode является одним из следующих: 1, 2, 3, 4, 5, 8, 9, 12, 14, 17, 18, 20, 21, 22, 23, 24, 25, 30, 31, 32, 35.

2.Правило: заявка не является возвратом, если у нее есть предыдущая заявка (идентифицированная по значению даты и IMEI (идентификационному номеру для мобильных телефонов) с fimaxActionCode 8 , 10, 11, 13, 19, 23, 24, 26, 27, 28, 29, 30, 33, 34, 36, 37 в fiClaimeStatus 1, 4, 6, 254, 255.

Первое правило возврата было старым и реализовано в виде вычисляемого столбца в нашем кубе ssas. Поскольку сейчас все стало сложнее, я подумал, что было бы лучше поместить этот расчет в хранимую процедуру, которая выполняется каждое утро.

Это то, что я должен проверить, если утверждение-кандидат (правило 1) не соответствует правилу 2: я создал представление «PrevClaim», которое выбирает все предыдущие утверждения:

SELECT     TOP (100) PERCENT Claim.idData AS ClaimID, PrevClaim.idData AS PrevClaimID, Claim.IMEI, 
                      Claim.Repair_Completion_Date AS ClaimRepDate, PrevClaim.Repair_Completion_Date AS PrevClaimRepDate, 
                      PrevClaim.fimaxActionCode AS PrevFiMaxActionCode, PrevClaim.fiClaimStatus AS PrevFiClaimStatus, Claim.IsReturn AS ClaimIsReturn
FROM         dbo.tabData AS Claim INNER JOIN
                      dbo.tabData AS PrevClaim ON Claim.IMEI = PrevClaim.IMEI AND Claim.idData <> PrevClaim.idData AND 
                      Claim.Repair_Completion_Date > PrevClaim.Repair_Completion_Date
ORDER BY PrevClaimRepDate DESC

Я могу получить последнее Parent-Claim для данного идентификатора с помощью этого sql-оператора (это утверждение должно быть проверено по правилу 2):

SELECT     TOP (1) ClaimID, PrevClaimID, IMEI, ClaimRepDate, PrevClaimRepDate, PrevFiMaxActionCode, PrevFiClaimStatus
FROM         PrevClaim
WHERE     (ClaimID = 44921287)
ORDER BY PrevClaimRepDate DESC

Но теперь я не знаю, как/где проверить, было ли это родительское требование утверждением, которое не соответствует правилу 2. Если я изменю этот sql и поставлю условие в предложение where, я получу неправильное утверждение (учитывайте, что есть 4 родительских требования , последний по времени в порядке, но четвертый терпит неудачу, поэтому я верну четвертый, но его нужно сверить с последним):

SELECT     TOP (1) ClaimID, PrevClaimID, ClaimRepDate, PrevClaimRepDate, PrevFiMaxActionCode, PrevFiClaimStatus
FROM         PrevClaim
WHERE     (ClaimID = 44921287) AND (PrevFiMaxActionCode IN (8, 10, 11, 13, 19, 23, 24, 26, 27, 28, 29, 30, 33, 34, 36, 37)) AND (PrevFiClaimStatus IN (1, 4, 254, 255, 6))
ORDER BY PrevClaimRepDate DESC

Я хожу кругами или, может быть, слишком жарко для чего-то подобного. Я надеюсь, что кто-нибудь сможет направить меня в правильном направлении и/или показать мне, как реализовать это в хранимой процедуре (ОБНОВЛЕНИЕ...CASE но как?).

EDIT: я думаю, что сейчас я на правильном пути. Может быть, кто-нибудь может показать мне, как обновить всю таблицу в одном sql-операторе. Следующая пользовательская функция дает мне правильное значение:

    SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO

CREATE FUNCTION dbo._isClaimReturn 
(
    @claimID  int,
    @fimaxActionCode int
)
RETURNS int
AS
BEGIN
 DECLARE @isReturn int

  IF(@fimaxActionCode in (1, 2, 3, 4, 5, 8, 9, 12, 14, 17, 18, 20, 21, 22, 23, 24, 25, 30, 31, 32, 35))
  AND (SELECT     TOP (1) PrevFiMaxActionCode
  FROM   PrevClaim
  WHERE     (ClaimID = @claimID))IN(8, 10, 11, 13, 19, 23, 24, 26, 27, 28, 29, 30, 33, 34, 36, 37)
  AND 
  (SELECT     TOP (1)PrevFiClaimStatus
  FROM         PrevClaim
  WHERE     (ClaimID = @claimID))IN(1, 4, 254, 255, 6)
  BEGIN
   Set @isReturn = 0
  END
 ELSE
  BEGIN
   Set @isReturn = 1
  END 

 RETURN @isReturn

END
GO

Еще вопрос: можно ли использовать только один запрос? В моей функции я использую два запроса в PrevClaim-View, чтобы проверить, находится ли Prev.Claim в критическом состоянии и имеет критический код MaxAction.


person Tim Schmelter    schedule 08.07.2010    source источник


Ответы (2)


Будет ли что-то вроде следующих строк тем, что вы ищете?

UPDATE tabData TD1
    SET TD1.IsReturn = 1
    WHERE TD1.fimaxActionCode IN (1, ...etc... , 35) AND
          NOT EXISTS (SELECT *
                          FROM tabData TD2
                          WHERE TD1.IMEI = TD2.IMEI AND
                                TD2.fimaxActionCode IN (8, ...etc... , 35) AND
                                TD2.fiClaimStatus   IN (1, 4, 254, 255, 6) AND
                                TD2.Repair_Completion_Date > TD1.Repair_Completion_Date);

Я думаю, что первое правило — это часть WHERE TD1.fimaxActionCode IN (1, ...etc... , 35). Запрос внутри NOT EXISTS предназначен для проверки второго правила. Если я немного ошибаюсь, вы можете увидеть свой путь к правильному решению. Если я совсем не прав... э-э... ну, мы попробуем что-нибудь выяснить, надеясь, что я не посылаю вас не в ту сторону и не трачу ваше время.

Отредактировано с учетом первого комментария.

person Brian Hooper    schedule 08.07.2010
comment
Я уже дал мне ответ о том, как рассчитать правильное значение с помощью определяемой пользователем функции. Поэтому мне нужно только проверить правило 1 И _isClaimReturn(idData)=1. Можете ли вы завершить update-sql с этой информацией? Возможно, у вас также есть ответ на мой последний вопрос о множественном выборе в функции. Все равно спасибо :) - person Tim Schmelter; 08.07.2010

Вы можете создать новый вычисляемый столбец, использующий UDF, который вы указали в своем редактировании. Это гарантирует, что значение всегда будет актуальным.

person K Richard    schedule 08.07.2010
comment
Спасибо за предложение. Но у меня есть еще одна проблема: состояние возврата должно быть заблокировано в дату закрытия (каждый месяц). Таким образом, значение не должно обновляться после даты закрытия. Но я думаю, что знаю, что делать. - person Tim Schmelter; 09.07.2010
comment
Кстати, исходный вопрос, когда кто-то предложил использовать хранимую процедуру вместо mdx-запроса (соображения производительности), был следующим: stackoverflow.com/questions/3194924/ssas-named-queries - person Tim Schmelter; 09.07.2010