-
-
Обсуждения на сайте Альта-Софт
-
SQL база ГТД. Сиквестирование базы. Вопросы.
Модераторы: Renat, Gala, alta_olg, expert, Lemur
Re: SQL база ГТД. Сиквестирование базы. Вопросы.
ну резонно. я просто в таких манипуляциях уже себя боюсь пользователям конечно на откуп отдавать этот кусок работы не будем. Но разработать рекомендованную систему работы с БД было бы нам всем полезно.
скрипт для очистки ЭД-сообщений за период уже есть. Может быть тогда добавить к нему скрипт на конкретную дату ? т.е. "удалить все ЭД-сообщения созданые ранее такого_то_числа " ? и еще добавить скрипт в коллекцию который бы чистил все базу ГТД "до такого то числа". Как мысль? исключительно для администратора.
Делаем бекап базы на сегодняшнее число и в текущей базе удалем все что было раньше "скажем так" сегодняшнего числа
скрипт для очистки ЭД-сообщений за период уже есть. Может быть тогда добавить к нему скрипт на конкретную дату ? т.е. "удалить все ЭД-сообщения созданые ранее такого_то_числа " ? и еще добавить скрипт в коллекцию который бы чистил все базу ГТД "до такого то числа". Как мысль? исключительно для администратора.
Делаем бекап базы на сегодняшнее число и в текущей базе удалем все что было раньше "скажем так" сегодняшнего числа
-
- Почетный участник
- Сообщения: 101
- На форуме: c 06 ноя 2004
- Откуда: Альта-Софт
Сказал: 0 ед.
Получил: 20 ед.
Получил: 20 ед.
Re: SQL база ГТД. Сиквестирование базы. Вопросы.
По поводу удаления ЭД-сообщений ранее конкретного числа - запрос ровно такой же, просто дату в формате YYYYMMDD надо использовать:
По поводу удаления документов ранее какого-то числа - тоже мысль правильная - именно эти две функции мы и хотели реализовать в виде меню Сервис/Чистка базы, но вот все никак руки не дойдут у наших товарищей
Сейчас на вскидку запрос не хочу писать - тут как раз надо подумать, что считать датой документа... возможно чистить надо не одну таблицу... и т.д.
Это у нас остается висящей задачей...
Код: Выделить всё
DELETE FROM EdMsgs WHERE PreparationDateTime < '20100630'
Сейчас на вскидку запрос не хочу писать - тут как раз надо подумать, что считать датой документа... возможно чистить надо не одну таблицу... и т.д.
Это у нас остается висящей задачей...
С уважением, Дмитрий.
Re: SQL база ГТД. Сиквестирование базы. Вопросы.
подниму тему, т.к. чистки базы средствами альты нету , хотелось бы получить расшифровку обозначений типов документов в столбце DOCTYP таблицы DOCS.
Чтобы не поудалять нужные документы как то: формализованные документы и т.п.
SQL запрос напишу сам.
Спасибо.
Чтобы не поудалять нужные документы как то: формализованные документы и т.п.
SQL запрос напишу сам.
Спасибо.
Re: SQL база ГТД. Сиквестирование базы. Вопросы.
В прилагаемом файле перечислены расшифровки всех возможных типов документов
- Вложения
-
- DocTyp.doc
- Расшифровка типов документов
- (67 КБ) 639 скачиваний
- Nick
- Аксакал
- Сообщения: 734
- На форуме: c 02 фев 2005
- Откуда: Альта-Софт, Программист
Сказал: 13 ед.
Получил: 124 ед.
Получил: 124 ед.
Re: SQL база ГТД. Сиквестирование базы. Вопросы.
Могу ответить короче - типов документов много и все нужные, ничего совсем уж временного в базе Docs нет.
Надо определить самим что именно вам не жалко почистить. Например у вас много одноразовых "Авианакладных". Заходите в нее, смотрите меню "Авианкладная / Информация о документе" там написано, в частности, "TYPE=E3AWB". Вот этот E3AWB значит включаем в кандидаты на удаление.
Конечно сами GTD/DTS/KTS/OPN первейшие кандидаты. Те что старые. Инвойсы иже с ними, и Invoice (для ЭД) и INV (альтовские расширенные). А вот с универсальными FreeDoc осторожнее, там мусор может смешаться с долгоиграющими.
Еще стоит присмотреться к базе EdMsgs, то есть сообщений. Блобы на них толстые, а после завершения процедуры реально программой они уже не используются. Смело выносить.
Правда в деле чистки базы есть одно но - что называется "для прокурора" она должна хранится три года т.к. ЭД документ с ЭЦП это и есть в случае чего единственный и неповторимый документ.
Поэтому перед чисткой по любому полный бэкап и в дальний ящик. Как раз у SQL-Express вся база на один DVD лезет...
Надо определить самим что именно вам не жалко почистить. Например у вас много одноразовых "Авианакладных". Заходите в нее, смотрите меню "Авианкладная / Информация о документе" там написано, в частности, "TYPE=E3AWB". Вот этот E3AWB значит включаем в кандидаты на удаление.
Конечно сами GTD/DTS/KTS/OPN первейшие кандидаты. Те что старые. Инвойсы иже с ними, и Invoice (для ЭД) и INV (альтовские расширенные). А вот с универсальными FreeDoc осторожнее, там мусор может смешаться с долгоиграющими.
Еще стоит присмотреться к базе EdMsgs, то есть сообщений. Блобы на них толстые, а после завершения процедуры реально программой они уже не используются. Смело выносить.
Правда в деле чистки базы есть одно но - что называется "для прокурора" она должна хранится три года т.к. ЭД документ с ЭЦП это и есть в случае чего единственный и неповторимый документ.
Поэтому перед чисткой по любому полный бэкап и в дальний ящик. Как раз у SQL-Express вся база на один DVD лезет...
Re: SQL база ГТД. Сиквестирование базы. Вопросы.
спасибо, перед экзекуцией естесно бэкап :]
Re: SQL база ГТД. Сиквестирование базы. Вопросы.
а у меня такой вопрос, имеется ваша программа "Отчет", все запустили все настроили как в самой альте, вопрос по SQL, можно ли эту программу подключить к базе sql? мы все настройки забили пароль логин все как делали с альтой.
-
- Аксакал
- Сообщения: 671
- На форуме: c 14 ноя 2004
- Откуда: Санкт-Петербург
Сказал: 4 ед.
Получил: 102 ед.
Получил: 102 ед.
Re: SQL база ГТД. Сиквестирование базы. Вопросы.
"Отчет брокера" работает не с самой базой гтд, а с базой зарегистрированных документов.kinotatr писал(а):а у меня такой вопрос, имеется ваша программа "Отчет", все запустили все настроили как в самой альте, вопрос по SQL, можно ли эту программу подключить к базе sql? мы все настройки забили пароль логин все как делали с альтой.
https://www.alta.ru/docs2sql.php
Ведь смысл - сформировать итоги по выпущенным ГТД, а в базе с которой работают декларанты помимо реальных есть еще и "мусор" (заготовки, сдублированные, недоделанные, переделанные и т.д.).
Если хотите делать отчеты "на лету", см. меню "Сервис", "Отчеты".
Следующие пользователи поблагодарили Sergey за это собщение: kinotatr
Re: SQL база ГТД. Сиквестирование базы. Вопросы.
Всем приветы!
На праздниках занимался сворачиванием базы (7,6 ГБайт)
1) попытался воспользоваться встроенной функцией по очистке из Альты. Реально там не хватает часиков. Мне показалось что программа зависла.
в итоге залез на сервер и воспользовался DELETE FROM EdMsgs WHERE PreparationDateTime < DATEADD(d, -30, GetDate()) - удавольствие заняло минут 10. Зря грешил на зависание программы, но хоть там было вино что процесс идет Все таки часики стоит включить в инструменте.
2) потом начал переносить документы из текущей базы за 2010 г в архивную базу с хламом с 2008 года. Ужал файл базы на сервере и добился приемлемого размера 1,8ГБ.
И вот проблема: в текущей базе пропали много документов. А в архивной куда была выгрузка/загрузка документов - не нашлось. Процесс загрузки/выгрузки был штатный. Без сбоев. Документы которых не досчитались брокеры все со статусом "в архиве".
Поэтому есть предложение основанное на следующих размышления:
1) в общей бзе ГТД есть таблица списка архивов.
2) есть таблица списка документов в каждом архиве.
3) есть документы со статусом "в архиве".
Я предлагаю упорядочить хранение документов успешно ушедших в архив в таможне. Т.е. в общем каталоге БД рядом с каталогом "ШАБЛОНЫ" и "КОРЗИНА" создать каталог "В АРХИВЕ ТАМОЖНИ". И после усешного присвоения документу статуса "в архиве" переносить документ в каталог "В АРХИВЕ ТАМОЖНИ".
Какие от этого приимущества ?
1) Пользователь в многодокументной БД получает возможность сразу доступ к документам отправленых в архив таможни. Как показывает практика крупных брокеров - режим работы редко предполагает удостовериться что документ успешно ушел в таможню. Из-за сложной формализации сложно переключаться между типами отображени я ЭД документов, когда основная работа декларанта работа со списком ГТД, а не ЭД.
2) Прозрачный контроль документов успешно ушедших в таможню даст возможность чистить и удалять каталоги внутри БД не опасаясь проблем с утерей документов которые были отправлены ранее в архив. Они лежат отдельно и не будут тронуты.
3) Так же практика показывает, что не всегда внимательный брокер может повторно создать документ и отправить его в архив с тем же именем, потому что в многовложенных каталогах документов по той или иной фирме не смог просмотреть все содержимое каталога из-за особенности устройства отображения документов в списке (п.1) Когда документы одного статуса (В АРХИВЕ) и веса (УДАЛЕНИЕ КРИТИЧНО ДЛЯ РАБОТЫ) их легче хранить в одном месте.
Собственно вот.
Прошу откликнуться на сей призыв. Наступит 2013 год и захочется 2011 снести в архивную базу, а это порядке сотни каталогов и несколько десятков тысяч документов разного типа и конечно много из них лежат со статусом "В АРХИВЕ". Это документы важны для работы брокеров, но увы нет инструмента просмтривать их в одном месте, т.к. они "размазаны" по всей БД.
Так же как мотивация хотелось бы что бы предварительно можно было бы собрать эти документы в кучу. Т.е. сделать настройку "собрать все документы со статусом "В АРХИВЕ" в каталог по выбору.
Есть еще один мотив - когда в одной БД храняться несколько организаций со своими ID декларанта и со своими архивами.
Жду отзывов
На праздниках занимался сворачиванием базы (7,6 ГБайт)
1) попытался воспользоваться встроенной функцией по очистке из Альты. Реально там не хватает часиков. Мне показалось что программа зависла.
в итоге залез на сервер и воспользовался DELETE FROM EdMsgs WHERE PreparationDateTime < DATEADD(d, -30, GetDate()) - удавольствие заняло минут 10. Зря грешил на зависание программы, но хоть там было вино что процесс идет Все таки часики стоит включить в инструменте.
2) потом начал переносить документы из текущей базы за 2010 г в архивную базу с хламом с 2008 года. Ужал файл базы на сервере и добился приемлемого размера 1,8ГБ.
И вот проблема: в текущей базе пропали много документов. А в архивной куда была выгрузка/загрузка документов - не нашлось. Процесс загрузки/выгрузки был штатный. Без сбоев. Документы которых не досчитались брокеры все со статусом "в архиве".
Поэтому есть предложение основанное на следующих размышления:
1) в общей бзе ГТД есть таблица списка архивов.
2) есть таблица списка документов в каждом архиве.
3) есть документы со статусом "в архиве".
Я предлагаю упорядочить хранение документов успешно ушедших в архив в таможне. Т.е. в общем каталоге БД рядом с каталогом "ШАБЛОНЫ" и "КОРЗИНА" создать каталог "В АРХИВЕ ТАМОЖНИ". И после усешного присвоения документу статуса "в архиве" переносить документ в каталог "В АРХИВЕ ТАМОЖНИ".
Какие от этого приимущества ?
1) Пользователь в многодокументной БД получает возможность сразу доступ к документам отправленых в архив таможни. Как показывает практика крупных брокеров - режим работы редко предполагает удостовериться что документ успешно ушел в таможню. Из-за сложной формализации сложно переключаться между типами отображени я ЭД документов, когда основная работа декларанта работа со списком ГТД, а не ЭД.
2) Прозрачный контроль документов успешно ушедших в таможню даст возможность чистить и удалять каталоги внутри БД не опасаясь проблем с утерей документов которые были отправлены ранее в архив. Они лежат отдельно и не будут тронуты.
3) Так же практика показывает, что не всегда внимательный брокер может повторно создать документ и отправить его в архив с тем же именем, потому что в многовложенных каталогах документов по той или иной фирме не смог просмотреть все содержимое каталога из-за особенности устройства отображения документов в списке (п.1) Когда документы одного статуса (В АРХИВЕ) и веса (УДАЛЕНИЕ КРИТИЧНО ДЛЯ РАБОТЫ) их легче хранить в одном месте.
Собственно вот.
Прошу откликнуться на сей призыв. Наступит 2013 год и захочется 2011 снести в архивную базу, а это порядке сотни каталогов и несколько десятков тысяч документов разного типа и конечно много из них лежат со статусом "В АРХИВЕ". Это документы важны для работы брокеров, но увы нет инструмента просмтривать их в одном месте, т.к. они "размазаны" по всей БД.
Так же как мотивация хотелось бы что бы предварительно можно было бы собрать эти документы в кучу. Т.е. сделать настройку "собрать все документы со статусом "В АРХИВЕ" в каталог по выбору.
Есть еще один мотив - когда в одной БД храняться несколько организаций со своими ID декларанта и со своими архивами.
Жду отзывов
-
- Почетный участник
- Сообщения: 101
- На форуме: c 06 ноя 2004
- Откуда: Альта-Софт
Сказал: 0 ед.
Получил: 20 ед.
Получил: 20 ед.
Re: SQL база ГТД. Сиквестирование базы. Вопросы.
По поводу "часиков" посмотрим конечно - по идее они там уже должны быть...
Но более подробного "прогресса" здесь сделать невозможно к сожалению - программа передает SQL-серверу тот же запрос DELETE и дальше тупит уже сервер, никак не сообщая клиенту о своем прогрессе...
Что касается списка документов, отправленных в архив таможни.
Во-первых, его сейчас можно посмотреть с помощью меню "Настройка/Сервер и сетевые настройки/Архивы ЭД-2 документов".
Во-вторых, у нас была идея сделать на панели "переключения типов док-ов" вариант "Все" (чтобы док-ты любых типов в папке можно было посмотреть), плюс в окне поиска (по сути "применения фильтра к списку") галочку аналогичную "только зарегистрированные" - здесь будет "только в архиве таможни" и м.б. даже с возможностью выбора конкретного архива из откидного списка. В этом случае можно будет получить "живой" список док-ов, которые можно выделять, выгружать, переносить и т.д. и т.п.
Но пока как говорится "не дошли руки"
А то что Вы предложили (отдельная "служебная" папка), во-первых, плохо стыкуется с нашим переключателем типов док-ов (будет не очевидно, что там все подряд показано, плюс не будет возможности посмотреть архивные док-ты именно определенного типа), во-вторых, затрудняет навигацию пользователя по док-ам (он же не просто так наплодил папок и разложил разные док-ты по разным папкам - ему так удобнее их искать и цеплять к Описи например)...
В принципе ровно такая же ситауция сейчас с "зарегистрированными" док-ами - они тоже "размазаны по всей базе", но с помощью фильтра их можно "собрать в кучку" (правда пока только определенного типа - надо делать все тот же вариант "все" для переключателя типов)...
Ну и, в-третьих, с многоархивностью в этой общей папке тоже не очень понятно как бороться...
P.S. У нас почти созрела программка, облегчающая ведение архивов - она будет сама переносить в архив выбранные док-ты (как сейчас в "чистке") и пересоздавать рабочую базу путем переноса в чистую оставшихся (это будет быстрее, чем удаление)... Скоро выпустим я думаю...
Но более подробного "прогресса" здесь сделать невозможно к сожалению - программа передает SQL-серверу тот же запрос DELETE и дальше тупит уже сервер, никак не сообщая клиенту о своем прогрессе...
Что касается списка документов, отправленных в архив таможни.
Во-первых, его сейчас можно посмотреть с помощью меню "Настройка/Сервер и сетевые настройки/Архивы ЭД-2 документов".
Во-вторых, у нас была идея сделать на панели "переключения типов док-ов" вариант "Все" (чтобы док-ты любых типов в папке можно было посмотреть), плюс в окне поиска (по сути "применения фильтра к списку") галочку аналогичную "только зарегистрированные" - здесь будет "только в архиве таможни" и м.б. даже с возможностью выбора конкретного архива из откидного списка. В этом случае можно будет получить "живой" список док-ов, которые можно выделять, выгружать, переносить и т.д. и т.п.
Но пока как говорится "не дошли руки"
А то что Вы предложили (отдельная "служебная" папка), во-первых, плохо стыкуется с нашим переключателем типов док-ов (будет не очевидно, что там все подряд показано, плюс не будет возможности посмотреть архивные док-ты именно определенного типа), во-вторых, затрудняет навигацию пользователя по док-ам (он же не просто так наплодил папок и разложил разные док-ты по разным папкам - ему так удобнее их искать и цеплять к Описи например)...
В принципе ровно такая же ситауция сейчас с "зарегистрированными" док-ами - они тоже "размазаны по всей базе", но с помощью фильтра их можно "собрать в кучку" (правда пока только определенного типа - надо делать все тот же вариант "все" для переключателя типов)...
Ну и, в-третьих, с многоархивностью в этой общей папке тоже не очень понятно как бороться...
P.S. У нас почти созрела программка, облегчающая ведение архивов - она будет сама переносить в архив выбранные док-ты (как сейчас в "чистке") и пересоздавать рабочую базу путем переноса в чистую оставшихся (это будет быстрее, чем удаление)... Скоро выпустим я думаю...
С уважением, Дмитрий.
Re: SQL база ГТД. Сиквестирование базы. Вопросы.
Люблю я Васpopov писал(а):По поводу "часиков" посмотрим конечно - по идее они там уже должны быть...
Но более подробного "прогресса" здесь сделать невозможно к сожалению - программа передает SQL-серверу тот же запрос DELETE и дальше тупит уже сервер, никак не сообщая клиенту о своем прогрессе...
Что касается списка документов, отправленных в архив таможни.
Во-первых, его сейчас можно посмотреть с помощью меню "Настройка/Сервер и сетевые настройки/Архивы ЭД-2 документов".
Во-вторых, у нас была идея сделать на панели "переключения типов док-ов" вариант "Все" (чтобы док-ты любых типов в папке можно было посмотреть), плюс в окне поиска (по сути "применения фильтра к списку") галочку аналогичную "только зарегистрированные" - здесь будет "только в архиве таможни" и м.б. даже с возможностью выбора конкретного архива из откидного списка. В этом случае можно будет получить "живой" список док-ов, которые можно выделять, выгружать, переносить и т.д. и т.п.
Но пока как говорится "не дошли руки"
А то что Вы предложили (отдельная "служебная" папка), во-первых, плохо стыкуется с нашим переключателем типов док-ов (будет не очевидно, что там все подряд показано, плюс не будет возможности посмотреть архивные док-ты именно определенного типа), во-вторых, затрудняет навигацию пользователя по док-ам (он же не просто так наплодил папок и разложил разные док-ты по разным папкам - ему так удобнее их искать и цеплять к Описи например)...
В принципе ровно такая же ситауция сейчас с "зарегистрированными" док-ами - они тоже "размазаны по всей базе", но с помощью фильтра их можно "собрать в кучку" (правда пока только определенного типа - надо делать все тот же вариант "все" для переключателя типов)...
Ну и, в-третьих, с многоархивностью в этой общей папке тоже не очень понятно как бороться...
P.S. У нас почти созрела программка, облегчающая ведение архивов - она будет сама переносить в архив выбранные док-ты (как сейчас в "чистке") и пересоздавать рабочую базу путем переноса в чистую оставшихся (это будет быстрее, чем удаление)... Скоро выпустим я думаю...
Но хоту уточнить, что имея в виду отдельная папка "В АРХИВЕ ТАМОЖНИ" - я подразумевал не просто отдельный каталог в корне БД, а много вложенный каталог - т.е. Если бы мы переносили ЭД-документ получивший статус "а в архиве" мы бы перенсли его так "В АРХИВЕ ТАМОЖНИ"-->"Имя_каталога_где_лежал_документ"-->"Имя_архива_куда_отправили_документ". И нет путаницы. И переключатель типа документов тоже там нормально смотриться, но лучше без него. (у вас же впроводнике или виндовс-коммандоре файлы списком лежат и переключаться по типам не нужно, достаточно список отфильтровать по типу если не удобно). Моя схема взаимодействия дает спокойно управлять целым каталогом без доп.утилит. Я могу эту папку целой выгрузить и загрузить. Когда у вас изначательно хранение "особых" документов в одном месте нет нужды выдумывать варианты вроде вашего Я провожу много времени между брокерами и помогаю управляться с документами и на мой взгляд система хранения "мух" и "котлет" поотдельности дает больше шанса не захлебнуться в документах, чем хранить вместе. Даже если человек понимает зачем у него так сложно устроены каталоги. Дополнительные утилиты и средства взаимодействия хороши для очень подковонного пользователя, администратора. А встроенный прозрачный механизм - хорош для любого пользователя, даже неподготовленного.
Если моя идея уходит в разврез с развитием Альты-ГТД, почему бы не попробывать отдельно для нас мы крупная компания со штатом достаточным, что бы просить отдельной поддержки и доработки Архив вещь полезная для брокера, прозрачный механизм работы с архивными документами - очень вещь необходимая для нас, которая бует экономить время наших брокеров.
С искренним уважением, Сергей.
- Nick
- Аксакал
- Сообщения: 734
- На форуме: c 02 фев 2005
- Откуда: Альта-Софт, Программист
Сказал: 13 ед.
Получил: 124 ед.
Получил: 124 ед.
Re: SQL база ГТД. Сиквестирование базы. Вопросы.
Про удаление документов из базы и "архив ЭД".
Дело в том, что признак "отправлен в архив" и "номер документа в архиве таможни" хранится в самом документе, т.е. в таблице DOCS. Если удалили документ, то в Описи (и в Альте, и у инспектора) он перестает отмечаться как "архивный" и будет запрошен по новой. То есть актуальные документы (старые контракты, сертификаты и т.д.) из базы удалять нельзя, даже после того как они ушли в архив таможни и вроде бы больше не нужны.
Поэтому во встроенной утилите чистки базы, помимо фильтра по дате, есть фильтр по типу документа. Инвойсы и накладные удалять можно, а контракты и регистрационные документы нельзя. Нельзя также чистить все подряд "Универсальные документы", это может оказаться что-то нужное типа паспорта или доверенности.
Радикальное решение возможно только если нам переделать программу примерно как вы говорите. Скажем, помимо документов реально лежащих в БД сделать понятие "документ в архиве таможни". У которого "тело" в таблице Docs не хранится и места не занимает. А остается в ней только номер для показа в списке и "архивный номер" для Описи. По которому этот документ в случае чего можно запросить в таможне и посмотреть целиком. Можно такие документы типа "ссылка на архив таможни" и в отдельную папочку вынести, как вы это дело предлагаете.
Со временем что-то такое придется сделать. Тем более возможно, что отправка документов в архив до подачи ГТД станет в новой спецификации обязательной...
P.S. А Дима пишет про "менеджер архивов старых документов". Не в смысле "архива таможни", а в смысле "чистки БД" с выносом всего старья в отдельную БД, в которую тем не менее можно залезть и что-то найти. Разные вещи "архив таможни" и "архив декларанта", одно и то же слово вызывает некоторую путаницу.
Дело в том, что признак "отправлен в архив" и "номер документа в архиве таможни" хранится в самом документе, т.е. в таблице DOCS. Если удалили документ, то в Описи (и в Альте, и у инспектора) он перестает отмечаться как "архивный" и будет запрошен по новой. То есть актуальные документы (старые контракты, сертификаты и т.д.) из базы удалять нельзя, даже после того как они ушли в архив таможни и вроде бы больше не нужны.
Поэтому во встроенной утилите чистки базы, помимо фильтра по дате, есть фильтр по типу документа. Инвойсы и накладные удалять можно, а контракты и регистрационные документы нельзя. Нельзя также чистить все подряд "Универсальные документы", это может оказаться что-то нужное типа паспорта или доверенности.
Радикальное решение возможно только если нам переделать программу примерно как вы говорите. Скажем, помимо документов реально лежащих в БД сделать понятие "документ в архиве таможни". У которого "тело" в таблице Docs не хранится и места не занимает. А остается в ней только номер для показа в списке и "архивный номер" для Описи. По которому этот документ в случае чего можно запросить в таможне и посмотреть целиком. Можно такие документы типа "ссылка на архив таможни" и в отдельную папочку вынести, как вы это дело предлагаете.
Со временем что-то такое придется сделать. Тем более возможно, что отправка документов в архив до подачи ГТД станет в новой спецификации обязательной...
P.S. А Дима пишет про "менеджер архивов старых документов". Не в смысле "архива таможни", а в смысле "чистки БД" с выносом всего старья в отдельную БД, в которую тем не менее можно залезть и что-то найти. Разные вещи "архив таможни" и "архив декларанта", одно и то же слово вызывает некоторую путаницу.
Re: SQL база ГТД. Сиквестирование базы. Вопросы.
АААА, ну кое что теперь встало на свои места. Ник, спасибо за проясненияNick писал(а):Про удаление документов из базы и "архив ЭД".
Дело в том, что признак "отправлен в архив" и "номер документа в архиве таможни" хранится в самом документе, т.е. в таблице DOCS. Если удалили документ, то в Описи (и в Альте, и у инспектора) он перестает отмечаться как "архивный" и будет запрошен по новой. То есть актуальные документы (старые контракты, сертификаты и т.д.) из базы удалять нельзя, даже после того как они ушли в архив таможни и вроде бы больше не нужны.
Поэтому во встроенной утилите чистки базы, помимо фильтра по дате, есть фильтр по типу документа. Инвойсы и накладные удалять можно, а контракты и регистрационные документы нельзя. Нельзя также чистить все подряд "Универсальные документы", это может оказаться что-то нужное типа паспорта или доверенности.
Радикальное решение возможно только если нам переделать программу примерно как вы говорите. Скажем, помимо документов реально лежащих в БД сделать понятие "документ в архиве таможни". У которого "тело" в таблице Docs не хранится и места не занимает. А остается в ней только номер для показа в списке и "архивный номер" для Описи. По которому этот документ в случае чего можно запросить в таможне и посмотреть целиком. Можно такие документы типа "ссылка на архив таможни" и в отдельную папочку вынести, как вы это дело предлагаете.
Со временем что-то такое придется сделать. Тем более возможно, что отправка документов в архив до подачи ГТД станет в новой спецификации обязательной...
P.S. А Дима пишет про "менеджер архивов старых документов". Не в смысле "архива таможни", а в смысле "чистки БД" с выносом всего старья в отдельную БД, в которую тем не менее можно залезть и что-то найти. Разные вещи "архив таможни" и "архив декларанта", одно и то же слово вызывает некоторую путаницу.
Единственное что значит я сделал не правильно это тупо выгрузил из корня папку с документами 2010 года и удалил ее.
В описе у декларантов остались только молнии без документа. Пришлось разворачивать из бекапа базу(отдельная история я буду о ней спрашивать чуть позже) и вытаскивать документы в текущую базу из которой они исчезли, кстати опись сразу подхватила их. Я же предлагаю не удалять тело документа отправленного в архив из таблицы Docs. А переносить его ...нет указывать ему другой путь хранения, через пути каталогов. Для Альты разницы никакой в каком из каталогов лежит документ. У документа есть длинный идентификатор покоторому он и прикреплен к описе. Система каталогов в принципе понятна для любого пользователя, а если будет каталог где "сложены" все архивно_таможенные документы дает те преимущества о которых я уже писал. Отдельно хочется отметить, что мне как опытному администратору приходиться задавать массу вопросов декларантам о их документах, а с учетом того что ту или иную фирму наш таможенный представитель ведет в несколько лиц(декларантов) они часто не имеют понятия что/когда_и_где
- Nick
- Аксакал
- Сообщения: 734
- На форуме: c 02 фев 2005
- Откуда: Альта-Софт, Программист
Сказал: 13 ед.
Получил: 124 ед.
Получил: 124 ед.
Re: SQL база ГТД. Сиквестирование базы. Вопросы.
Ну так и с точки зрения размера БД разницы нет. Начинали-то с чистки БД? Вот я и предлагаю документы "в архиве" в новых версиях убивать не удалением записи, а только очисткой поля BLOB. Так будет и Опись целой, и база меньше, и ничего не надо вручную отслеживать. А в списке такие "полуудаленные" документы показывать серым, а по двойному щелчку предлагать запросить из архива таможни.Koteneff писал(а):Я же предлагаю не удалять тело документа отправленного в архив из таблицы Docs. А переносить его ...нет указывать ему другой путь хранения, через пути каталогов. Для Альты разницы никакой в каком из каталогов лежит документ.
- Nick
- Аксакал
- Сообщения: 734
- На форуме: c 02 фев 2005
- Откуда: Альта-Софт, Программист
Сказал: 13 ед.
Получил: 124 ед.
Получил: 124 ед.
Re: SQL база ГТД. Сиквестирование базы. Вопросы.
Ага, насчет "Все" идея была, но как-то в текучке утонула. Технически не сложно, сейчас кому-нибудь из программистов её еще разок подсуну.Koteneff писал(а):у нас была идея сделать на панели "переключения типов док-ов" вариант "Все" (чтобы док-ты любых типов в папке можно было посмотреть), плюс в окне поиска (по сути "применения фильтра к списку") галочку аналогичную "только зарегистрированные" - здесь будет "только в архиве таможни" и м.б. даже с возможностью выбора конкретного архива из откидного списка. В этом случае можно будет получить "живой" список док-ов, которые можно выделять, выгружать, переносить и т.д. и т.п.
-
- Почетный участник
- Сообщения: 101
- На форуме: c 06 ноя 2004
- Откуда: Альта-Софт
Сказал: 0 ед.
Получил: 20 ед.
Получил: 20 ед.
Re: SQL база ГТД. Сиквестирование базы. Вопросы.
Да, про утилитку это я не очень точно сформулировал, из-за чего возникла некоторая путаница
Действительно, не надо путать задачу "работы с документами, отправленными в архив таможни", и задачу "создания архива старых док-ов у декларанта с одновременной очисткой рабочей базы".
Так вот, я имел в виду, что утилитка поможет решать вторую задачу, соотв-но первая скорее всего станет менее актуальна, т.к. при "очистке" рабочей базы можно будет поставить галочку типа "не трогать док-ты, когда-либо отправлявшиеся в архив таможни" (в "чистке" сейчас такая настройка есть кстати) и соотв-но никуда их руками таскать не придется (единой папкой выгружать и т.п.).
То о чем написал Николай тоже относится ко второй задаче (уменьшение размера рабочей БД), но к первоначальному вопросу отношения не имеет. Скорее всего об этом тоже придется подумать, но имхо не сейчас и не все там так гладко...
Что касается "многовложенной папки" - ну это вообще людям объяснить будет невозможно (слишком замороченно), плюс Вы же сами через некоторое время захотите по-другому сгруппировать те же самые док-ты (например, чтобы папки были по "куда отправили", а уже внутри по "исходным папкам"), ну т.е. вариантов отображения/группировки одних и тех же данных можно напридумывать море, но это не значит, что из-за этого их хранить надо по-другому...
Про типы док-ов я уже объснил, что это не соотв-ет текущему интерфейсу (у нас все-таки не "командер" и не "проводник виндоус", а свой интерфейс, к которому люди привыкли). Так что сделаем вариант "все" для фильтра по типам и вопрос закрыт...
Но в принципе Вам никто не мешает организовать у себя именно такую структуру папок (чисто организационными мерами) и переносить туда док-ты после их отправки в архив. Я просто не понимаю зачем тогда нужны исходные папки (со сложной структурой вложенности и т.д.)? Сейчас тенденция идет к тому, чтобы 100% док-ов отправлять в архив таможни, соотв-но в исходных папках останется только полный мусор (черновики, какие-то дубли никому ненужные и т.п.). При таком раскладе проще завести ровно одну папку "Черновики", где готовить док-ты, после чего отправлять их в архив и перемещать в ту структуру, о которой Вы написали. Кстати, так будет гораздо проще чистить базу от реального мусора
В общем, это очень спорный и сомнительный вариант, который можно сделать только "под заказ" - по договору, за отдельные деньги и т.д. - если есть реальная необходимость в этом, то обращайтесь с конкретным тех. заданием на alta@alta.ru - будем думать...
Ну а для тех кто будет пользоваться штатными средствами "чистки" или этой "утилиткой" таких проблем/задач не возникнет в принципе...
Действительно, не надо путать задачу "работы с документами, отправленными в архив таможни", и задачу "создания архива старых док-ов у декларанта с одновременной очисткой рабочей базы".
Так вот, я имел в виду, что утилитка поможет решать вторую задачу, соотв-но первая скорее всего станет менее актуальна, т.к. при "очистке" рабочей базы можно будет поставить галочку типа "не трогать док-ты, когда-либо отправлявшиеся в архив таможни" (в "чистке" сейчас такая настройка есть кстати) и соотв-но никуда их руками таскать не придется (единой папкой выгружать и т.п.).
То о чем написал Николай тоже относится ко второй задаче (уменьшение размера рабочей БД), но к первоначальному вопросу отношения не имеет. Скорее всего об этом тоже придется подумать, но имхо не сейчас и не все там так гладко...
Что касается "многовложенной папки" - ну это вообще людям объяснить будет невозможно (слишком замороченно), плюс Вы же сами через некоторое время захотите по-другому сгруппировать те же самые док-ты (например, чтобы папки были по "куда отправили", а уже внутри по "исходным папкам"), ну т.е. вариантов отображения/группировки одних и тех же данных можно напридумывать море, но это не значит, что из-за этого их хранить надо по-другому...
Про типы док-ов я уже объснил, что это не соотв-ет текущему интерфейсу (у нас все-таки не "командер" и не "проводник виндоус", а свой интерфейс, к которому люди привыкли). Так что сделаем вариант "все" для фильтра по типам и вопрос закрыт...
Но в принципе Вам никто не мешает организовать у себя именно такую структуру папок (чисто организационными мерами) и переносить туда док-ты после их отправки в архив. Я просто не понимаю зачем тогда нужны исходные папки (со сложной структурой вложенности и т.д.)? Сейчас тенденция идет к тому, чтобы 100% док-ов отправлять в архив таможни, соотв-но в исходных папках останется только полный мусор (черновики, какие-то дубли никому ненужные и т.п.). При таком раскладе проще завести ровно одну папку "Черновики", где готовить док-ты, после чего отправлять их в архив и перемещать в ту структуру, о которой Вы написали. Кстати, так будет гораздо проще чистить базу от реального мусора
В общем, это очень спорный и сомнительный вариант, который можно сделать только "под заказ" - по договору, за отдельные деньги и т.д. - если есть реальная необходимость в этом, то обращайтесь с конкретным тех. заданием на alta@alta.ru - будем думать...
Ну а для тех кто будет пользоваться штатными средствами "чистки" или этой "утилиткой" таких проблем/задач не возникнет в принципе...
С уважением, Дмитрий.
Re: SQL база ГТД. Сиквестирование базы. Вопросы.
Добрый день.
А эта "утилита" уже вышла? Как называется, если да?
Или это он и есть штатный инструмент в меню Сервис - Администратор SQL?
А эта "утилита" уже вышла? Как называется, если да?
Или это он и есть штатный инструмент в меню Сервис - Администратор SQL?
Re: SQL база ГТД. Сиквестирование базы. Вопросы.
И ещё скажите, возможно ли в вашем инструменте чистки SQL сделать выбор вместо Удалять документы старше "45 дней, года, 2х лет" сделать Удалить документы ДО 01.01.2012? Ну т.е. с выбором конкретной даты.
Re: SQL база ГТД. Сиквестирование базы. Вопросы.
Для чистки базы данных используется Сервис\Администратор SQL. Выбора произвольной даты нет. Вы можете выставить нужные параметры, затем сохранить скрипт, потом открыть его и поменять значение параметра PreparationDateTime на нужное вам, затем Сервис\Администратор SQL\Выполнить скрипт из файла.
-
- Почетный участник
- Сообщения: 101
- На форуме: c 06 ноя 2004
- Откуда: Альта-Софт
Сказал: 0 ед.
Получил: 20 ед.
Получил: 20 ед.
Re: SQL база ГТД. Сиквестирование базы. Вопросы.
Да, см. C:\ALTA\UTILS\dbutils.exeKonkoAM писал(а): А эта "утилита" уже вышла? Как называется, если да?
В dbutils.exe это изначально есть, в меню Сервис/Чистка... пока нет, но тоже сделаем...KonkoAM писал(а): И ещё скажите, возможно ли в вашем инструменте чистки SQL сделать выбор вместо Удалять документы старше "45 дней, года, 2х лет" сделать Удалить документы ДО 01.01.2012? Ну т.е. с выбором конкретной даты.
Это не получится, т.к. там "GO" присутствует, т.е. скрипт изначально для SQL Server Management Studio предназначен. Но если его открыть в окне "Сервис/Выполнить SQL-запрос" и выделяя блоками (между словами GO) выполнить, то вполне. Ну либо студией...gorkin писал(а): ... затем Сервис\Администратор SQL\Выполнить скрипт из файла.
С уважением, Дмитрий.