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

[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 без ядерных ролапов.

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

[KiselevSA]

Цитата:

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

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

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

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

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

И у меня все работает. Все-таки дела в разных структурах данных. Если грохнуть поле в середине в таблице, а потом создать его в конце таблицы, импорт начинает ругаться (хотя, может я еще что-то задел)