gifts2017

О повышении удобства блокировки соединения пользователей с информационной базой и завершения сеансов пользователей

Опубликовал Виталий Роженюк (nimus) в раздел Администрирование - Системное

Иногда на время технологического обслуживания (обновление базы, резервное копирование) необходимо обеспечить освобождение рабочей базы от пользователей и недопустить временного их подсоединения. Для оперативности и удобства принудительного завершения работы пользователей вместо стандартных возможностей консоли управления и подсистем типовых конфигураций целесообразно использовать более развитые средства, один из вариант которых и рассматривается в этой статье.

Для всех, кто не очень любит читать, сразу предложу вместо большого количества букв посмотреть видеоролик, наглядно демонстрирующий, каким образом мы принудительно завершаем активные сеансы пользователей и временно блокируем соединение с информационными базами при применении "1С:Предприятия" 8.1 и 8.2.

Это еще одно интересное решение, которое применяется нашим коллективом на практике с 2007 года. Оно может быть интересно всем, кто применяет "1С:Предприятие" 8.х на динамично развиваемых высоконагруженных информационных базах (когда обновления работающих баз проводятся почти каждый день или по нескольку раз в день, когда количество пользователей исчисляется десятками, сотнями или тысячами).

Речь об управлении запретом на соединение пользователей с информационной базой и принудительном завершении активных сеансов пользователей.

Конечно, всё это можно делать с помощью стандартных средств 1С:Предприятия 8.х (например, консоли управления серверами 1С) или механизмов, имеющихся в некоторых типовых конфигурациях. Однако удобство применения повсеместно доступных средств, всё же, ограничено, затраты времени на управление блокировкой соединений можно сократить, а администраторы и разработчики при использовании стандартных механизмов вполне могут позволить себе не вполне корректно информировать пользователей о причинах и времени недоступности информационной базы. И позволю высказать своё мнение, что всё это вполне исправимо?


Итак, иногда разработчикам или администраторам необходимо обеспечить монопольный доступ к информационной базе. Например, при обновлении базы в случае изменения структур хранения или для резервного копирования в ночное время средствами конфигуратора "1С:Предприятия", а не сервера баз данных (размеры копии всё же очень значимо отличаются при применении этих подходов).

Для запрета установки новых соединений пользователями и начала завершения активных сеансов мы применяем вот такую форму:

Окно установки блокировки соединения с информационной базой

Вызвать её - это один клик мышки, заблокировать информационную базу - еще один (по большой красной кнопке "Заблокировать").

После установки блокировки форма немного меняется и выглядит вот так:

Окно снятия блокировки соединения с информационной базой

Как видно, разрешить пользователям работать - это тоже один клик мышкой. В каком состоянии сейчас информационная база на форме видно, как разблокировать - тоже вроде понятно. Сделать что-то некорректное не то чтобы трудно, скорее невозможно.

Для простейших ситуаций установки/снятия запрета на использование информационной базы удобство администратора мы обеспечили. А как же пользователи? Ведь сотни людей в этот момент могут работать с информационной базой. Они просто увидят сообщение о разрыве соединения? Нет. Все сеансы будут завершены максимально корректно и так, чтобы все пользователи понимали, что, почему и как быстро от них требуется.

За 10 минут до времени, с которого нам необходимо обеспечить монопольный доступ к информационной базе, все пользователи получат первое уведомление:

Уведомление пользователя о необходимости завершения сеанса

Еще через 3 минуты те пользователи, что продолжают работать, получат второе уведомление:

Повторное уведомление пользователя о необходимости завершения сеанса

Еще через 3 минуты те, кто не понимает, что такое завершить текущий сеанс или не смотрит на экран монитора, получат третье, последнее предупреждение:

Уведомление пользователя о скором принудительном завершении сеанса

Ну а через минуту, как и написано в уведомлении, сеанс будет корректно автоматически завершен клиентом "1С:Предприятия" (именно клиентом, а не будет разрорван в одностороннем порядке со стороны сервера).

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

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

Настройка параметров блокировки информационной базы

На время, пока установка соединения с базой запрещена, при попытке запустить программу (установить соединение с информационной базой) пользователи увидят вот такое сообщение:

