|
v7: md модифицировался под Win7 и ХР, объединен. Накат на SQL базу под ХР не идет. | ☑ | ||
---|---|---|---|---|
0
olmi
10.12.13
✎
09:04
|
Обновляю правленную базу бухгалтерии 568. Md готовился под ХР и семеркой, блоками, md с блоками правок сохранялись с текущей кодировкой семерки и ХР соответственно, потом объединялись под ХР. Полный md сохранен с текущей кодировкой ХР.
При объединении с md на копии боевой базы SQL дает ошибку "CREATE UNICUE INDEX terminated because a duplicate key was found for index ID 2.Most significant primary key is '1FUPQ '. SQL State: 01000.Native 3621... The statement has been terminated.". Предполагаю, что проблема в неправильной кодировке, надо было с кодировкой "русский, белорусский и т.д." сохранять. Что можно сделать сейчас? Поможет ли накат этого md на боевой в пустой базе dbf с сохранением в русской кодировке? |
|||
1
ДенисЧ
10.12.13
✎
09:05
|
кодировка тут ни причём. База кривая....
|
|||
2
ЧеловекДуши
10.12.13
✎
09:08
|
(0) Вынь 7 и 1С 7.7 + ХП... зверский коктельчик + SQL :))
Да вы мазохистка... :) |
|||
3
ЧеловекДуши
10.12.13
✎
09:13
|
+(0) Можно попросту убить Файлик "OrdNoChk.prm", Оставить только XP и сервер 2003 32х или 64х :)
И все у вас получится :) + GComp-мом можно разархивировать MD файл и упаковать его обратно |
|||
4
ЧеловекДуши
10.12.13
✎
09:13
|
+ >>> GComp-мом
Соответственно, только под Вин ХП |
|||
5
olmi
10.12.13
✎
09:23
|
(3) 1. Где взять GComp? Я с ним дела не имела еще.
2. Где находится OrdNoChk.prm, с которым надо поступить неуважительно?) 3. Можно ли вообще пользовать 1Сину под 7-кой?) И объединять с ХР в каком-либо виде?) Моих знаний явно мало. |
|||
6
пипец
10.12.13
✎
09:24
|
наверное - в режиме конфигуратора - администрирование кодовая страница не доступна ?
ЗЫ или перекодировать пустой каталог с МД тяжко? |
|||
7
NikVars
10.12.13
✎
09:25
|
(0) Начинать нужно с фотки в ЛК. Это магия!
|
|||
8
Mikeware
10.12.13
✎
09:29
|
Причем тут md?
ошибка - в базе. |
|||
9
Mikeware
10.12.13
✎
09:30
|
+(8) ну, или в ДНК
|
|||
10
ЧеловекДуши
10.12.13
✎
09:32
|
(5) >>> Можно ли вообще пользовать 1Сину под 7-кой?
Можно, с бубном и танцами. Нельзя пользоваться при этом SQL, оно не поддерживает старый формат :) Еще хуже когда одновременно работают и ХП и Вин7 Файл "OrdNoChk.prm" ищи в каталоге БД :) |
|||
11
ЧеловекДуши
10.12.13
✎
09:33
|
+(10) >><>оно не поддерживает старый формат
Старый формат, который нужен для работы 1С 7.7 :) |
|||
12
ЧеловекДуши
10.12.13
✎
09:33
|
+ И где фото? В бикини... если можно :)
|
|||
13
olmi
10.12.13
✎
09:43
|
(6), (9) Падающего подтолкни? Не комильфо - я же с проблемой обратилась, причем к высококлассным профессионалам. Если чего-то не знаю - бить по лицу - метод решения?
(8) База вообще с причудами. Но надо искать решение же, а не констатировать факт. (10) SQL-я база под ХР. И как все-таки правильно - удалить OrdNoChk.prm или(и)архив менять GCompом? Вообще, уже спасибо большое за ответы!) |
|||
14
olmi
10.12.13
✎
09:45
|
(7) - Что есть ЛК?) И что за фото требуется?) Не (12) же).
|
|||
15
Mikeware
10.12.13
✎
09:50
|
(13) база английским-по-белому написала, где у нее ошибка...
a duplicate key was found for index ID 2.Most significant primary key is '1FUPQ '. |
|||
16
olmi
10.12.13
✎
09:56
|
(15) Если бы я знала, как с этим справиться, сюда бы не писала. Зачем такой тон? Я ведь обращаюсь за помощью. Или Миста стала закрытым клубом ОТЦОВ? Тогда прошу прощения, что потревожила.
|
|||
17
mikecool
10.12.13
✎
09:57
|
согласен с ораторами в (1), (8) и (9)
|
|||
18
пипец
10.12.13
✎
09:59
|
(14) ЛК видимо личная карточка
ЗЫ если база не большая то выгрузка загрузка - собственно ЗЫЫ а ошибку искать - это таки надо понимать - чем ее править - в самом скуле или средствами 1Цы /нам в наследство база досталась изначально с ошибкой, правили вручную таблицу на скуле / |
|||
19
olmi
10.12.13
✎
10:13
|
(17) Дай Бог, чтобы у Вас никогда не было проблем. И к Вам никогда не обращались бы в таком тоне.
|
|||
20
olmi
10.12.13
✎
10:13
|
(18) База достаточно большая, чтобы стандартной выгрузкой-загрузкой помочь нельзя было. SQL я знаю плохо. Правили ли когда-то таблицы SQL вручную, не знаю. Хорошо бы, если б ошибку можно было поправить средствами 1С.
|
|||
21
ДенисЧ
10.12.13
✎
10:14
|
(20) Для начала на копии ТИИ запустиь.
Не поможет - тогда уже руками. |
|||
22
NikVars
10.12.13
✎
10:16
|
||||
23
NikVars
10.12.13
✎
10:17
|
+(22) Это тебе ссылка для демострации, что лучше позвать специалиста.
|
|||
24
НеБорис Нуралиев
10.12.13
✎
10:18
|
(12) При всем уважении к ТС, не надо фоток в бикини :).
(0) ТС. Ошибка в SQL-базе. Лучше позвать специалиста. |
|||
25
NikVars
10.12.13
✎
10:19
|
(24) Согласен. Самое лучшее фото - без бикини!
|
|||
26
пипец
10.12.13
✎
10:20
|
(21) + надо понимать что если ТИИ не пройдет то искать придется ошибку руками (SQL-ем)
ЗЫ не все ошибки ТиИ может поправить |
|||
27
Масянька
10.12.13
✎
10:22
|
(24) (25) Вы чего тут орете? :) Человек, однако, уже 5 лет здесь. Так что с фоткой - раньше надо было выступать :))))))))
(19) Ты не обижайся ;) Тут традиция такая - перед особями женского пола, особи мужского пола показывают свои 22 см :)))) |
|||
28
NikVars
10.12.13
✎
10:29
|
(27) Ок. Буду тихо. Раньше было нельзя. Щас точно фотка будет.
А я ничего не показываю - наоборот - прячу. :) |
|||
29
olmi
10.12.13
✎
10:30
|
(27) Ну вот, норм реакция пошла). Правда, я тут не с особями пытаюсь общаться, а с их умом и знаниями). Порой получается). Кстати, ТС можно использовать и для чтения). В том числе мой). Это к вопросу о бикини). Чуть опоздали вы с предложениями). Я пугающую инфу, кажется, убрала, но намекаю - на этом свете живу далеко не 5 лет тут).
(24,26) Базу восстановлю, ТИИ прогоню. Если бред - буду звать спеца. Такое тоже бывало. Всем спасибо большое, в том числе тем, кто сперва обидел, потом развлек!) |
|||
30
NikVars
10.12.13
✎
10:32
|
(29) Ты возможно не так накатила обновление.
Проблема возможно в том, что у измененной базы дубли, к примеру, кода, допустимы, а в типовой - нет. Возможно в изменена уникальность кодов ранее было в пределах справочника, в измененой - в пределах группы. Рой тут. Но фотку жду. |
|||
31
ЧеловекДуши
10.12.13
✎
10:33
|
(27) Она страшная? :)
|
|||
32
NikVars
10.12.13
✎
10:36
|
(31) Как SQL база?!
:) |
|||
33
Масянька
10.12.13
✎
10:36
|
(31) Не знаю.... Может наоборот - ослепляюще красива.
|
|||
34
ЧеловекДуши
10.12.13
✎
10:38
|
(33) Если ослепляюще, то тем более мир должен лицезреть эту красоту :)
|
|||
35
NikVars
10.12.13
✎
10:38
|
(33) Как новый набор ключей для автомобиля?!
|
|||
36
пипец
10.12.13
✎
10:39
|
(29) есть работа с скулем стандартными средствами SQL
(бэкап БД обязательно) http://www.1csql.ru/materials/faq/admin.html?pagenumber=2 http://mitkin.blogspot.ru/2011/07/ms-sql-server.html http://sysadmins.ru/post7982416.html |
|||
37
ЧеловекДуши
10.12.13
✎
10:39
|
(35) Не... как набор освежителя в салон :)
|
|||
38
Mikeware
10.12.13
✎
10:40
|
(16) А что вам не понравилось в тоне?
Вам просто было сказано, что программа сама вам пишет - где именно ошибка. и что md ни при чем. (30) там первичный индекс строится, поэтому область уникальности кода тут ни при чем. |
|||
39
ЧеловекДуши
10.12.13
✎
10:41
|
||||
40
ЧеловекДуши
10.12.13
✎
10:42
|
+(29)Там сборник всех проблем и решений по 1С 7.7 на SQL :)
|
|||
41
NikVars
10.12.13
✎
10:43
|
(38) Возможно. Но что-то инициировало перестройку этого индекса.
|
|||
42
Масянька
10.12.13
✎
10:47
|
(35) Мда... Мужская логика.... :)))))))))))
|
|||
43
olmi
10.12.13
✎
11:05
|
Всем-всем-всем).
1. По делу: попробую выгрузку-загрузку. Если не поможет, попрошу спеца помочь с поиском задвоения в SQL - или чего-то, маскирующегося под задвоение). (36), (39) - спасибо за хелп! Посмотрю все обязательно).(38) - я понимаю, но не знаю пока, что делать). Начну с выгрузки-загрузки. 2. По жизни). Фото могу прислать только многолетней давности - оно устроило бы многих, возможно). Но не буду, ибо поезд ушел, и возвращать не стоит). Спасибо за улыбку). |
|||
44
пипец
10.12.13
✎
11:25
|
(43) если база сильно большая , есть поделка от romix-а для выгрузке/загрузке больших БД
http://sysadmins.ru/post7588839.html |
|||
45
olmi
10.12.13
✎
11:33
|
(44)romix-ом пользуюсь, но спасибо).
|
|||
46
ADirks
10.12.13
✎
11:34
|
(43) Не поможет.
нашёл тут у себя краткое описание проблемы, но и это врядли поможет :) Проблема такая: при обновлении конфигурации на этапе пересчёта перекрёстных ссылок 1С ругается "CREATE UNIQUE INDEX terminated because a duplicate key was found for index ID 2" и умирает. Фишка в том, что она сначала напихивает записей в _1scrdoc, а потом уже создаёт уникальный индекс, который не желает создаваться, т.к. 1С неправильно заполнила таблицу. Не долго думая я залез в 1Cv7.DDS, нашёл там нужный индекс (CHILDID, MDID, PARENTVAL) и вырубил ему уникальность. После повторного запуска конфигуратора обновление завершилось прекрасно. Далее, таким вот запросом SELECT CHILDID, MDID, PARENTVAL, count(*) FROM _1scrdoc GROUP BY CHILDID, MDID, PARENTVAL HAVING count(*) > 1 SELECT * FROM _1sjourn WHERE IDDoc IN ( SELECT CHILDID FROM _1scrdoc GROUP BY CHILDID, MDID, PARENTVAL HAVING count(*) > 1 ) определил, какие документы так жестоко ввели 1С в заблуждение (это оказались выписки). Нашёл эти документы в 1С и перепровёл. Удалил _1scrdoc, включил уникальность обратно, зашёл в 1С - всё зашибись, всё уникально. Вопрос: какого фига? Небольшое исследование показало следующее: в таблице проводок по этим выпискам в поле DocLineNo везде стояло 0, и в поле Date_Time_DocID время было ни разу не такое, как в документе. Но почему так получилось непонятно. После перепроведения всё стало нормально. |
|||
47
olmi
10.12.13
✎
12:24
|
(46) Спасибо большое, идея хорошая. Я сейчас уже общаюсь с одним из ваших коллег, который мне помог в прошлом со SQL-ми проблемами в этой же базе, смотрит, что к чему, с обеда буду в офисе, займемся вплотную, пока по телефону). Когда что-то станет ясно, постараюсь написать, возможно, кому-то пригодится решение.
|
|||
48
olmi
10.12.13
✎
21:33
|
Итак, наши действия.
1. Стандартной процедурой _1sp_DBReindex из Stored Procedures проверили существующую базу на дубли индексов - не нашлось. 2. В DDS в _1scrdoc обнулили Unique у CHILD и PARENT, затем в таблице _1scrdoc отредактировали их же, убрав галочку в Unique values. 3. Запустили обновление правленной базы с 551 на 568 релиз моей болванкой md. Тот же вылет при создании таблицы индексов. Значит, дело не в 1scrdoc. 4. Создали в Enterprise Manager автоматический скрипт для поиска всей информации по индексам, рассчитывая либо в нем найти данные по недоделанным индексам, либо сделать еще одну копию базы, в ней такой же скрипт и сравнить тексты двух скриптов. Время у советчика вышло, завтра продолжим. |
|||
49
ADirks
11.12.13
✎
06:24
|
... сначала напихивает записей в _1scrdoc, а потом уже создаёт уникальный индекс
эта ключевая фраза осталась, очевидно, непонятой |
|||
50
olmi
11.12.13
✎
06:58
|
(49) Не осталась - см.пп.2 и 3. К сожалению, не помогло... Что лучше делать в таком случае, как считаете?
|
|||
51
olmi
11.12.13
✎
07:01
|
(49) Или не надо было в таблице _1scrdoc убирать галочку в Unique values? И что еще стоило сделать не так?
|
|||
52
ADirks
11.12.13
✎
07:28
|
когда обновляется _1scrdoc происходит следующее:
- удаляется 1scrdoc. _совсем_удаляется_ - создаётся пустая _1scrdoc, без индксов - наполняется записями - создаются индексы т.е. все манипуляции с _текущей_ 1scrdoc ни к чему не приведут, и ошибок там нет. Ошибка возникает именно в процессе обновления. И ДДС надо править не _перед_ накатом нового МДшника, а после того, как 1С издохнет. Поправить, и продолжить процесс обновления. Кроме того, таблица возможно и не 1scrdoc - но для выяснения этого факта есть например profiler. |
|||
53
olmi
11.12.13
✎
07:54
|
(52) Принято к сведению. У меня просто нет знаний на этом уровне, а мой советчик сейчас болен, видно, пропустил эту информацию. В 9 позвоню ему и продолжим. Вопрос: исходя из проделанного, можно ли сейчас пойти по этой схеме, т.е поправить DDS и проверять дальше?
|
|||
54
ADirks
11.12.13
✎
07:56
|
Конечно стоит, это позволит найти и устранить проблему.
Естественно, в рабочем режиме такую конфигурацию нельзя использовать. Уникальность индекса нужно восстановить. |
|||
55
olmi
11.12.13
✎
07:59
|
+(52) И не понимаю еще - стоит ли вручную удалить все из таблицы 1scrdoc перед продолжением или надо базу восстановить тестовую с нуля?
|
|||
56
olmi
11.12.13
✎
08:00
|
(54) Конечно, все делается на тестовой базе и весь Ваш текст я помню уже почти наизусть - в том числе о восстановлениии индексов в конце проверок).
|
|||
57
olmi
11.12.13
✎
08:02
|
(54) Ваша помощь очень важна, и информация неоценима!
|
|||
58
ADirks
11.12.13
✎
08:06
|
(55) без разницы, она же заново сгенерируется
|
|||
59
olmi
11.12.13
✎
08:08
|
Все поняла! Сейчас попробую DDS поправить и запустить обновление снова.
|
|||
60
olmi
11.12.13
✎
09:41
|
(58) После правки DDSа обновление прошло!) Ваш запрос выдал пустую табличку, т.е. повторов вроде как нет?! Непонятно тогда, что это было).
Теперь удалять _1scrdoc? Что, саму таблицу удалять, в SQL? |
|||
61
Ёпрст
11.12.13
✎
09:43
|
(46) время поди 23:59:59 было, да ?
:) |
|||
62
Ёпрст
11.12.13
✎
09:43
|
(60) да, можешь её грохнуть и сделать ТиИ (с одной галкой) - восстановится
|
|||
63
olmi
11.12.13
✎
09:45
|
(61) Время вполне такое могло быть). Удаляю табличку _1scrdoc.
|
|||
64
Ёпрст
11.12.13
✎
09:46
|
(63) Я не у вас , а у Алексея спрашивал, хотя, у вас такие записи тоже имеют место быть.
|
|||
65
olmi
11.12.13
✎
09:46
|
(61) Кстати, все время об это время спотыкаюсь). Чем оно чревато, толком объясните нубочке?) Нигде внятного ответа не нашла - от ничем до незнамо чем только)
|
|||
66
Ёпрст
11.12.13
✎
09:49
|
(65) невозможность записать много документов в пределах одной секунды в 23:59:59, после некоего числа, время в проводках и операциях становится другим, чем в 1sjourn .. из-за этого траблы
|
|||
67
Ёпрст
11.12.13
✎
09:50
|
грубо позиция одного документа в этих табличках отличается.
Лечить в скуле, можно тупо тригер навесить, к примеру. |
|||
68
Ёпрст
11.12.13
✎
09:52
|
ну вот, например
http://www.1cpp.ru/forum/YaBB.pl?num=1281425103/8#8 |
|||
69
ADirks
11.12.13
✎
09:59
|
(61) Это было очень давно, не помню. Но скорее всего оно, родимое.
|
|||
70
olmi
11.12.13
✎
10:02
|
(66), (69) Ребята, получилось!!!) Время в доках придется программно исправить). (68) Посмотрю сейчас).
ВСЕМ СПАСИБО ОГРОМНОЕ!!!!!))) И замечательного дня!) |
|||
71
olmi
11.12.13
✎
10:19
|
Ребята, последнее. Мне мой советчик сказал, что в 1 секунду все-таки ограниченное количество доков загнать можно - и не только в 23:59:59. Вроде как то ли тысячу, то ли 10 000... Что скажете, умный народ?)
|
|||
72
olmi
11.12.13
✎
10:23
|
У нас просто в эту базу выгрузка идет из многих источников, и кое-где есть программное распределение доков по периодам дня. Надо знать точные ограничения...
|
|||
73
olmi
11.12.13
✎
10:25
|
В ссылке из (68), кстати, следующее:
Итак, причины: Причина ровно одна - запись нового документа в режиме "в конец дня" при наличии в этом дне документов со временем >= 23:59:50. (в посте по ссылке я немного неверно написал - при изменении времени существующих ошибка не наблюдается). С "большим количеством документов в 23:59:59" никак не связано. Достаточно одного, и даже чуть раньше, чем 59:59. Операция нового документа получает время последний_документ_в_дне + 10 секунд (т.е. от 23:60:00 до 23:60:09) Ошибка возникает в таблице _1SOper и дальше мигрирует по остальным таблицам бух. подсистемы. |
|||
74
Ёпрст
11.12.13
✎
10:31
|
(71) загнать можно - проблема с разной позицией будет + сообщение об ошибке - о невозможности провести документ за ТА..
|
|||
75
olmi
11.12.13
✎
11:43
|
(74) Так есть разумные ограничения - или все свше 1 док в сек чревато?)
|
|||
76
ЧеловекДуши
12.12.13
✎
09:21
|
(71) Лучше так не делай. Документы лучше расфасовать на весь день. Обработкой конечно.
А так, если любят писать вчерашним числом, то лучше всегда ставить текущее время. И проблема исчезнет :) |
|||
77
ЧеловекДуши
12.12.13
✎
09:21
|
(75) Есть ограничения на 23:59:59.
|
|||
78
olmi
12.12.13
✎
17:43
|
(76),(77) Беда в (72). Для бухов безразлично распределение по времени в дне, строго говоря, но доков базе много на день приходится, а на 8-ку только в будущем году перейдем летом. Попробую все приходящее при загрузке раскидывать посекундно, но не уверена, что помещу.
|
|||
79
olmi
12.12.13
✎
19:04
|
А сейчас еще проблема возникла - день в обновленной базе отработали бухи и обнаружили, что разрушилась связь между документами-основаниями и счетами-фактурами на их основании.
В счете-фактуре основанием указана Отгрузка товаров, продукции, по кнопке "О" открывается, т.е рекв.ДокументОснование в порядке. Лезу в Отгрузку - журнал подчиненных документов пуст. Еще фокус: в доке ЗаписьКнигиПокупок в поле Основание - Счет-фактура. Документ-основание-Выгрузка. Это уже фокусы нестандартной обработки загрузки из другой базы. Пытаюсь по кнопке с "..." открыть основание - вываливается пустой журнал счетов-фактур. Отдельно он открывается нормально, счета-фактуры на месте. Что делать? |
|||
80
Ёпрст
12.12.13
✎
19:05
|
прибить 1crcdoc сделать тии
|
|||
81
Ёпрст
12.12.13
✎
19:05
|
с одной галкой
|
|||
82
olmi
12.12.13
✎
19:07
|
(80),(81) Я при загрузке делала же так. Повторить? И прибить - это удалить и сделать Тии с одной галкой, восстановив индексы?
|
|||
83
Ёпрст
12.12.13
✎
19:09
|
нет.. если дбф - удалить файл, если скуль - truncate table
далее в Тии , галка пересчет служ. данных. |
|||
84
olmi
12.12.13
✎
19:14
|
Скуль. Что такое truncate table и как это сделать в Enterprise manager? - я в скуле почти нуль.
|
|||
85
olmi
12.12.13
✎
19:14
|
(84) для (83)
|
|||
86
МихаилМ
12.12.13
✎
19:18
|
(84)
http://yandex.ru/yandsearch?clid=9582&text=truncate+table+ms+sql&lr=213 http://images.yandex.ru/yandsearch?source=psearch&text=Enterprise%20manager%20ms%20sql&fp=0&pos=0&rpt=simage&lr=213&uinfo=ww-1390-wh-734-fw-1165-fh-528-pd-1&img_url=http%3A%2F%2Fwww.quackit.com%2Fpix%2Fdatabase%2Ftutorial%2Fdbms_sql_server.gif |
|||
87
Ёпрст
12.12.13
✎
19:18
|
(84) сделай копию, затем в QA выполни
TRUNCATE TABLE dbo._1SCRDOC усё.. |
|||
88
olmi
12.12.13
✎
19:50
|
(86) 2-я и 4-я ссылки не читаются, и разбирать сейчас поздно, мне бы точные пошанговые инструкции на этот раз. Понимаю, что с моей стороны нехорошо это просить, но деваться мне некуда. Обязуюсь после завершения этой истории все внимательно прочитать!)
(84) Сделаю, потом напишу, что получилось. |
|||
89
olmi
12.12.13
✎
21:09
|
(84),(86) Так. Копию базы мне сделали, могу работать. Теперь : стоит ли мне перед началом TRUNCATE прогнать обработку по изменению времени доков, которые в 23:59:50-23:59:59, на, скажем, 23:59:49? Или опять будут проблемы? Таких документов очень много.
|
|||
90
olmi
12.12.13
✎
21:12
|
+(89) Или надо распределить все доки по секундам, а, если секунд не хватит, хвост на 23:59:49? Но я не могу трогать закрытые периоды, а база с начала 2012 года... Перепроводить не могу. А кривизна операций и проводок ведь при проведении?
|
|||
91
olmi
12.12.13
✎
21:13
|
(+89) Я про кривизну времени.
|
|||
92
Ёпрст
13.12.13
✎
06:43
|
(90) можно в скуле проапдейтить табличку, чтоб позиция дока была такой же, как в _1sjourn
|
|||
93
olmi
13.12.13
✎
10:07
|
(92) Как я поняла, придется менять время документов, операций и проводок в закрытых периодах.
Можно ли при этом обойтись без перепроведения, чтобы не посыпались данные в закрытых периодах? Какие таблички в SQL при этом и как стоит поменять, причем так, чтобы не посыпался 1С? |
|||
94
Ёпрст
13.12.13
✎
10:34
|
(93) _1sentry/_1soper + файло итогов пересчитать потом
|
|||
95
ADirks
13.12.13
✎
11:20
|
Вот, нашёл тут :)
///******************************** ADirks 03.10.2013 ************ Функция сзТаблицы() сз = СоздатьОбъект("СписокЗначений"); сз.ДобавитьЗначение("_1SACCSEL"); сз.ДобавитьЗначение("_1SENTRY"); сз.ДобавитьЗначение("_1SOPER"); сз.ДобавитьЗначение("_1SSBSEL"); Возврат сз; КонецФункции Функция тзПроводки() ТекстЗапроса = "Set NoCount ON | |-- Время проводки не совпадает с временем документа | |select | Right(_1sJourn.Date_Time_IDDoc, 13) [Doc $Документ], | _1sjourn.IdDocDef, | _1sjourn.IDDoc, | _1sjourn.DocNo, | _1sjourn.Date_Time_IDDoc, | _1sentry.Date_Time_DocID, | count(*) |from | _1sjourn (nolock) | INNER JOIN _1sentry (nolock) ON (_1sjourn.IDDoc = _1sentry.DocID) |where | _1sjourn.Date_Time_IDDoc <> _1sentry.Date_Time_DocID |GROUP BY | _1sjourn.Date_Time_IDDoc, | _1sentry.Date_Time_DocID, |-- Right(_1sJourn.Date_Time_IDDoc, 13), | _1sjourn.IdDocDef, | _1sjourn.IDDoc, | _1sjourn.DocNo |"; тз = ЗапросСКЛ.ВыполнитьИнструкцию(ТекстЗапроса); Возврат тз; КонецФункции Функция тзТаб(Имя) ТекстЗапроса = "Set NoCount ON | |-- Время проводки не совпадает с временем документа | |select | Right(_1sJourn.Date_Time_IDDoc, 13) [Doc $Документ], | _1sjourn.IdDocDef, | _1sjourn.IDDoc, | _1sjourn.DocNo, | _1sjourn.Date_Time_IDDoc, | "+Имя+".Date_Time_DocID, | count(*) |from | _1sjourn (nolock) | INNER JOIN "+Имя+" (nolock) ON (_1sjourn.IDDoc = "+Имя+".DocID) |where | _1sjourn.Date_Time_IDDoc <> "+Имя+".Date_Time_DocID |GROUP BY | _1sjourn.Date_Time_IDDoc, | "+Имя+".Date_Time_DocID, |-- Right(_1sJourn.Date_Time_IDDoc, 13), | _1sjourn.IdDocDef, | _1sjourn.IDDoc, | _1sjourn.DocNo |"; тз = ЗапросСКЛ.ВыполнитьИнструкцию(ТекстЗапроса); Возврат тз; КонецФункции ///******************************** ADirks 03.10.2013 ************ Процедура Показать() сз = сзТаблицы(); Для н = 1 По сз.РазмерСписка() Цикл Имя = сз.ПолучитьЗначение(н); тз = тзТаб(Имя); тз.Сортировать("Doc", 1); РедакторТЗ(тз, Имя); КонецЦикла; // //тз = тзПроводки(); //тз.Сортировать("Doc", 1); //РедакторТЗ(тз); КонецПроцедуры Процедура Выправить() сз = сзТаблицы(); Для н = 1 По сз.РазмерСписка() Цикл Имя = сз.ПолучитьЗначение(н); тз = тзТаб(Имя); РедакторТЗ(тз, Имя); тз.ВыбратьСтроки(); Пока тз.ПолучитьСтроку() = 1 Цикл ЗапросСКЛ.Выполнить("Set NoCount ON |UPDATE "+Имя+" | Set Date_Time_DocID = '"+тз.Date_Time_IDDoc+"' |WHERE | DocID = '"+тз.IDDoc+"' |"); КонецЦикла; КонецЦикла; КонецПроцедуры |
|||
96
Ёпрст
13.12.13
✎
11:26
|
(95) ну, тесты проверок, в своё время кто тока не писал :))
В одну кучку Z1 собирал.. в своё время на 1cpp валяются |
|||
97
Ёпрст
13.12.13
✎
11:27
|
чорт, не заметил про update внизу
.. |
|||
98
ADirks
13.12.13
✎
11:45
|
Мне быстрее написать, чем найти готовое :)
|
|||
99
olmi
13.12.13
✎
12:17
|
(94), (95) Ребята, милые вы мои, дорогие, спасибо огромное за помощь!) Сейчас посмотрю тексты процедурок).
Только закончила вразумлять бухов). |
|||
100
olmi
13.12.13
✎
12:18
|
(98) А Вам мне просто в ножки поклониться надо!) Как это ни выглядит смешным сегодня - но хочется!)
|
|||
101
olmi
13.12.13
✎
12:33
|
(95) 1. Что за РедакторТЗ(тз, Имя)? Не наблюден.
2. При просмотре наискось показалось, что время документа правится по времени операции. Для ситуации с 23:59:50+ операции записаны на незнамо когда. Надо бы наоборот - операцию к документу привязать)... Возможно ли это?) Естественно, документы перед этим поднять на пораньше, причем их надо записать, но не перепроводить - в закрытых периодах... |
|||
102
ADirks
13.12.13
✎
12:41
|
РедакторТЗ() - человеческая замена для тз.ВыбратьСтроку()
можно произвести обратную замену вообще-то в данном случае во все таблички пишется дата-время из _1sjourn. Подозреваю, что в принципе без разницы что к чему приводить, лишь бы одинаково было. |
|||
103
olmi
13.12.13
✎
13:05
|
(102)Ага, значит, можно и в операциях менять?) Уррряяяя!) А то ж закрытые же ж периоды же ж)... Через полчасика возьмусь).
|
|||
104
olmi
13.12.13
✎
13:06
|
(102) А это все можно делать под сервером скульным 2000?) Я так поняла, что да?)
|
|||
105
ADirks
13.12.13
✎
13:25
|
Ну да, можно операции, и для SQL.
Собственно, это боевая обработка, коей мы обнаруженный косяк правили. |
|||
106
olmi
13.12.13
✎
14:02
|
(105) А что за ЗапросСКЛ и ВыполнитьИнструкцию?
|
|||
107
МихаилМ
13.12.13
✎
14:17
|
||||
108
olmi
13.12.13
✎
14:48
|
(107) Хорошо, неправа насчет ВыполнитьИнструкцию. А как определить ЗапросСКЛ? Код ругается. В гугле про запрос СКД только вижу. Ругай, переживу, только поверни в нужнгую сторону. Это же не 1Совский запрос.
|
|||
109
olmi
13.12.13
✎
14:50
|
(108) И, потом, ВыполнитьИнструкцию - это 1С++? У меня не установлен.
|
|||
110
Ёпрст
13.12.13
✎
14:51
|
(108)
ЗапросСКЛ = СоздатьОбъект("ODBCRecordSet"); |
|||
111
Ёпрст
13.12.13
✎
14:52
|
(109)
ЗагрузитьВнешнююКомпоненту("1cpp.dll") воткни перед этим |
|||
112
МихаилМ
13.12.13
✎
14:59
|
(108)
Вам привели пример. Ваша задача адаптировать его. соответственно пример написан на чистом tsql. и для его исполнения достаточно иметь ms SQL Query Analyzer либо любой другой инструмент, позволяющий исполнять запросы. |
|||
113
olmi
13.12.13
✎
15:02
|
(110),(111) Вот это другое дело). Сделаю).
(112) И так попробую. |
|||
114
olmi
20.12.13
✎
11:03
|
Ребята, простите, что так надолго замолчала. Начальник уходил в отпуск, и, раз сразу не получилось, не стал рисковать и вернул базу, в которой ваяли сутки, на место. Мне пришлось разбираться и восстанавливать информацию.
Теперь пора заняться основной темой).Я посмотрела код в 95, и вижу, что им можно воспользоваться напрямую, спасибо огромное! Но есть один вопрос: поскольку много доков на 23:59:59, то не стоит ли прежде прибивания операций и проводок к ним поменять их время? И можно ли это сделать прямо в 1Се для закрытых периодов - т.е.перезаписать с другим временем без перепроведения и потом прибить к ним все SQLем? Или, учитывая кривость таблиц, лучше все сделать SQLем? Если да, то как поменять им время? Не скажется ли UPDATE таблиц из сзТаблицы() еще на чем-то 1Свском? Потому что сделать запрос по образцу я смогу, а вот дальше боязно)... |
|||
115
Ёпрст
20.12.13
✎
11:05
|
(114) проапдейтить таблички.. это фигня.. тебе придётся потом бух итоги пересчитать.
|
|||
116
Ёпрст
20.12.13
✎
11:06
|
на счет исправления времени в табличках проводок - вам Алексей постами выше дал рабочий код..
|
|||
117
olmi
20.12.13
✎
11:07
|
Итоги все же в 1Се пересчитывать). А вот что можно и нужно апдейтить-вот вопрос). Хотя)... В прошедших-то периодах отчеты сданы)... А итоги пересчитывались несколько месяцев назад)... Что, по-любому плёхо, однако?)
|
|||
118
Ёпрст
20.12.13
✎
11:08
|
По мне, я бы исправил всё и пересчитал всё.
|
|||
119
olmi
20.12.13
✎
11:09
|
(116) Я про код написала-код замечательный). Но он для прибивания операций и проводок к докумен6там, а мне прежде время доков менять надо). Об этом и страх)
|
|||
120
olmi
20.12.13
✎
11:10
|
(118) Конечно, все до ума доводить надо). Вопрос - время доков из 1Са менять или все сделать SQLно, добавив в код про сдвиг доков?
|
|||
121
olmi
20.12.13
✎
11:11
|
И потом пересчитать итоги...
|
|||
122
olmi
25.12.13
✎
16:39
|
Ребята, я все перечитала, мне помогают с написанием процедур на SQL, но, все-таки не все понимаю еще. Базу вернули в исходное состояние, до обновления. Сейчас мне надо сперва обновить - попасть на ошибку - убрать уникальность в DDSе - закончить обновление - удалить _1scrdoc - сделать ТИИ с 1 галкой - включить уникальность обратно (или сперва включить уникальность, а потом ТИИ?, или TRUNCATE TABLE dbo._1SCRDOC и далее в Тии , галка пересчет служ. данных?). И потом SQL-й процедурой подтянуть время документов в 1sjourn, а потом к ним привязать _1SACCSEL, _1SENTRY, _1SOPER, _1SSBSEL? В середине путаюсь, про обновление. Помогите еще раз, очень прошу!
|
|||
123
olmi
25.12.13
✎
16:40
|
(122)+ Или вообще сперва наладить время документов, а уж потом обновлять?
|
|||
124
ADirks
25.12.13
✎
16:46
|
(123) Попробуй для начала запустить тот скрипт, который я приводил, и накатывай обновление. Вроде должно сработать.
С временем остальных доков я бы не заморачивался. |
|||
125
olmi
25.12.13
✎
17:12
|
(124) Скрипт из (95)? До обновления? Или все же сперва обновить-ошибка-убрать уник.-законичть обновление-TRUNCATE TABLE dbo._1SCRDOC-пересчет служ.данных?
А насчет времени остальных доков не все так просто. Если связь доков с операциями и проводками разорвана из-за того, что из в 23:59:59 в какие-то даты собралось слишком много, скажем, больше 10000, то в новых доках, формирующих проводки, и записанных в эти даты, опять разорвутся связи с проводками и операциями. Поэтому и хочу поднять их с 01:00:00, как в одном месте рекомендовалось. Причем делать это придется скульно, чтобы не перепроводить доки в закрытых периодах. А потом то ли пересчитывать итоги, то ли они встанут на место при пересчете служебных данных - тоже хочу уточнить... Ведь доки буду поднимать в том же порядке и в пределах той же даты, так что итоги не должны полететь как бы? |
|||
126
ADirks
25.12.13
✎
17:27
|
Ага, из (95), до обновления. Все те манипуляции с уникальностью индекса на самом деле были проделаны, чтобы быстренько обновиться, а потом уж разбираться. Если исправить ситуацию до, то во время обновления проблем уже не будет.
Что касается дофига документов в одно время, то мы, например, на это начхали, просто сделали триггер, правящий ситуацию в момент записи (где-то ранее была ссылка на эту тему на 1cpp.ru). Можно и без триггеров, перед обновлением каждый раз скриптом время в операциях править. |
|||
127
olmi
25.12.13
✎
17:31
|
(126) А без обновления этот разрыв нам нервы трепать не будет? На итоги это не повлияет?
|
|||
128
olmi
25.12.13
✎
17:33
|
(127)+ Триггер этот я видела. Но у нас не стоит 1Срр, и ставить ее я не рискую - малейший сбой, и меня убьют тумбочкой. Поэтому готова только на разовые правки, пусть и перед каждым обновлением). Недолго мучиться - следующим летом, наконец, переводим все на восьмерку)
|
|||
129
olmi
25.12.13
✎
17:35
|
(126) И еще: то, что проблема с разрывом связей между счетами-фактурами и ЗаписьюКнигиПокупок однозначно отсюда - ясно, а вот такая фигня еще? обнаружили бухи, что у некоторых контрагентов в Выписках не тот договор оказался. Причем во всех. Может ли это тоже быть из той же кашки?
|
|||
130
ADirks
25.12.13
✎
17:39
|
(127) В том то и дело, что ни на какие итоги не влияет. Я, честно говоря, сильно удивился, когда стали смотреть что к чему, и выяснили, что документов с одинаковым временем - до чёрта. Т.е. прям полностью идентичные части Date_Time в Date_Time_IDDoc.
(129) насчёт разрывов я бы не был так уверен - там время вроде ни при чём. Что касается договоров, так это достаточно распространённая ситуация, связанная с кривизной ручек 1Снегов из 1С. |
|||
131
olmi
25.12.13
✎
17:43
|
(130) Насчет разрывов, как мне кажется - дело в нарушении связей как раз между документами-основаниями и подчиненными, т.е. в нашей любимой табличке, нет? Этого до обновления ведь не было...
А вот с договорами что делать мне, бедной?) Убьют ведь, а Новый Год на носу)... |
|||
132
ADirks
25.12.13
✎
17:52
|
Ну так то да, если _1scrdoc криво заполнилась, то ВыбратьПодчиненныеДокументы() тоже будет криво работать. Но тут ничего не могу сказать, лечение по фотографии не мой профиль.
С договорами вообще сложно. Надо прям с каждой конкретной ситуацией разбираться. Причём вопрос из чисто технического становится организационно/бухгалтерским. |
|||
133
olmi
25.12.13
✎
17:55
|
(132) Пока пришью операции и проводки, обновлю, а там посмотрим по месту). Значит, итоги при таком раскладе не трогаем?) Ура!)
|
|||
134
olmi
25.12.13
✎
17:56
|
(132) Для начала - очередное огромное спасибо!)
|
|||
135
ADirks
25.12.13
✎
17:58
|
Ну там, ура не ура, а попробовать надо. Время, судя по всему, есть :)
|
|||
136
olmi
09.01.14
✎
17:47
|
(135) Дошли до дела, наконец-то). Написана процедурка в SQL, которая прибивает время в _SACCSEL,_1SENTRY,_1SOPER,_1SSBSEL по _1sJourn.
Стало ясно, что после обновления бухи начнут править и создавать новые документы в прошлых датах, где все прибито будет, но время 23:59:50+ у доков останется, и мы опять получим тот же компот. Посмотрела триггер из (68). В нем по событию такому правится только _1SOPER, причем время, если оно бредово, заменяется на 23:59:59, как я поняла... Вопросы: 1) Надо ли править остальные 3 таблички аналогично или, по (73), ошибка возникает в _1SOPER и потом мигрирует по остальным таблицам? В какой момент мигрирует тогда? После отработки триггера? 2) Не повлияет ли это действо еще на какие-то вещи в базе? На таблицы, вроде, нет, я просмотрела DDS... 3) Что делать с _1scrdoc и когда? Удалять, TRUNCATE? Мозги окончательно всмятку. |
|||
137
olmi
09.01.14
✎
17:58
|
(136) Еще момент: база была обрезана, т.е. были на начало 2012 года созданы начальные остатки, а все старье помечено на удаление. Сейчас в _1sJourn моей помощницей в SQL обнаружено в 2011, помеченном на удаление, году, у ряда документов бредовое время - больше 23:59:59 в 36-ричной системе. Те годы не волнуют, но возможно ли повторение такого в текущих годах? Если да, то стоит ли повесить триггер аналогичный и на _1sJourn? Если да, то скажется ли это сильно на производительности?
Ради подробного ответа согласна на любые сомнения в качестве моей ДНК!) |
|||
138
МихаилМ
09.01.14
✎
17:59
|
(137)
на сколько больше ? |
|||
139
olmi
09.01.14
✎
18:14
|
(138) Вопрос непонятен.
|
|||
140
МихаилМ
09.01.14
✎
18:20
|
(139)
на сколько сенкунд (10 тысячных секунды) больше чем 23:59:59 в 36-ричной системе вполне возможно, что это время в пределах 1 секунды |
|||
141
olmi
09.01.14
✎
18:22
|
(140) Сейчас посмотрим.
|
|||
142
olmi
09.01.14
✎
18:42
|
Вот что найдено:
полный день в долях секунд = 864000000 В _1SACCSEL имеем EAGG40 = 864090000. Полностью строка: 5562356 518 3Z2 15T2D 20120531EAGG40 15T2D 0 0 В _1sJourn: 1154418 45264 OWJ3 45164 20 20110111WKESG OWJ3 451642011 07-0000015 4 1 0 4 int=1969200000 Дальше коммент программиста SQL: Возможно, в 11 году по-другому считывалось время 20110111WKESG, и по новым правилам должно быть написано так: 20110111 WKESG тогда это не ошибка. Мой коммент: 1Са она не знает, сишник. |
|||
143
olmi
09.01.14
✎
18:55
|
(140) Ответ в (141). Но писала вслед за сишником, второпях. Вижу, что ее коммент не в тему, главное, что время бредовое есть и в _1sJourn/
|
|||
144
МихаилМ
09.01.14
✎
19:38
|
(143)
что скажет РазобратьПозициюДокумента("20120531EAGG40 15T2D",Дата, Час, Мин , Сек, Документ) ? |
|||
145
olmi
09.01.14
✎
20:35
|
(144) Прости, что не сразу отвечаю - переключилась на подготвку болванки 570 релиза.
Код: //Перем ДатаДока, Ч, М , С, Док; ДатаДока='01.01.01'; Ч="";М="";С=""; Док=ПолучитьПустоеЗначение("Документ"); Позиц=РазобратьПозициюДокумента("20120531EAGG40 15T2D",ДатаДока, Ч, М , С, Док); Сообщить("Позиция = "+Позиц+"; ДатаДокумента = "+ДатаДока+"; Ч = "+Ч+"; М = "+М+"; С = "+С +"; Документ = "+Док); Ответ: Позиция = . . 00:00:00; ДатаДокумента = . . ; Ч = 0; М = 0; С = 0; Документ = Одинаково - через Перем или явно нач.значения задавать. |
|||
146
olmi
09.01.14
✎
20:37
|
(144) Правда, это я в боевой базе смотрела, а она работала в копии непосредственно на SQLе. Причем копия была создана не по нашим правилам, а чисто скульная. Возможно, это неважно, но попрошу завтра (сегодня она уже ушла) посмотреть то же самое в моей тестовой базе, и там прогоню этот пример, если ошибка обнаружится.
|
|||
147
ADirks
09.01.14
✎
20:44
|
(136) насчёт триггера, вроде же Паша всё расписал в той теме на 1cpp?
В том то и прикол, что для доков с операциями date_time_iddoc берётся из _1soper, а вовсе не из _1sjourn. Это "немного странно", но факт. Именно поэтому триггер и навесили на _1soper - достаточно там исправить, дальше само разойдётся. Насчёт crdoc ничего сказать не могу - не исследовали за ненадобностью. |
|||
148
olmi
09.01.14
✎
20:55
|
(147) Т.е. время формируется в _1SOPER при записи документа, триггером правится, и при проведении остальные таблички цепляются за _1SOPER? И почему в _1SOPER ставим триггером время не такое, как в журнале, а просто конец дня?
И насчёт crdoc - мне неясно, как с ней быть - там есть дата и время подчиненных доков. Если я перед обновлением прибью все существующее к _1sjourn по 4 табличкам, что, сразу обновление запускать, и crdoc просто пересчитается? А итоги надо пересчитывать после приколачивания или после обновления? Или при таком раскладе все и так будет замечательно?) |
|||
149
olmi
09.01.14
✎
21:00
|
(147)+ Прошу прощения за занудство - слишком многое на кону, это наша основная база, а сейчас пора отчетности. Я, конечно, тестю, но все проверить невозможно же... А база и так еле жива - например, в конце декабря вдруг в Выписках в текущем, старом релизе бухи не смогли выбирать субконто... Я еще не смотрела, в чем дело, тоже отдохнуть решила в каникулы, сегодня взялась за все).
|
|||
150
olmi
09.01.14
✎
22:09
|
(147)+ Еще раз перечитала все, вроде правильно понимаю?). Для верности пишу еще раз). 1. Меняю время в 4 табличках по _1sjourn. 2. Вешаю триггер на _1SOPER. 3. Обновляю. 4. Пересчитываю итоги. Все правильно?)
|
|||
151
ADirks
09.01.14
✎
22:16
|
(150) Почти так. Триггер лучше вешать после обновления, потому что 1С может его и прибить (не проверял, у нас все триггера тупо пересоздаются после каждого обновления).
Что касается crdoc, то попробую завтра посмотреть, чего там происходит. |
|||
152
olmi
10.01.14
✎
07:53
|
(150)+ Напрягло бредовое время в (142) - и в помеченном на удаление 2011 году в _1sJourn, и в рабочем 2012 году в _1SACCSEL. Ну ладно, во втором случае оторвалось все, а в журнале? Как 1С обрабатывает пометку на удаление в документах? База обрезана, все до 2012 года помечено на удаление, я писала в (137). Что делать, если бред со временем в журнале? База бухгалтерская, вроде как не очень важно, что когда в течение суток, но все же они ручками всегда переставляют приходы прежде расходов...
(151) Жду про crdoс - и заранее благодарна за любую инфу, вообще Вы меня капитально выручили уже, Алексей, спасибо! Очень большое! |
|||
153
olmi
10.01.14
✎
07:55
|
(151) Пост (152) адресован Вам). Ошиблась).
|
|||
154
ADirks
10.01.14
✎
11:08
|
Как ни странно, в crdoc всё пучком пишется, даже и без всяких триггеров. Башню сносит только при перезаполнении.
|
|||
155
Ёпрст
10.01.14
✎
11:19
|
ё..
порабы было ужо давно забить на эту базу :)) |
|||
156
olmi
10.01.14
✎
11:26
|
(154) А что Вы думаете про бредовое время в помеченных на удаление доках в _1sJourn?
(155) Это как?) Дело не доделано, есть вопросы, знания я получаю только в этой ветке нужные. Да, медленно, прошу прощения. Но, будь я корифеем, вопросов и не было бы). В любом случае, спасибо за советы!) В этот раз очень помог Алексей, в другие разы Вы давали замечательные советы, за что я очень благодарна!) А сколько мне помог Михаил, это вообще слов нет... Спасибо вам, дорогие, что не плюете на нас с высокой1 горки своих знаний и умений!) Теперь, порой, по мелочи, и я кому-то помогаю)... |
|||
157
ADirks
10.01.14
✎
12:29
|
>А что Вы думаете про бредовое время в помеченных на удаление доках в _1sJourn?
я бы оставил как есть |
|||
158
olmi
10.01.14
✎
12:57
|
(157) Еще раз о прошлых годах. До 2012 года все доки в базе помечены на удаление или сделаны непроведенными. В 4 табличках вся инфа по ним есть, но, насколько я понимаю, невидима для 1С. Вижу, что при изменениях в доке (проведен-непроведен-помечен на удаление) время в табличке журнала не меняется.
Вопрос: прибивать ли время к журналу в 4 табличках и за те годы? Не повлияет ли это на что-то? Насколько я поняла, нет и можно сплошь таблички прибивать? И как быть, если в журнале время бредовое? Это только в прошлые годы бывало. Его подправлять на конец дня - все равно непроведенные доки? |
|||
159
olmi
10.01.14
✎
13:13
|
(157)+ Понимаю, что надо по-любому за весь период все прибивать, иначе таблица ссылок при обновлении сыпанется. Вопрос, что делать, если в журнале время бредовое? То ли брать в этом случае за основу время из таблицы операций, а, если и там бред - в конец дня, то ли все в конец дня? Насколько я поняла, такое бывало только в ненужных годах...
|
|||
160
Ёпрст
10.01.14
✎
13:26
|
(158)можешь вообще прибить эти доки.. насовсем, если ссылок по ним нигде нет.
|
|||
161
Ёпрст
10.01.14
✎
13:27
|
+159 в табличке операций.. нет строчек с доками, помеченными на удалени или не проведенными.
|
|||
162
olmi
10.01.14
✎
13:58
|
(161) там нет, а в табличках проводок и т.д. есть, потому и спросила.
(160) Да, это обязательно сделаю. |
|||
163
olmi
10.01.14
✎
14:01
|
(160)+ Кстати, ссылки в скле где смотреть - в crdoc? Или где-то еще? А то через 1С долго искать.
|
|||
164
ADirks
10.01.14
✎
14:04
|
(163) например
http://infostart.ru/public/60727/ |
|||
165
olmi
10.01.14
✎
14:50
|
(164) Чего-то не пускает, пароль, видно, забыла. А можно сюда линкануть?)
|
|||
166
ADirks
10.01.14
✎
16:42
|
||||
167
olmi
10.01.14
✎
16:57
|
(166) И тут требует авторизации, или не читает. Попробую дома вечером из Оперы, что-то тут Эксплорер барахлит к тому же). В любом случае, спасибо большое!) Прошу прощения, что не сразу отвечаю - болванку готовила для обновления на 570).
|
|||
168
МихаилМ
10.01.14
✎
17:26
|
теперь ждем мучений по работе с 1с++...
и еще через месяц-другой (постов 300) ... увольнения |
|||
169
olmi
10.01.14
✎
17:30
|
(168) Ты о чем? С 1С++ работать мне нельзя в этой базе, поэтому все процедуры написаны в SQL. Если все сработает, все нормально. А если нет, и даже если меня уволят, что маловероятно, то зачем так?
|
|||
170
МихаилМ
10.01.14
✎
17:36
|
(169)
стеб по поводу количества времени и постов этой ветки. |
|||
171
МихаилМ
10.01.14
✎
17:40
|
+ (170)
кстати сегодня месяц, как создана тема |
|||
172
olmi
10.01.14
✎
17:52
|
(170) И что? И зачем стеб? Жаль.
|
|||
173
МихаилМ
10.01.14
✎
18:06
|
(172)
"Жаль" не сотвествует (108) |
|||
174
olmi
10.01.14
✎
18:52
|
(173) Соответствует, но не теме ветки, а другой теме. Но об этом я больше не пишу.
|
|||
175
olmi
10.01.14
✎
18:53
|
Ребята, существенно ли по каким-либо параметрам, где делать пересчет итогов - в режиме Предприятия или в Конфигураторе?
|
|||
176
olmi
10.01.14
✎
18:55
|
На тестовой базе все обновилось, осталось итоги пересчитать и добавить триггер). Всем помогавшим спасибо огромное!) Ну и надо проверить, конечно, не вылезет ли еще какая-нибудь бяка). Дай Бог, чтобы все прошло благополучно).
|
|||
177
olmi
10.01.14
✎
20:03
|
И еще: нашла ссылку еще с 2009 года, что под 25 релизом - а у нас именно он - полный пересчет итогов может глючить под 25 платформой, а у нас именно она, и в любом случае, работает очень медленно. И что есть некая процедура чисто SQL-я, которая может быстро итоги пересчитать. Есть ли у кого-то информация по этому поводу?
Сразу - 27 релиз предлагала поставить 100 лет назад, но из-за сложностей работы с удаленными базами на это не пошло мое начальство. Теперь уже важно все добить и с весны начать все переводить на восьмерку. И еще: Я обновила, но переиндексацию не делала, сразу запустила полный пересчет итогов в режиме Предприятия. А сейчас думаю - может, надо было сперва восстановить crdoc? И вообще итоги считать в Конфигураторе или найти быструю и более верную скульную процедуру? |
|||
178
МихаилМ
10.01.14
✎
20:16
|
(177)
зачем нужен пересчет итогов, если в результате Ваших исправлений итоги не должны были поменяться. |
|||
179
olmi
10.01.14
✎
20:32
|
(178) Я тоже так думала, но... последние посты см. (150), (151). И до того было.
|
|||
180
МихаилМ
10.01.14
✎
20:32
|
вот загатовка для обработки пересчета би
http://softpoint.ru/article_id46.htm |
|||
181
МихаилМ
10.01.14
✎
20:37
|
(179)
" пересчет служ. данных" <> "пересчет БИ" "И до того было" - про пересчет пересчет БИ не было советов. |
|||
182
olmi
10.01.14
✎
20:58
|
(181): (94), (115), (117), (118), (150)-(151).
Но, кстати, итоги пересчиталлись аккуратно, с боевой базой совпадают. |
|||
183
olmi
10.01.14
✎
21:00
|
(181)+ А вот насчет пересчета служебных данных не было речи, если 4 таблички (операции и проводки со всеми связями) прибиваются к журналу.
|
|||
184
МихаилМ
10.01.14
✎
21:09
|
(182)
хорошо. совет про пересчет БИ был. |
|||
185
ADirks
10.01.14
✎
21:11
|
Для пересчета итогов по регистрам, и двиганья ТА в НЕмонопольном режиме есть такая штука: УстановкаТА, исходный вариант здесь: http://www.dev.citykirov.ru/
её потом кто-то допиливал, на предмет (кажется) оборотных регистров, и измерений с типом Неопеределено где качать найти теперь не могу, положил на http://rusfolder.com/39432040 |
|||
186
МихаилМ
11.01.14
✎
00:02
|
(185)
для пересчета регистров есть обработки на 1cpp и infostart а вот для БИ - не встречал. |
|||
187
olmi
11.01.14
✎
01:19
|
(185), (186) Я их нашла, там и про БИ что-то есть, но, не разобрав, и не проверив, использовать пока не рискую. Запустила обычный пересчет в режиме Предприятия. Долгий он, правда...
|
|||
188
olmi
11.01.14
✎
01:51
|
Все завершено, триггер на месте. Утром бухи начнут работать, станет ясно, как у них дела. Ушла отдохнуть до утра)...
|
|||
189
КонецЦикла
11.01.14
✎
01:55
|
(185) Спасипки
|
|||
190
olmi
13.01.14
✎
16:55
|
Ну вот, вроде все ОК). Всем огромное спасибо за помощь!) Чтоб у вас все всегда получалось, ребята!!!)
|
|||
191
Ёпрст
13.01.14
✎
16:57
|
(190) более правильно этот тост надо говорить так:
"дай бог вам между ног крепкого здоровья!" |
Форум | Правила | Описание | Объявления | Секции | Поиск | Книга знаний | Вики-миста |