генерирование RecId

[Дмитрий]

может кто эксперементировал в этом направлении?
интересует возможность инсерта в таблицы Ах из "посторонних"
источников, т.е. непосредственно в базу. возможно ли искуственно
генерировать RecId после инсерта?
можно конечно создавать n пустых записей Ах'ой а потом их update,
но это имхо громоздко.

Д.К.

[mazzy]

Экспериментировал. Следы привели к таблице UtilElements.

Посмотрел и плюнул:
1. это системнозависимая таблица. Решил в ней не копаться и к ней не привязываться.
2. так и не понял как она работает, если appl каталоги разные.

Решил заставлять Аксапту создавать записи через COM.
Может быть и зря. Но не уверен, что такие знания пригодятся в следующей версии.

[skof]

В прошлом году мы разрабатывали систему синхронизации нескольких баз данных
Axapta, так что бы сама система "не видела" синхронизации, и решали эту проблему.
Вот выдержка из нашей документации по системе синхронизации:

В поле DataAreaId хранится идентификатор компании, к которой принадлежит данная запись в нашем случае это: «Hld», «Msk», «Pit» и «Tvr». В поле RecId хранится порядковый номер записи, который уникален во всех записях, принадлежащих одной компании во всех таблицах. Таким образом, сочетание этих полей дает уникальный ключ, который мы и будем применять.
Здесь необходимо знать о правилах присвоения значения поля RecID. Axatpa не пользуется никакими сервисами базы даных для вычисления нового номера в этом поле. Вместо этого она ведет таблицу SystemSequences следующей структуры:

Имя столбца | Тип | Значение по умолч. | NULL | Описание столбца.
ID | NUMBER(10) | 0 | NOT
NEXTVAL | NUMBER(10) | 0 | NOT | Начало следующего пула номеров
MINVAL | NUMBER(10) | 0 | NOT | Минимальный номер
MAXVAL | NUMBER(10) | 0 | NOT | Максимальный номер
CYCLE | NUMBER(10) | 0 | NOT | Номера по кругу
NAME | VARCHAR2(20) | ' ' | NOT | Наименование последовательности
TABID | NUMBER(10) | 0 | NOT
DATAAREAID | VARCHAR2(3) | 'dat' | NOT | Идентификатор компании
RECID | NUMBER(10) | | NOT | Номер записи

Работает AXAPTA с этой таблицей следующим образом:
1. При вставке первой записи в новую компанию система AXAPTA добавляет в таблицу SystemSequences запись. В поле DATAAREAID устанавливается значение равное идентификатору компании, а в поля MINVAL и NEXVAL записывается единица.
2. Сразу после этого система AXAPTA берет лот номеров (лот в данном случае это - несколько подряд идущих номеров, AXAPTA берет 25). И записывает в поле NEXTVAL следующий свободный номер – 26.
3. Заносит в таблицу, с которой все началось запись с RECID равным 1 и DATAAREAID равным идентификатору компании.
4. После того как номера в лоте заканчиваются, система AXAPTA снова читает таблицу SystemSequences, берет оттуда NEXTVAL как первый номер следующего лота. А в таблицу SystemSequences записывает значение NEXTVAL+25.
Таким образом AXAPTA решает две проблемы – каждый пользователь ведет свой лот номеров RECID и значения этого поля не пересекаются, второе – пользователь (вернее его приложение) обращается к таблице SystemSequences один раз на 25 операций вставки и таким образом не возникает ожидания из-за обращения всех к этой таблице.


Надеюсь понятно...
К сожалению таблица рассыпалась, но заинтересованные лица я думаю восстановят...

[mazzy]

Спасибо!!! Очень ценная информация.

Есть ли изменения в алгоритме в разных сервис-паках самой Аксапты?

[Дмитрий]

Я уже потерял надежду на ответ. Приятно удивлен. Спасибо.

Д.К.

[rdv]

Цитата:

Изначально опубликовано skof
В прошлом году мы разрабатывали систему синхронизации нескольких баз данных
Axapta, так что бы сама система "не видела" синхронизации, и решали эту проблему.
Вот выдержка из нашей документации по системе синхронизации:

Не могли бы вы поподробнее рассказать о системе синхронизации?
Это что закачка данных нескольких компаний в одну базу? Или это репликация данных? Или что-то еще.
Вопрос в общем то в следующем: пока тонкий клиент работает по выделенной лини все хорошо. Но линия в любой момент может пропасть, всякое бывает!
Нужно обеспечить работоспособность клиента и все что он наизменял передать в центральную базу данных. Если же ремонт лини продолжается, например, больше суток, то следуют организовать передачу информации дискетами с курьером.
Решает ли ваша система эти задачи?

[skof]

Поподробнее можно - система написана еще под Конкорд, разработана под Оракл, прерывания линий поддерживает, перенос на дискетах - с определенными ограничениями можно реализовать, требует наличие серверов баз данных на обоих концах линий, т.е. ваш тонкий клиент должен иметь на своем филиале сервер Оракл,
по своей сути данная система подобна репликации реализованной в MSSQL, но на момент своей разработки делала больше чем родная мелкомягкая репликация и наверное сейчас - таже ситуация...

[Vadik]

Можно поподробнее насчет того, что есть у Вас и не реализовано у MS? А то как-то за ребят обидно

Для того, чтобы иметь две базы, нужно Аксапту два раза купить?

[skof]

Цитата:

Изначально опубликовано Vadik
Можно поподробнее насчет того, что есть у Вас и не реализовано у MS? А то как-то за ребят обидно

Для того, чтобы иметь две базы, нужно Аксапту два раза купить?

За ребят не обдно:
1. Они не ставили перед собой таких "спецфических" задач...
2. Они живут в стране где связь не пропадает...

Основное отличие - до недавнего времени у нас был более тонкий механизм выборки какие записи синхронизировать а какие -нет, что MS наворотили в последних версиях - я не знаю, может уже все это есть

Насчет еще одной - Аксапты - консультируйтесь с тем кто вам ее продает...