Страница 1 из 1

"Жирный" NRec, сгенерированный со стороны - пробле

Добавлено: 18 дек 2006, 10:08
Goblin
При экспорте данных из сторонней системы в Галактику приходится генерировать NRec с запасом , дабы не пересекалось с родными записями (таблица Katsopr, только документы по ТМЦ , документы по услугам - остались в галактике). Дабы не было конфликта , NRec при экспорте брали с запасом - получался вида 00FFXXXXXXXXXXXX. После проведения съэкспортированных документов в интерфейсах складских ордеров интересная вещь наблюдается - номер накладной/акта, по которому сформирован ордер, из подцепленной Katsopr к Sklorder, начинает плыть, хотя ссылка нормально прописана(наблюдается только в ордерах, созданных по съэкспортированному документу).

Нет ли каких интересных тонкостей именно с номером офиса (FF - в системе нет, есть только номера 201,202,203 - C9,CA,CB соотвественно) в подцепке, не рушится ли там что-либо при наличии записей по несуществующему офису(что скорее всего вряд ли, ибо у многих репликация даже не используется ) или именно с номером офиса FF ?

Добавлено: 18 дек 2006, 10:39
Goblin
Упс, все выяснилось ...
Номер выдавется через функцию , а не через прямое обращение к полям,вместе с дескриптором менеджера, который у документов, экспортированных со сторонней системы, незаполнен ... Видимо у функции просто не чистится буфер и выдается последний непустой результат ...
Жирный NRec оказался непричем

Добавлено: 18 дек 2006, 13:05
WiRuc
Зачем такие извращения?
Использовали бы стандартную генерацию NREC с помощь расширенных ХП.

Добавлено: 18 дек 2006, 16:32
Goblin
Какие такие ХП на Pervasive ??? :D

Добавлено: 19 дек 2006, 07:35
Алексей
Goblin
т.е. вы получаете ДБФ файл и просто его добавляете к существующим записям?
а что мешает сделать прог-му на вип и добавлять всё это с нормальной генерацией НРЕКа?

Добавлено: 19 дек 2006, 08:56
Goblin
Да вот то и мешает , что часть справочников и документов ведутся в сторонней программе, и если не там генерить NRec, а отдать его на откуп стандартного механизма при Insert'е- то потом синхронизация последующих изменений просто не состыкуется.

Зачем вообще заморачиваться с этим - лучше не спрашивайте. В описании причин не матерщиной будут только предлоги "в", "на" и "по"
:D
Идиотизм и мракобесие в нашем IT-департаменте цветет буйным цветом.