Сообщение о невозможности установки соединения с информационной базой

Оно очень похоже на стандартное окно уведомления о запрете установки соединения с информационной базой. Но в нем дополнительно выводится пояснение, что использование системы недоступно временно и по причине проведения регламентных работ.

Часто ли администраторы удосуживаются писать подобные пояснения, запрещая подсоединение к информационной базе? Нет. Если это делать на десятках баз по несколько раз в день, то их вполне можно понять. А ведь уместным в разных ситуациях может быть разный текст уведомления, что стоит обсудить отдельно.


Пару слов про время недоступности, которое можно задать на форме в полях "с" и "по".

По умолчанию в поле "с" указывается время на Х минут больше от текущего времени, где Х - время, которое требуется для корректного поэтапного информирования пользователей и завершения сеансов. 15, 10, 7, 4 минут. Мы чаще всего используем 10-ти минутный интервал завершения сеансов.

При необходимости в этом поле можно задать любое другое время, с которого будет действовать запрет. Например, днем можно установить запрет на 23:00, т.е. на время, когда будет проводиться резервное копирование.

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

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

Благодаря заполненному времени, до которого планируется обслуживание информационной базы, мы имеем возможность более детально проинформировать пользователей о своих планах. На примерах уведомлений ниже видно, как изменятся некоторые уведомления и сообщения, основные изменения выделены.

Уведомление пользователя о скором принудительном завершении сеанса с указанием ожидаемого времени завершения обслуживания

Сообщение о невозможности установки соединения с информационной базой с указанием ожидаемого времени завершения обслуживания


Но и это еще не всё. Часто мы проводим шаблонные операции. Типовое обновление в обед, которое обычно занимает 10 минут. Или резервное копирование, которое займет около часа. Даже указание ожидаемого времени завершения обслуживания можно избежать. Для самых отъявленных лентяев мы применяем шаблоны:

Шаблоны - предопределенные варианты установки запрета на использование информационной базы

Т.е., если, например, нам нужно быстренько обновить информационную базу, что займет не более 5-ти минут, достаточно вызвать окно шаблонов и нажать на кнопке "ВКЛ" напротив первого шаблона. Картинки обычно помогают нашим администраторам осознать суть предлагаемых шаблонов без слов ;)


Описанную схему мы применяем на информационных базах, работающих под управлением "1С:Предприятия" 8.1 и 8.2. Скорее всего, и под 8.3 в свете недавнего выхода этой версии платформы, вполне возможно провести доработку подсистемы и применять её на практике.

Когда мы брались за разработку этих механизмов, я выставлял 2 главных требования:

  1. человечность и простота восприятия, ориентация на применение без необходимости глубоких познаний или интеллектуальных способностей (всё должно быть просто и удобно, как применять должно быть понятно и без инструкции);
  2. ориентация на минимизацию трудозатрат админов в сочетании с требованием корректного информирования при ограничении доступа пользователей к базам (промышленные объемы требуют отработки там, где при разовом применении можно было бы проделать на пару лишних действий).

Как думаете, получилось ли сделать то, что хотелось?

См. также

PowerTools от 1 000
Подписаться Добавить вознаграждение

Комментарии

1. Алекс Одинэсник (Alex1Cnic) 30.12.14 09:49
Интересно, но где же сами файлы обработок???
CTAKAH; Бурухтан Второй Второй; kare; dr.death; zorka-gold; Dragonim; mc2; Lyolik; Oleg1708; a_ageev; bashirov.rs; +11 Ответить 2
2. Stas Agapov (Agapov_Stas) 30.12.14 10:20
и под 8.3 в свете недавнего выхода этой версии платформы

Ничего себе недавнего )))
Возник вопрос - как отключаются сеансы пользователей? - то что у Вас написано, что они отключаются клиентом, а не сервером приводит к тому что не выбрасываются зависшие сеансы либо сеансы в которых выполняется какое либо продолжительное действие.
Если вы все делали через обработчик ожидания, то в ситуации когда пользователь запустит какую то обработку (например, перепроведение документов, которое будет выполняться Х часов) он отключен не будет!
3. Виталий Роженюк (nimus) 30.12.14 10:23
(1) Alex1Cnic,

