|
![]() |
#1 |
Участник
|
Цитата:
Проблема с изменением поля в том что если табличка непустая, то аксапта создает новую табличку, такую же по структуре и новой длиной поля. Переливает данные из одной таблички в другую, старую грохает, а новую переименовывает. А затем с нуля индексирует ее. На перелив данных и индексацию уходит много времени (если табличка миллионник) Мы придумали обходной финт. Если строковый EDT меняет длину, то собираем перечень табличек и полей на которые это повлияет, генерим для них SQL запросы вида ALTER TABLE ... MODIFY FIELD изменяя длину поля и обновляем также инфу в системной табличке SQL Dictionary После этого аксапта при синхронизации ничего не трогает (мы ведь все сделали за нее). Отрабатывает такая полуручная "синхронизация" мгновенно. Но если поле для которого хотим поменять длину индексировано, то БД посылает на попытке изменения длины, приходится грохать индекс, менять длину и заново строить индекс. Т.е. выигрываем на переливке данных все равно, но можем потратить много времени на переиндексацию (о чем я и упомянул). А поскольку номер документа это ключевое поле которой входит в первичный ключ и почти во все foreignKey то ... Приходится кучу индексов пересоздавать и тратить на это много времени. 2 часов на всю базу не хватает. Ну и плюс опять же размер индексов вырастать будет если реально будут 50 символов заполнять. Последний раз редактировалось Logger; 09.02.2017 в 15:37. |
|
![]() |
#2 |
Moderator
|
Цитата:
И какая у вас версия SQL ? |
|
![]() |
#3 |
Участник
|
Цитата:
Цитата:
ORA-30556: functional index is defined on the column to be modified
Поговорил с DBA. Проблема в функциональных индексах. Без них все ок. Попробовал сам, действительно без функциональных индексов все ок. Запрос такой X++: ALTER TABLE TESTTABLE MODIFY TEXTFIELD NVARCHAR2(50) |
|
|
За это сообщение автора поблагодарили: fed (1). |
![]() |
#4 |
Участник
|
А сколько сейчас времени у вас тратится при варианте пересоздания индексов, хотя бы порядок, если конечно пробовали? Просто при временных затратах в десятки часов, вариантов вроде не так много остается. В стандарте вроде как FactureExternaId_RU имеет длину 30 символов, у вас также ?
Можно же попробовать в два этапа провести увеличение длины номеров отдельно номера фактуры, отдельно накладные(скажем если бы два этапа шли последовательно условно в неделю разницы, то вполне можно написать джоб, который бы обновил номера накладных из фактур(правда, может с внешними обменами будут проблемки небольшие), в случае если у вас текущие размеры их совпадают, если же фактура больше и сейчас, то проблем по идее и так быть не должно). Цитата:
Б. Много неоднозначностей в каком случае какое поле использовать и как заполнить обычный InvoiceId (как усечь номер от поставщика, чтобы не получить кучу дублей)
__________________
Sergey Nefedov |
|
|
За это сообщение автора поблагодарили: Logger (3). |
![]() |
#5 |
Участник
|
Цитата:
Цитата:
Цитата:
Поговорили еще с DBA. Мне все больше нравится вариант 1. Возможно что нить придумаем как сделать. Как вариант - пропатчить ядро чтобы аксапта научилась работать с БД в регистронезависимом режиме без всяких функциональных индексов. Тогда и проблемы не будет никакой. Длины полей увеличатся легко. |
|
![]() |
#6 |
Участник
|
Цитата:
Т.е. условно вместо 20 минут на одну таблицу + 20 минут на другую итого 40. Получите 20 минут на обе.
__________________
- Может, я как-то неправильно живу?! - Отчего же? Правильно. Только зря... |
|
|
За это сообщение автора поблагодарили: Logger (1). |
Теги |
factureexternalid, invoice, invoiceid, num, электронная отчетность, электронный сф |
|
|