Вопросы по обновлению SD и дисковому пространству FTP сервера

1) Нет
2) Нет, но почему, же… это, же XML загрузить значит можно,. только это не быстрый процесс… и номера будут другие, нужно будет в новые поля передавать значения старых ID
3)Не совсем понятен вопрос…
4) Да есть такая доработка Позволяет из любых объектов удалить вложения по фильтру, т.е например нужно удалить только вложения из обращений которые созданы в 2006-7 году. И не являются заявками. (удалятся только вложения).
5)Если бизнес логика от штатного изменялась, то я бы именно так и сделал… только базу и app сервер.
6) Видео Вечером могу выложить еще видео. Установка чего именно интересует?

3) Он выгружает все поля, как есть, т.к если в объекте есть ключевое поле, по которому можно найти, то по нему и делать поиск. Неудобно, но жить можно. Еще как вариант, это сделать архивный сервер, а с боевого сервера удалить все объекты которые можно отнести к архивным данным.
Получиться, если нужны архивные данные, то специалист меняет только имя сервера подключения.

4) А как мы определим, что данные являются устаревшими? По дате создания? А если фтп меняли с диска на диск? Или, допустим, есть объект с номером 1234 создан в 2008 году. А в 2011 году этот объект добавили файл, выходит, что у данного объекта 1 файл является новым, а объект относиться к архиву.
Читабельны будут, вопрос в другом, как удалить только те объекты, которые действительно нужно удалить, а если требуется сохранение заявок, скажем, придет проверка и скажет, а на основании чего Иванову предоставили доступ? Поиском по базе можно будет найти в два счета, а если элемент удален, то придется мало того что долго и упорно ковырять xml еще придется искать все вложения которые были в данном обращении…

5) FTP меняли на более ранней стадии, чем 23 пак, поэтому можно использовать и боевой, только очень осторожно. Я бы поднял новый FTP и не подключал его к боевому серверу, на то это и тестовый стенд. И без FTP стенд работать будет, все зависит от того, что на нем тестировать.

6) Тут не все так просто с SP, если в систему внедрялись сторонние обновления, в хостфикс, или еще как, то желательно на тестовом стенде произвести обновление.. и посмотреть на кол. Ошибок, если они будут, и методы их решения. Посмотреть, как делается обновление локальных клиентов удаленно, настроить все на тестовом стенде, оттестировать все пару раз, а уж потом и делать обновление. При этом уведомить всех специалистов, что их ожидает при запуске системы. Ну и соответственно указать им какие новшества их ожидают.

Ок, хорошо что все подробно ответили.
Для себя сделал следующие выводы:
1) Чтобы освободить место на FTP сервере, необходимо выгрузить (архивировать) servicecall и связанные workorder на локальную машину вместе с attachements. В дальнейшем можно как-то работать с этими XML или импортировать в SD.
2) Чтобы накатить SP необходимо сначала сделать тестовый сервер - копию боевого и тестовую базу - копию боевой. FTP не обязательно копировать т.к. он занимает много места и оттестировать можно без него. Далее накатываем SP на тест и убеждаемся что все работает норм.

Такой вопрос. Вот сделал я копию боевого сервера и поместил ее на тестовый. Какие мне нужно сделать действия чтобы новый тестовый сервер не мешал работе боевого и жил своей, отдельной жизнью?

Добрый день.
Сделал копию боевого сервера, поставил на тестовый. Базу также клонировал. Путь и логин к базе в тестовом сервере изменил.
Проблема в том, что тестовый и боевой сервера работают вместе. Т.е. если завести заявку в тестовом, она видна на бою. Необходимо чтобы тестовый и боевой сервера работали раздельно.
Посмотрел реестр тестового сервера, там все пути указаны как на бою, т.е. servicedesk01.домен.ru.
Нужно править реестр или запускать какую-то утилиту по перенастройке?