T-SQL INSERT каждого 10 дней

[Stilet]

вынужден хранить в таблице

Крайне неудачная идея...
А почему тогда триггером? Почему не зарядить планировщик задач на каждые 10 дней?

[xxbesoxx]

Крайне неудачная идея...

Stilet После 9-ого дня начисляется процент по дням только 1 раз в день ... хотели так посмотреть и если я это не хранил таблицу , как я мог доказать кому -когда и сколько было начислено ?

А почему тогда триггером?

Триггер это в моменте оформление ... Когда какой то Вася попадает в Tab1 эму сразу начисляем 10% от выданный деньги и потом после 9 дня хотели каждого дня что было начислено процент по дня... сделано все нормально работает

insert Tab2(mon, Tab1ID)  output 'inserted.Tab2'[inserted.Tab2],inserted.*
select mon/100*1 ,id
from Tab1 
where Tab1.dt<dateadd(day, -9, cast(GETDATE() as date))
and not exists( 
	       select * 
	       from Tab2 
	       where Tab1.id=Tab2.Tab1ID 
               and cast(Tab2.dt as date)=cast(GETDATE() as date)
              )

А сейчас меняется чуть-чуть задача и хотят не 1% по дням . А каждого 10 дня 10%
Питаюсь этого тоже делать , и для этого думаю что хочу выбрать последний дата начисления ...
Выбираю в select

SELECT D.DT_Nachislen
FROM (SELECT T1.*, 
     (SELECT  TOP 1 T2.dt  from Tab2 T2 
      WHERE  T2.Tab1ID=T1.id ORDER BY T2.dt DESC) AS DT_Nachislen FROM Tab1 T1) D

Что это запрос не получается запихнуть здесь where Tab1.dt<dateadd(day, -9, cast(GETDATE() as date))
сейчас создал времени таблица и туда храню это данный -"последние дата начисление"

CREATE TABLE #MyTab (MyDate datetime)
INSERT INTO #MyTab(MyDate) 
            SELECT D.DT_Nachislen
            FROM (SELECT T1.*, 
            (SELECT  TOP 1 T2.dt  from Tab2 T2 
            WHERE  T2.Tab1ID=T1.id ORDER BY T2.dt DESC) AS DT_Nachislen FROM Tab1 T1) D 
 SELECT * FROM #MyTab
------Здесь хочу это INSERT что было ------------
и потом в конце 
DROP TABLE #MyTab

Вот здесь зависаю

CREATE TABLE #MyTab (MyDate datetime)
INSERT INTO #MyTab(MyDate) 
            SELECT D.DT_Nachislen
            FROM (SELECT T1.*, 
            (SELECT  TOP 1 T2.dt  from Tab2 T2 
            WHERE  T2.Tab1ID=T1.id ORDER BY T2.dt DESC) AS DT_Nachislen FROM Tab1 T1) D 
 SELECT * FROM #MyTab

                            
insert Tab2(mon, Tab1ID)  output 'inserted.Tab2'[inserted.Tab2],inserted.*
select mon/100*10, -- Вот здесь 10%
       id
from Tab1 
-- А здесь MyDate нелзя пользовать ?
where MyDate  < 
        dateadd(day, -9, cast(GETDATE() as date))
and not exists( 
	       select * 
	       from Tab2 
	       where Tab1.id=Tab2.Tab1ID 
               and cast(Tab2.dt as date)=cast(GETDATE() as date)
              )
 -- Здесь уже удаляю времены таблица 
 DROP TABLE #MyTab

Щас кофе попью и буду продолжать

Почему не зарядить планировщик задач на каждые 10 дней?

Друг , Я думал на это вы меня это посоветовали на предыдущие теме ... Но на несколько клиенту MS SQL и приложения установлен на одном компьютере не кто не выделяет компьютер для сервера ... и если 23:59 компьютер отключили или перезагрузил оператор , это "планировщик" на тот день не будет начислять процент да ? и за этого пришлось делать таким образом

[Stilet]

После 9-ого дня начисляется процент по дням только 1 раз в день ... хотели так посмотреть и если я это не хранил таблицу , как я мог доказать кому -когда и сколько было начислено ?

Ну смотри: Берешь текущую дату - дата кредита (или что там у вас). Вычисляешь разницу в днях. Отнимаешь 9, а остальное делишь на 10. Полученное умножаешь на номинальный процент и показываешь это в вычисляемом поле.
Вести записи по накрутке процентов в БД чревато недостоверностью данных (у меня такой опыт был).

Щас кофе попью и буду продолжать

Зря. Ты подумай о том, как описать ХПшку, в которую будет передаваться значение процента, дата начала и которая будет возвращать начисленный процент. Не надо в БД прям так хранить.

P.S. Малость поправлюсь: После того, как на 10 разделил - получаешь счетчик для цикла, в котором прибавляешь процент, а потом его из ХП возврашаешь. Простым умножением неправильно будет.

[Аватар]

Еще 3 копейки почему чревато - редактирование полей исходной записи, от значений которых рассчитывается этот процент. Только не говори, что его не будет. Еще как будет, если не программно, то скриптом, который сам же и запустишь

[Stilet]

Еще 3 копейки почему чревато

