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