Всё это не только обработками реализуется. Это еще и обработчики ожидания на клиенте. Для интеграции с базами требуется сведение баз. Точнее будет сказать - подсистема, для интеграции с другими конфигурациями. Она актуальна только в случае, если конфигурация снята с поддержки.
4. Виталий Роженюк (nimus) 30.12.14 10:25
(2) Agapov_Stas,

Хороший вопрос, видно что в теме )
Сеансы завершаются последовательно в два этапа: первый - со стороны клиента обработчиком ожидания, второй - через com-соединение с сервером. Второй начинает выкидывать соединения по завершению указанного времени, т.е. когда все, кто мог, уже вышли. Именно вторая часть рубит зависшие сеансы.
5. Виталий Роженюк (nimus) 30.12.14 10:29
(2) Agapov_Stas,

Я писал о недавнем выходе ядра 8.3, а эта штуковенция уже 100 лет у нас применяется )
6. Stas Agapov (Agapov_Stas) 30.12.14 11:20
(3) nimus, так к чему статья то не пойму?
Без файлов и без кода она ничего не дает - просто показать какие вы классные?) и как вы рубите пользователей ?)
7. Александр Губанов (gubanoff) 30.12.14 11:58
Не увидел новаций. Использованы стандартные механизмы, только доработаны для "одного нажатия мышкой". Исходя из заголовка публикации "вместо стандартных механизмов" ожидал увидеть нечто новое. Расстроился :)
8. Виталий Роженюк (nimus) 30.12.14 12:38
(7) gubanoff,

Я постарался показать не альтернативный код, а альтернативный интерфейс управления запретом использования, потому этот материал в статьях, а не обработках ))

Моё мнение было выше - на крупных базах иногда мельчайшая тонкая доработка может сэкономить уйму времени и нервов. Вот это пример одной из таких доработок, которая для нас оказалась крайне полезной.
9. Виталий Роженюк (nimus) 30.12.14 12:40
(6) Agapov_Stas,

Даже без файлов виден вариант организации достаточно удобного интерфейса управления и показана корректная схема информирования пользователей. Уверен, что и это может многим быть интересным ;)
10. Рамиль Баширов (bashirov.rs) 30.12.14 12:47
(1) Alex1Cnic, поддерживаю.

(5) nimus,
1) у вас при установке блокировки все ли пользователи будут "выброшены" из базы? Просто со стандартной обработкой такое случается. Всё время ожидания прошло, основная часть пользователей вышли, а пару пользователей осталось, хотя время ожидания парой превышает 10-15 минут.
2) С информационными сообщениями конечно не удивили - в стандартных обработках можно добиться такого же и даже проще.
3) Но ради удобства вы молодец все же! Плюс.
11. Виталий Роженюк (nimus) 30.12.14 13:01
(10) bashirov.rs,

По вопросу, все ли будут выброшены. Да, за очень редким исключением, все. Там, где пользователи отказались выйти - клиент закроется по таймеру. Если по каким-либо причинам клиент не закроется (модальные окна, диалоги, зависшие сеансы, ...) - сеансы разрываются через com-объекты сервера 1С. Исключение - это мертво висячие сеансы, которые вылазят 1-2 раза в год, и которые не снимаются даже через консоль управления серверами. Для таких помогает только перезапуск сервера 1С, тут никакой код не спасает.

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

За "+" спасибо )
12. Рамиль Баширов (bashirov.rs) 31.12.14 07:33
(11) nimus, стандартная обработка называется "Блокировка соединений с информационной базой" это в Бухгалтерии КОРП, в УТ и УПП вроде тоже так же называется. Поэтапное информирование есть, но более подробного, как у вас, конечно нет. Там возможно просто написать сообщение при завершении работы пользователей и никаких доработок не требуется. Подробно я сейчас не опишу конечно, только в вкратце:
1. Просит выйти (несколько раз предупреждает в определенном интервале времени);
2. Окончательное предупреждение с закрытием сеанса (с возможностью сохраниться);
3. При попытке войти в базу говорит что база заблокирована;
Автоматически снимается блокировка при истечении времени, которое вы установили (возможно снять самостоятельно).
Одним словом это тот же стандартный механизм который вы используете как я предполагаю.
13. Виталий Роженюк (nimus) 31.12.14 09:55
(12) bashirov.rs,

