Комментарии 29
«При этом конфигурацию можно поставить на поддержку» — это как «чудо чудесное» (@малышева), зачем тогда плодить различные базы «с идентичными объектами метаданных»?
В статье разбирается реальная ситуация, когда в «старой» конфигурации поставщика использовался один объект конфигурации, а после значительного обновления продукта в новой конфигурации — используется другой объект, с идентичными реквизитами, но другим УИДом. Задача была — перекинуть данные с минимальными выгрузками/загрузками для ускорения обработки большого объема данных и максимального снижения риска затронуть движения прошлых периодов
Вмешательство в базу на уровне СУБД нарушает лицензионное соглашение 1С.
Выбирая между десятками часов пользователя (они еще и ошибок наделают) и нескольких часов программера, решение очевидно.
Какой ужас… Их теперь страшно накажут, да?
А я читал мнение, что пользователь вправе работать со своими данным так, как ему необходимо.
С данными своими делайте, что хотите, но инструментами, которые вам дали в аренду, будьте любезеы пользоваться на условиях арендодателя.
Так речь ведь и идёт о работе с таблицами в базе MS SQL.
Программные файлы самой платформы 1С тут никак не затрагиваются.
Программные файлы самой платформы 1С тут никак не затрагиваются.
Таблицы в базе MS SQL, которые создала платформа 1С для внутренних нужд в закрытом формате.
Ну, это же просто таблицы в которых кранятся данные прикладных объектов.
Они не для внутренних нужд.
Можно ли представить, что любая программа работающая с базой в MS SQL может запрещать вам отдельно работать с её таблицами через SQL Management Studio?
Они не для внутренних нужд.
Можно ли представить, что любая программа работающая с базой в MS SQL может запрещать вам отдельно работать с её таблицами через SQL Management Studio?
Вы не должны знать, что там хранится, формат закрытый. Можно представить да, вот 1С запрещает. Либо используйте программу, соблюдая лицензию, либо не используйте.
Да, в конторах, где приходится ГУИДы скрещивать вручную при обновлении, может быть об этом пока не догадываются. Но в корп. сегменте таким серым решениям дорога закрыта — только поэтому я не понимаю, кому и зачем эта статья нужна на Хабре, когда для этого есть профильные ресурсы.
Да, в конторах, где приходится ГУИДы скрещивать вручную при обновлении, может быть об этом пока не догадываются. Но в корп. сегменте таким серым решениям дорога закрыта — только поэтому я не понимаю, кому и зачем эта статья нужна на Хабре, когда для этого есть профильные ресурсы.
Согласитесь, раз людам приходится этим заниматься, значит для них это оптимальный путь.
Получается, что типовые возможности 1С при обновлении не позволяют корректно обработать ситуацию с полным сохранением данных в базе и без необходимости дальнейших переносов данных между объектами.
И наобходимость «скрещивания» возникает, мне кажется, как раз в корп. сегменте с большими объёмами данных.
В базе какого-нибудь ларька плюнули бы на потерю и быстренько внесли документы заново.
Получается, что типовые возможности 1С при обновлении не позволяют корректно обработать ситуацию с полным сохранением данных в базе и без необходимости дальнейших переносов данных между объектами.
И наобходимость «скрещивания» возникает, мне кажется, как раз в корп. сегменте с большими объёмами данных.
В базе какого-нибудь ларька плюнули бы на потерю и быстренько внесли документы заново.
С этим я и не спорил вроде как. Более того, я на личном опыте не раз сталкивался с аналогичной проблемой и технически это решение оптимальное, да. Но, во-первых, с каких-то пор считается приемлемым публиковать серые схемы на белом ресурсе? Тем более в блоге крупной компании! Во-вторых, в кривых руках это знание несет больше рисков, чем пользы. Намудрив с базой на уровне СУБД можно наделать таких проблем, которые всплывут сильно позже, когда они уже расползутся по бэкапам.
Более того, я на личном опыте не раз сталкивался с аналогичной проблемой и технически это решение оптимальное, да
Как обычно, существенные недостатки используемого инструмента приводят людей к поискам решения.
Нельзя их за это осуждать
Намудрив с базой на уровне СУБД...
Естественно, предполагаю, что всё предварительно проверяется на копии базы.
Наоборот, когда у вас террабайтные базы, только такое решение и имеет смысл
То, которому дают таблетку от жадности в половине контор?
Неоднозначная формулировка. Ребилд индексов, обновление статистики тоже можно привести к этой фразе, а ведь ребилд и обновление статы есть на ИТС.
Ваш способ применим только для серверных баз?
Можно и для файловых применять, но в таком случае понадобится инструмент для доступа непосредственно к конфигурации базы данных, чтобы перекинуть УИДы в ней. Глубоко не погружался в структуру хранения данных в файле .1CD, но полагаю, что в нем также должна быть таблица связи логических и физических данных.
Для переброски данных я пишу SELECT с подменой ID записи, потом через приложение ImportExportDataSql выгружаю результат в виде SQL скрипта (UPDATE or INSERT). Приложение можете скачать бесплатно, постоянно его дорабатываю и пользуюсь им ежедневно. Рекомендую его всем, кто работает с SQL Server.
А переименовать таблицу не сработало бы?
При чём тут тег «битрикс»?
а флажок «удалить отсутствующие в файле поставки объекты» не пробовали отключить?
понятия не представляю зачем так заморачиваться
понятия не представляю зачем так заморачиваться
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Переброска данных между идентичными объектами метаданных базы 1С через подмену УИДов в базе SQL