Импорт из буфера

[vey]

Кто-нибудь сталкивался с задачей импорта данных в Axapta из буфера? К примеру, нужно импортировать ряд новых номенклатур, которые поступают сотруднику в файле формата .xls от поставщика. Сотрудник корректирует поля, добавляет некоторые параметры, далее копирует строки файла в буфер, в Axapta выполняет вставку из буфера, находясь в нужной форме. Как понимаю, такая функциональность есть в том же Navision, так за что же Axapta обидели? Или, может, я что-то неправильно делаю и все же такая возможность есть? Просто за один сеанс может импортироваться порядка нескольких тысяч записей. А время импорта стандартными средствами Axapta из файла .xls просто удручающее.

[akvi]

Попробуйте сделать job, импортирующий из xls. Если будут проблемы с подключением непосредственно xls как источника данных, можно преобразовать его в dbf - проверенный способ. Вот похожий пример:

static void dbfTableImport(Args _args)
{

    OdbcConnection connection;
    LoginProperty    loginProperty = new LoginProperty();
    Statement         statement;
    ResultSet           resultSet;
    str                    statementTxt = "SELECT FIELD1, FIELD2, FIELD3 FROM DBFTABLE1";
    int                    i, c, v, w;

    InventTableModule   itm, itmu;
    InventTable         it;
    InventItemLocation  iil;


;

    loginProperty.setDSN("dbf");
    connection = new OdbcConnection(loginProperty);
    statement = connection.createStatement();
    resultSet = statement.executeQuery(statementTxt);

    ttsbegin;

    while (resultSet.next())
    {

     //делаем необходимый импорт
    //значения полей получаем из выражений resultSet.getString(1), resultSet.getInt(2) и т.д.
    }
    ttscommit;

}

если нужен еще более скоростной вариант, то копайте в сторону команды insert_recordset...

[Vadik]

Сохраняем в текстовый файл, далее группа определений, тип - Произвольный
Для желающих попрограммировать - Настройка таблиц, закладки Конвертация, Критерий

[Андре]

Хе... немного философских рассуждений. На мой взгляд буфер обмена - одна из тех вещей, в которые еще при постановке задачи была заложена ошибка.
Каково его основное предназначение - обеспечивать возможность передачи пользователем данных из одной программы в другую. При этом, вроде никаких ограничений на сами программы накладываться не должно.
Чтобы это обеспечить данную возможность - следовало бы разработать некий стандарт, на формат данных в буфере обмена, тогда, в каждом приложении было бы достаточно реализовать 2 функции - запись данных в буфер в стандартном формате и получение этих данных опять же в стандартном формате.
На практике же мы имеем ситуацию, когда никакого стандарта на формат данных в буфере обмена не существует и каждая программа пихает туда данные, как бог на душу положит и каждому разработчику приходится каждый раз заново добавлять в свою программу поддержку работы с той или иной программой посредством буфера обмена. Если у нас N программ, то для нормально взаимодействия их друг с другом разработчики пишут N*N функций

[mazzy]

Цитата:

Сообщение от Андре

На практике же мы имеем ситуацию, когда никакого стандарта на формат данных в буфере обмена не существует и каждая программа пихает туда данные, как бог на душу положит и каждому разработчику приходится каждый раз заново добавлять в свою программу

Ну... не так малешко...
Хорошим тоном считается, если программы пихают туда одни и те данные в нескольких форматах: как правило поддерживается простой текст, xml. Если есть оформление, то html, rtf...

если в буфере обмена не текстовая информация а двоичные данные, то действительно дело не очень хорошо. Но для двоичных данных и общий стандарт сложно выработать. Но даже в этом случае как правило поддерживается несколько форматов. Например, почти все программы для работы с векторной графикой кладут в буфер обмена помимо своего формата, еще и EPS с wmf...

Есть режимы, когда сами данные не копируются в буфер, а только объявляются в нем. Реальная подготовка и передача происходит в момент вставки.

В общем, "не согласен"

[Zan]

Цитата:

если нужен еще более скоростной вариант, то копайте в сторону команды insert_recordset...

правда ожидаемого эффекта (как-то повышение производительности) Вы можете не получить. В силу того, что Аксапта все равно преобразует Ваш insert_recordset в while select.

[mazzy]

Цитата:

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

В силу того, что Аксапта все равно преобразует Ваш insert_recordset в while select.

Если не запретить ей обрабатывать каждую запись в X++
См. What prevents fast SQL operations? в руководстве разработчика.
skipDeleteActions()
skipDatabaseLog()
skipDataMethods()

[mazzy]

Vadik дело говорит.

Цитата:

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

Кто-нибудь сталкивался с задачей импорта данных в Axapta из буфера? К примеру, нужно импортировать ряд новых номенклатур, которые поступают сотруднику в файле формата .xls от поставщика. Сотрудник корректирует поля, добавляет некоторые параметры, далее копирует строки файла в буфер, в Axapta выполняет вставку из буфера, находясь в нужной форме.

FAQ: http://axapta.mazzy.ru/lib/import/
и сразу ответ на ваш следующий вопрос: http://axapta.mazzy.ru/lib/inventimport/

если вы не любите программировать, есть альтернативный вариант
http://axapta.mazzy.ru/lib/easyimport/

[Zan]

Цитата:

Сообщение mazzy
Если не запретить ей обрабатывать каждую запись в X++
См. What prevents fast SQL operations? в руководстве разработчика.
skipDeleteActions()
skipDatabaseLog()
skipDataMethods()

Ну вот, раскрыл все секреты
Пусть человек сам бы поразбирался

[mazzy]

Цитата:

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

Ну, вот раскрыл все секреты

Извините.

[Zan]

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

[mazzy]

Цитата:

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

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

Тут таки либо массовая обработка (тогда нет обработки каждой записи)
Либо обработка на каждой записи стороне бизнес-логики (но тогда это не массовая по определению)

[Андре]

Цитата:

как правило поддерживается простой текст, xml

Ну, в общем то, я и имел в виду некую надстройку над XML.

Цитата:

Если есть оформление, то html, rtf...

Хм... а чем тут то XML не угодил

Цитата:

Но для двоичных данных и общий стандарт сложно выработать. Но даже в этом случае как правило поддерживается несколько форматов. Например, почти все программы для работы с векторной графикой кладут в буфер обмена помимо своего формата, еще и EPS с wmf...

Еще раз, подойдет любой самодокументированный формат. Сейчас это надстройки над XML, коих развелось огромное множество. В области графики - это SVG.

Цитата:

В общем, "не согласен"

Не согласен с чем? С тем, что механизм спроектирован коряво или с тем, что лучше сделать нельзя ?

p.s. Кстати, наверное, это лучше в курилку выделить

[mazzy]

Цитата:

Сообщение от Андре

Сейчас это надстройки над XML, коих развелось огромное множество.

Это они сейчас подойдут.
А когда появился буфер их еще не было.
Стандарты так быстро не меняются.

Цитата:

Сообщение от Андре

Не согласен с чем? С тем, что механизм спроектирован коряво или с тем, что лучше сделать нельзя ?

Не согласен с тем, что механизм спроектирован коряво.
Готов согласится с тем, что стандарты - вещь очень инертная. На то они и стандарты, чтобы меняться редко.

Насчет переноса - может просто закончим оффтопик?
Если интересно продолжать - открывай новую.