импорт при несовпадающих tableid

[Asterisk]

Кто-нибудь сталкивался с проблемой не работающего экспорта через группы определений при несовпадающих tableid исходной и конечной таблицы. Есть две Аксапты - в одной таблица изначально определена на cus слое и имеет tableid 30018 , в другой - на usr слое и имеет recid 50135. При этом стандартный экспорт через группы определений не работает , так как не совпадают ни tableid ни reid у двух таблиц с полностью идентичным словарем
Есть какой - нибудь workaround для этой проблемы ?

[KiselevSA]

Выгрузить данные из приложения, в которое нужно произвести закачку.
Сохранить def файл.
Выгрузить данные из другого приложения.
Заменить def файл. Закачать. По идее, если нет различия в структуре, должно пройти

[Asterisk]

Спасибо . Только видимо не для данного случая . По крайней мере во время импорта опять была ругань . Хотя идея очень красивая

[KiselevSA]

Цитата:

Сообщение от Asterisk

Спасибо . Только видимо не для данного случая . По крайней мере во время импорта опять была ругань . Хотя идея очень красивая

Сравните структуры и порядок полей в двух def файлах. Ошибка, скорее всего там. Если не поможет используйте импорт через csv.

[Asterisk]

А разве при импорте через csv не такой же принцип импорта - импорт идет по recid ? Насколько я понял имеется в виду что при экспорте надо указать тип файла csv формат . Однако при этом Axa опять создает def и dat файлы - чем ситуация отличается - честно говоря , не понимаю . Точнее даже , я не совсем понимаю почему называется импорт в csv - ведь файл в формате csv не создается ?

[KiselevSA]

Выгрузить данные в csv (txt файл с определенным разделителем) достаточно легко. При импорте можно будет управлять порядком данных (столбцов), а вот id полей уже никакого влияния не окажут

[Asterisk]

А как именно ? Если просто указать csv файл в меню Параметры экспорта то мы имеем на выходе два файла - dat и def (см предыдущий пост) Какой из них считается csv ??

[mazzy]

Цитата:

Сообщение от Asterisk

А как именно ?

Скорее всего имелся в виду импорт из текстового файла
http://axapta.mazzy.ru/lib/import/

[glibs]

1. Создал табличку. Имя (метку в названии) ей указать забыл.

2. Экспортировал в .xpo

3. Ввел три строчки.

4. Экспортировал табличку в .dat

5. Удалил табличку.

6. Импортировал .xpo

7. Убедился, что изменился ID таблички.

8. Импортировал данные. Хм... Пишет, что импортировало 0 записей.

9. Убедился, что в табличке три записи.

В общем-то, даже и не сомневался, что оно работает.

Как воспроизвести вашу проблему? И при чем здесь RecId, если речь идет об идентификаторах таблиц и полей, а также о переносе кода между слоями?

[KiselevSA]

Скорее всего не совпадает структура данных. В этом случае единственный доступный способ - закачка не из двоичного файла.

[Artem Mikhailov]

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

делайте экспорт с типом csv, в текстовом редакторе в дат и деф-файлах массово заменяйте один tableid на другой

[KiselevSA]

Цитата:

Сообщение от Artem Mikhailov

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

делайте экспорт с типом csv, в текстовом редакторе в дат и деф-файлах массово заменяйте один tableid на другой

Откуда такие сведения? Разбор метода record2con в SysDataExport не выявил высказанного

[glibs]

Цитата:

Сообщение от Artem Mikhailov

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

М.б. Я точно не помню. Но там есть мощный алгоритм, который .def файл разбирает. И, если мне не изменяет память (смотреть лень), изменение идентификатора таблицы он отлавливает (по-моему, по имени). Да и опытным путем работоспособность импорта подтверждается.

[raz]

Может у таблицы выключен параметр saveDataPerCompany и система считает ее системной... тогда надо галочку пометить (импортировать системные).

[Artem Mikhailov]

покажите первую строку дефа
для EXPFORMAT VER. 3.0 CIS SP2 это так

для более поздних я думаю эта нелепость с совпадением тейблайди устранена

[Artem Mikhailov]

Цитата:

Сообщение от KiselevSA

Откуда такие сведения?