А я с другой траблой сталкивался. На компе батарейка кырдыкнулась. Опомнился оператор когда в минусы баланс ушел - через полмесяца (В бд даты заносились несусветные). А за это время процентов накрутил записями в БД будь здоров. Я тогда сказал "Идите вы сами чистить свои базы". Банальная проблема дала такие всходы болот

[xxbesoxx]

Так напишу как я решил это задача , только вы не бейте А то я все расскажу у дядя "Мишико"

1) это запросе попадает последний дата начисление DT_Nachislen

SELECT *
FROM (SELECT T1.*, 
     (SELECT  TOP 1 T2.dt  from Tab2 T2 
      WHERE  T2.Tab1ID=T1.id ORDER BY T2.dt DESC) AS DT_Nachislen FROM Tab1 T1) D

Я создаю представления потому что не было недоступно поля Tab1.mon

Create view T_Name
as
SELECT *
FROM (SELECT T1.*, 
     (SELECT  TOP 1 T2.dt  from Tab2 T2 
      WHERE  T2.Tab1ID=T1.id ORDER BY T2.dt DESC) AS DT_Nachislen FROM Tab1 T1) D

Потом , когда уже все поля доступно в месте этого

select mon/100*1 ,id
from Tab1 
where Tab1.

Я магу написать так

SELECT T.mon/100*10, 
       T.id
FROM T_Name T

целиком это сценарий выглядит так

insert Tab2(mon, Tab1ID)  output 'inserted.Tab2'[inserted.Tab2],inserted.*
SELECT T.mon/100*10, 
       T.id
FROM T_Name T
where T.DT_Nachislen<dateadd(day, -9, cast(GETDATE() as date))
and not exists( 
	       select * 
	       from Tab2 
	       where T.id=Tab2.Tab1ID 
               and cast(Tab2.dt as date)=cast(GETDATE() as date)
              )

А бухгалтеру покажу это так детально

  select T1.c_fio as ФИО, T1.dt as [Дата выдачи] , 
         T2.dt as [Дата начисление], 
		 T2.mon as [Начислени процент]
  from Tab1 T1 inner join Tab2 T2 on T1.id=T2.Tab1ID
  order by 1 asc

Проверяется последний дата начисление T.DT_Nachislen и если больше на 9 то работает INSERT .... сегодня 26.10.2015 хот сколько раз не выполнял он начислял 05.11.2015 только один раз, А второе раз он не делает не какой INSERT и потом 15.11.2015 и.т.д... Огромное спасибо Аватар , Огромное спасибо Stilet много раз помогли.!!! Я очень вам благодарен ... Вы хорошие, дружны и веселы люди . Дай вам бог здоровья и все хорошего... Тема можно закрыть

[Stilet]

Тема можно закрыть

Хозяин конечно барин, но я бы на твоем месте так не делал...

[xxbesoxx]

но я бы на твоем месте так не делал...

Stilet Это Tab1 и Tab2 просто для тест , А так такой структура мне уже работает в программу .... примерно как у меня на #1 он после 9 дня начислял каждого дня только 1% А сейчас другой бухгалтер захотел каждого 10-ого дня 10%... Мне так проще потому что работа на проекте получается меньше время тратит, переделаю бистро и все ... А так не хочу менять структуру и много чего ... честно лень .... за копейки тратит на него много время . Желание пропадает когда "Работа много" и оплата "Копейки " но иногда это копєйчики тоже нужно и работаю вынужден.
У нас не такой мотивация как на ваши стране .... У нас работодатель хотят все за копейки и бистро ... мотивация не та

[Stilet]

он после 9 дня начислял каждого дня только 1% А сейчас другой бухгалтер захотел каждого 10-ого дня 10%...

В таких случаях делается процентная сетка. Ну или тарифная сетка, если в общем.
Особая таблица-справочник с тарифами и их характеристиками, их номенклатурным кодом или кодом вида. Каждый платеж ну или транзакция денежная получает код из этой тарифной сетки, в которой задуты параметры начисления.
Я сталкивался например с такой таблицей-сеткой:
1) Код вида тарифа или ставки
2) Процент
3) Минимальная плата
4.1) BLOB поле с процедурой расчета.
4.2) Поле с характеристикой расчета.

Пункты 4 взаимоисключающие. Либо там хранили ХПшку, которая вызывалась для калькуляции начисления либо какое-то цифровое условие.
Такой тарифный справочник давал большую гибкость базе, поскольку самих транзакций клиентов не затрагивал, всего лишь являясь оберткой над вычислениями начислений.

А у тебя ерунда какая-то получается: Ведется тупо букмекерская книга.

А так не хочу менять структуру и много чего ... честно лень

Я тут на форуме недавно одному... глупцу, если мягко говорить, обьяснял чем такие "ленивые" события чреваты - он сказал что ему "насрать". Ты хочешь к нему в когорту глупцов попасть? Имей ввиду - потом будешь жалеть.

[xxbesoxx]

А у тебя ерунда какая-то получается:

Почему ? все работает правильно да ?

обьяснял чем такие "ленивые"

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

Ты хочешь к нему в когорту глупцов попасть? Имей ввиду - потом будешь жалеть.

Буду - буду и если буду, тогда начну переписать с нуля БД и сам программу ... А так на данный момент работает все нормально , не вижу не какой глук