Да, понял о каком речь. Он еще в ряде конфигураций, я в УПП прошлых поколений видел раньше. У нас администраторы крайне ленились при таком варианте закрытия на обслуживание впечатывать корректные уведомления пользователей, как и ленились прогнозировать время завершения обслуживания. Но уж точно эта обработка лучше, чем через окно консоли управления серверами закрывать. Точнее там не только обработка. Она также тесно связана с рядом обработчиков, тикающих по таймеру на клиентах.
14. Игорь (IgorS) 31.12.14 11:27
Без демонстрационной конфигурации с реализацией упомянутых механизмов вся статья - пустое "бла-бла-бла", полезный эффект от которого стремится к нулю.
MMF; mc2; wolfsoft; Lyolik; +4 Ответить 1
15. Babuin 01.01.15 14:50
меня больше вот это порадовало) явно что то не то в консерватории.
когда обновления работающих баз проводятся почти каждый день или по нескольку раз в день, когда количество пользователей исчисляется десятками, сотнями или тысячами

16. Виталий Роженюк (nimus) 01.01.15 16:31
17. Анастасия Сокирко (honeyform) 02.01.15 10:25
Одна из идей данной статьи – минимизировать влияние человеческого фактора на корректную работоспособность программного комплекса. При стандартных механизмах есть все риски как не до конца понятно описать сообщение, так и в принципе не предупредить о том, что мы «выбрасываем» пользователя из системы. Это если говорить только со стороны пользователя.

Теперь если со стороны администратора… Основная то суть оптимизации либо-какой системы не только в том, чтобы была отработана видимая часть для пользователя. Качество реализации так раз кроется «за ширмой». А как же драгоценное время на поддержку? Порой мы тратим слишком много времени на вещи, которые повторяем ежедневно. А что, если можно оптимизировать и эту часть? Ведь сэкономленные 5 минут на лишний вход в Конфигуратор, описание сообщения для пользователя при закрытии базы ежедневно (а может быть и несколько раз на день!) смогут накопить часы свободного времени! Ну а куда потратить это время - всегда найдется;) Даже продлить время на выполнение более интересных задач и повысить производительность в связи с переключением с задачи на задачу - уже позитив.

Так что как не крути – автору 5!

(14) IgorS,
Без демонстрационной конфигурации с реализацией упомянутых механизмов вся статья - пустое "бла-бла-бла", полезный эффект от которого стремится к нулю.

Порой толковая идея - это нечто большее, чем просто кусок кода. Как минимум - логику данного механизма можно применять не только при блокировке соединений... Здесь описаны вещи более глобального характера;) Если бы еще суметь применить такой подход при подготовке к свиданию=) Ведь по сути - повторяю те же самые действия! А вот нажать бы кнопку - и все готово! Не нужно огромный алгоритм держать в голове!)
А с другой стороны - по себе сужу... Человек - ленивое существо) Если получаю готовый работающий механизм - я до конца не вникаю в концепцию реализации, а иногда и совсем не задумываюсь о глубине проработки! А ведь можно так многие полезные идеи упустить;)
18. Юрий Сафонов (Ted1982) 02.01.15 16:50
Тот же принцип и тот же функционал был реализован в данной обработке http://infostart.ru/public/90241/, которая была сделана уже очень давно (2011 год). Не понимаю, что нового/необычного в данной обработке.
19. Виталий Роженюк (nimus) 02.01.15 17:26
(17), спасибо за внятный комментарий )

