kolkov, а вы когда нибудь администрировали триггеры? Разбираться с их работой такая головная боль, что я давно взял за правило - чем меньше триггеров, тем лучше.
Полного ответа дать не удастся, так как в скрипте везде используются данные значения которых не известно.
Но если обратить внимание на строку IDate.CreationDateTime < (GETDATE() - 724)
Сейчас это примерно 2016-02-02
В базе точно есть записи из [dbo].[dvsys_instances_date] с датой меньше 2016-02-02 ?
Честно сказать побоялся писать через событийную модель, думая что это может повлиять на переключение стрелками строк в DataGrid.
Казалось что через триггер или прочие WPF-ные фишки будет будет правильнее.
Но нет, работает нормально. Только по хорошему нужно CommitEdit()
Спасибо!
Собственно по тому и пишу вопрос, что понимаю что это можно сделать.
В коде, кстати и идет обращение к уже имеющемуся экземпляру Outlook.
Но писать сфивер или патч в EXE не хочется - долго, муторно и накладно.
Иван: так, а касательно каждые 20 строк? Как должен выглядеть результат:
Я пока так представил:
Позиция 1 Цена 1 Позиция 21 Цена 21
Позиция 2 Цена 2 Позиция 22 Цена 22
.......................................
Позиция 20 Цена 20 Позиция 40 Цена 40
?
Daeamon: У вас ошибки в синтаксисе. "FROM [OTD_db].[dbo].[DocumentsA] AS [CurStatID] WITH (NOLOCK)" и еще зачем обращаться к одной и тоже таблице два раза? Я про ваше условие WHERE...
Вот немного набросал.
SELECT DISTINCT [Vv0].[Deleted]
,[LtstRev].[LatestrevisionNo]
,[Vv1].[Name] AS 'Current Status'
,[Vv8].[ValueText] AS 'Component name'
,[Vv10].[ValueCache] AS 'Componet cache'
,[Vv2].[ValueText] AS 'PartNumber'
,[Vv4].[ValueText] AS 'FootPrint'
,[Vv5].[ValueText] AS 'FootPrint path'
,[Vv6].[ValueText] AS 'Library path'
,[Vv7].[ValueText] AS 'Library ref'
,[Vv9].[ConfigurationName] AS 'Config'
,[PrjID].[ProjectID] AS 'ProjectID'
FROM [OTD_db].[dbo].[DocumentsA] AS [CurStatID] WITH (NOLOCK)
INNER JOIN [OTD_db].[dbo].[Status] AS [Vv1] WITH (NOLOCK) ON [Vv1].[StatusID] = [CurStatID].[CurrentStatusID] AND [Vv1].[Name] LIKE 'Шаблон'
Борис Животное: потому что если есть возможность избежать падение транзакции, то лучше это сделать. Плюс я считаю что шарповая транзакция это зло, которое нужно по возможности избегать. Они не надежны и сложно отлаживаемы.
Прочитал источник - там о табличных переменных шла речь, как об альтернативе. Очень странный совет - на практике они работают гораздо медленнее времянок, особенно если в таблице выше 10 тыс. записей.
Создавать и заполнять времянки лучше до открытия транзакции. По хорошему получили данные, проверили и только после этого записываем.
Денис Машанов: а можете пояснить что вы вообще хотите добиться более подробно? Как должна меняться картинка и как вы вообще данные храните у себя?
По поводу того что не ведется - просто скомпилируйте проект. После этого всё должно будет работать нормально.
Антон Алфимов: транзакция нужна на любую операцию где запись идет в две и более таблиц.
Насчет остатков - по мне таблица не решение, решение запрос в базу. Считать запрос остатков можно двумя способами: если вам нужно знать с каких приходов вам нужно будет списать товар, то по формуле ПРИХОДЫ-РЕЛЕЙШЕНЫ, если просто нужно знать количество остатков по SKU- то формула - ПРИХОДЫ-РАСХОДЫ (так быстрее).
Соглашусь, что это не всегда быстро. Но вариант держать таблицу в базе SKU-Кол-во мне не по душе, по причине того, что количество нужно будет увеличивать и уменьшать. Это и отслеживать неудобно и я не гарантирую правильности заполнения при частых и одновременных запросах.
Плюс данная система позволяет знать с какого прихода мы списали товар, а это как раз учитывается при расчете прибыли.
Алексей Павлов: в ответах мне нет смыла писать. Это костыль, а не решение. Огромная просьба отписаться, если сможете решить. У меня пока не получается.