3.0 cis sp2. сделайте экспорт в формате сsv, откройте дат-файл в блокноте. второе поле по всем строкам - tableid. после его замены на новое значение аксапта всасывает файл не поперхнувшись

[KiselevSA]

Цитата:

Сообщение от Artem Mikhailov

3.0 cis sp2. сделайте экспорт в формате сsv, откройте дат-файл в блокноте. второе поле по всем строкам - tableid. после его замены на новое значение аксапта всасывает файл не поперхнувшись

А вот Вы о чем. Никогда не использовал стандартную выгрузку в csv для импорта, только двоичный формат. Я говорил о группе определений для экспорта/импорта с типом "Произвольный". Для таких типов доступен только импорт, но можно подключать обработки и указывать набор и порядок полей.

[Asterisk]

Насколько я понял , обсуждение пошло по двум параллельным направлениям Glibbs сомневается в существовании проблемы , Артем в ее существовании не сомневается и пытается дать совет.
Предлагаю сперва определиться с тем что проблема все таки есть Мощный алгоритм , по всей видимости , все таки не отслеживает изменения id шников полей . В принципе мне это кажется логичным - любой алгоритм должен использовать минимальный набор данных и работать быстро .Поэтому стандартный алгоритм отталкивается от id шников и предполагает что id таблицы и полей при импорте не меняются
2 raz : SaveDataPerCompany у таблицы включен

Алгоритмы связанные с заменами , подменами и переименованиями id -шников очень интересны , но у меня например возникали ошибки и результат был нулевой
Потом ручное переименование 10 полей

[Asterisk]

(продолжение) это одно , а если полей 50 ?? Это может привести к трудно уловимым ошибкам при экпорте

Хотелось бы все таки поставить оптимистичную точку в этом обсуждении . Я воспользовался стандартной функциональностью SQL server а - создал DTS package в Data Transformation Services\Local Packages создал там необходимое количество task ов для импорта - и вперед
При это столкнулся с двумя проблемами
1) Была ругань на consistency поля recVersion - убрал соотвествующую трансформацию на закладке transformations
2) В исходной базе компания была wrk , в конечной - dat - соотвественно поменял dataareaid уже в Аксапте при помощи UserConnection

UserConnection connection = new UserConnection();
Statement statement;
;
ttsbegin;
statement = connection.createStatement();
statement.executeUpdate("Update " + <название таблицы> +
" SET " + chooseTable.text() + ".DataAreaId = '"
+ <название компании>+ "'");
statement.close();
ttscommit;
element.close();


Вот пожалуй и все . Не могу сказать что все прямо совсем оптимально (например компанию скорее всего можно было поправить еще при импорте в SQL) , но по крайней мере это работает и проблем вроде нет


Всем большое спасибо за помощь !

[glibs]

Цитата:

Сообщение от Asterisk

...
Предлагаю сперва определиться с тем что проблема все таки есть Мощный алгоритм , по всей видимости , все таки не отслеживает изменения id шников полей . В принципе мне это кажется логичным - любой алгоритм должен использовать минимальный набор данных и работать быстро .Поэтому стандартный алгоритм отталкивается от id шников и предполагает что id таблицы и полей при импорте не меняются
...

М.б. перейдем от теории к практике?

Я снова поставил эксперимент.

1. Экспортировал данные из описанной выше таблицы в двоичный формат .dat.

2. Экспортировал данные из описанной выше таблицы в двоичный формат .csv.

3. Экспортировал таблицу со значениями идентификаторов.

4. Удалил таблицу.

5. Открыл .xpo файл и поменял илентификаторы таблицы и полей на левые.

6. Импортировал таблицу.

7. Убедился в том, что идентификаторы в таблице (для таблицы и для поля) именно такие, как я из ввел в .xpo файле.

8. Импортировал данные из .dat файла. Ошибок при импорте не было. Данные присутствуют.

9. Удалил данные из таблицы.

10. Импортировал данные из .csv файла. Ошибок при импорте не было. Данные присутствуют.

Существует практический способ воспроизведения вашей проблемы?

Аксапта 3.0 ЕЕ сп5 без ядерных ролапов.

Эта хрень работает. Ею можно пользоваться для выгрузки-загрузки данных. Конечно, можно придумать и другие способы импорта данных, если именно это является вашей целью...