(18), по реализации столько отличий, что можно предложить найти 12 отличий ;)
20. Руслан Ибрагимов (break) 03.01.15 07:16
а как обстоят дела с уведомлением пользователя если 1С свернута? или включилась заставка?
21. Виталий Роженюк (nimus) 03.01.15 11:31
(20) - выводятся модальные окна в окне 1С. Т.е. на свернутой 1С помигает несколько раз приложение 1С, но само не развернется. Если пользователь не заметил и не закрыл сам, после 3-го уведомления приложение будет закрыто.
22. andrey dyak (dyak84) 03.01.15 12:19
Автор как теоретическая статья ну просто на 5+. Как практически ничего нет, а картинками сыт не будеш. Выложите пожалуйста теперь практическую часть. Зарание спасибо
Бурухтан Второй Второй; zorka-gold; andy23; +3 Ответить
23. Тарас Курдельчук (softgarant) 03.01.15 13:36
Вот и я не сдержался чтобы не высказать свое недовольство - а почему без куска кода. Да я читал что идея важна, но идейных много, это не эксклюзивная реализация, это субъективное мнение.
24. Babuin 04.01.15 13:31
(16) nimus, по несколько раз в день прерывать работу сотен и тысяч пользователей.
И резервное копирование в таких базах точно нужно делать не так.
или для резервного копирования в ночное время средствами конфигуратора "1С:Предприятия", а не сервера баз данных (размеры копии всё же очень значимо отличаются при применении этих подходов).


25. Виталий Роженюк (nimus) 04.01.15 16:00
(24), это от ситуации зависит. Например, мы обслуживаем 3 активно используемых программных комплекса, где количество пользователей находится как-раз между сотнями и тысячами. Но специфика их такова, что ночью с ними не работают. При размере баз около 200Гб, резервное копирование средствами SQL, конечно, возможно, но не позволяет хранить длительную историю копий, что иногда полезно. Резервные копии средствами 1C при этом в зависимости от конфигурации составляют от 2 до 10Гб. Обновление на этих комплексах проводится 1 или 2 раза в день. В 22:00 и, в экстренных ситуациях, в 12:00 (обеденное время работников предприятия). Вот в таком случае всё сказанное верно )
Конечно, если речь о круглосуточно используемых высоконагруженных комплексах, то обслуживание проводится не так. Но доработки и обновления всё равно нужны. Пусть и в середине ночи, но если есть шанс, что кто-то работает - надо пользователей попросить выйти корректно.
26. Роман Ложкин (webester) 05.01.15 04:04
(17)
Порой толковая идея - это нечто большее, чем просто кусок кода

В корне неверное убеждение. Есть мнение, что любая самая гениальная идея, ничто без реализации, в то время как реализация в любом случае несет в себе и саму идею и код в том числе, если он нужен для реализации. Картинки в статье для 99% прочитавших ее так и останутся картинками. А значит статья как таковая не имеет смысла, ну кроме как похвастаться.
27. Виталий Роженюк (nimus) 05.01.15 11:05
(26), как думаете, почему software-архитекторы оплачиваются в разы больше, чем кодеры? Сколько людей сможет сделать программу по ТЗ, а сколько может спроектировать программу так, чтобы на ее разработку ушло минимум времени, она решала все поставленные задачи и всем устраивала заказчика? Это я к тому, что к фразе "В корне неверное утверждение" корректнее было бы добавить "По моему мнению, ...".
28. Мищенко Вадим (vslimv) 05.01.15 13:23
Вместо того чтобы ругаться со всеми и мерится заработком, выдавая философские тезисы, лучше бы выложили .cf или четко отказали людям.
29. Виталий Роженюк (nimus) 05.01.15 13:55
(28) vslimv, не стоит так перекручивать сказанное. И ругани не было, и заработками никто не мерялся. Но девушка выше написала умную мысль, поэтому я и попросил критикуя быть корректными.
По cf. Это публикация в разделе статей. Когда появится возможность запостить конфигурацию - она появится в другом разделе.
31. Алексей Захаров (almas) 06.01.15 09:50
Примерно то-же самое на упр формах: http://infostart.ru/public/281099/
Жаль, что 1с-не понимает важности данного направления и не стремиться реализовать это в платформе.
32. Кирилл Бондаренко (karapuzzzz) 08.01.15 16:24
(19) nimus, ах, ну да. Тут все увидели Ваш код и смогли сравнить его с другими вариантами. А судя по возможностям, то та обработка почти ничем не отличается от Вашей. Мы же сравниваем функционал и идеологию подхода? Тогда отличий меньше чем 12.
33. Babuin 08.01.15 18:23
(25) nimus, когда обслуживаются такие комплексы как правило существуют такие понятия как SLA, время доступности систем, управление изменениями, релизами.т.д. Организовываается различные процессы и регламенты их регулирующие. Когда есть работающий процесс как правило достаточно работы консоли сервера и суперперделки по выгону пользователю нах не нужны.
Бэкап таких комплексов опять же только SQL. У sql есть замечательная фича сжатия бэкапа,если уж нужно организовать архив с большой глубиной хранения.
Итого такая фича по выгону пользователей нужна в небольших конторах, базах. Когда нет смысла организовывать процессы, обновлять конфу хоть ежечасно.
34. Павел Колмаков (Stim213) 12.01.15 09:46
Настоящий такой велосипед, блестящий и яркий, с лампочками и звоночками, почти как штатный одинесовский..

только зачем в одной базе 2 велосипеда - не понимаю
35. Виталий Роженюк (nimus) 13.01.15 21:16
(33) Babuin, В бекапе средствами SQL есть одно бо-о-ольшое отличие от бекапа, сделанного средствами 1С. Понять его можно изучив в профайлере размер наиболее крупных таблиц базы данных. Это таблицы остатков и оборотов регистров накопления, расчета, бухгалтерии. При качественной отработке производительности эти таблицы в сотни и тысячи раз превосходят по размеру таблицы самих регистров. Угадайте, попадают ли таблицы остатков и оборотов в бекап средствами SQL? Попадают. А в бекап средствами 1C не попадают. Благодаря этому в ряде случаев, например, как на наших базах, размер бекапа средствами 1С составляет примерно 2Гб, а средствами SQL - 200Гб. Всего 100-кратная разница. Разве она не стоит того, чтобы использовать доступный функционал, если специфика работы организации или предприятия позволяет на час ночью закрыть базу?
36. Babuin 14.01.15 13:31
(35) nimus,
А в бекап средствами 1C не попадают.
Т.е если вы из этого dt файла загрузите базу, у вас этих таблиц не будет?)
200 ГБ бэкап сиквельный это уже со сжатием? т.е у вас база порядка 500 ГБ? и dt такой базы получается 2ГБ? что то где то несходится.
Самая главная причина почему не стоит делать DT для хранения информации, это то что есть вероятность невозможности загрузить этот dt.
Ну если уж на то пошло и dt нужны позарез, можно организовать промежуточную базу в которую средствами SQL загружать бэкап и оттуда уже выгружать dt не выгоняя пользователей.


37. Виталий Роженюк (nimus) 14.01.15 17:21
(36) Babuin, да, базы около 500Гб. Размер dt от 2 до 8Гб в зависимости от метода хранения истории изменений.
А таблицы остатков не попадают в dt-файлы, так как в этом нет необходимости. При поднятии базы остатки рассчитываются, а не загружаются.

С проблемами поднятия базы из dt файлов за 10 лет применения 1С на предприятии проблем не наблюдалось ни разу, а делается это ежедневно.

И дабы не впадать в пустую полемику, очень прошу обратить внимание, что для оговоренного варианта конкретно указаны условия, когда он полезен. В нашем случае такая схема обслуживания наиболее удачная, так как ночью базы не испльзуются, экономия дискового пространства значима и размер sql-копий не позволяет их записывать на ленточные носители. Если для Вас эти преимущества не значимы или нет возможности на час в сутки ограничивать работу с базой - конечно остается делать монстрокопии силами сервера баз данных. Но я точно знаю, что как минимум для ряда организаций описанная схема оказалась очень удобной.
38. Сергей Рудаков (fishca) 20.01.15 11:15
Самая главная причина почему не стоит делать DT для хранения информации, это то что есть вероятность невозможности загрузить этот dt.

Самая главная причина почему не стоит пить водку, это то что есть вероятность стать алкоголиком. :)
Для написания сообщения необходимо авторизоваться
Прикрепить файл
Дополнительные параметры ответа