Фильтрация записей при импорте

[Александр Костоусов]

Доброго времени суток!

Необходимо импортировать данные из *.dbf.

Что сделали:
- создали шаблон Exel
- забили туда данные
- импорт пошел очень медленно!

Отсюда вопросы:
- как оптимальнее сделать импорт
- как реализовать импорт только определенных данных
(удовлетворяющих условию)

Буду благодарен любому совету!

[Prof]

Если есть навыки программирования - то проще и быстрее сделать все через job импортом из текстового файла, там вам и фильтрация и все что хочешь.

[Александр Костоусов]

Да это то что надо! Спасибо!

Как читать текстовый файл?
Есть ли примеры кода?

[Prof]

Суперпростенький код - импорт банковских счетов из файла

PHP код:

static void importBankAccounts(Args _args)
{
    FileName    fileName = 'c:\\work\\data\\accounts';
    ASCIIIO     io = new ASCIIIO(fileNAme, 'R');
    //CommaIO     io = new CommaIO(fileNAme, 'R');
    str         s;
    container   con;
    EmplTable   emplTAble;
    EmplBankAccount_RU  bankAccount;
    ;
    io.outFieldDelimiter(';');
    io.inFieldDelimiter(';');
    io.outRecordDelimiter(';');
    if (io)
    {
        ttsbegin;

        while (io.status() == IO_Status::Ok)
        {
            con = io.read();
            emplTAble = EmplTable::findByName(conpeek(con,1));
            if (emplTable)
            {
                select bankAccount where bankAccount.EmplAccount == emplTable.EmplId
                    && bankAccount.BankGroupId == 'МСЭБ';

                bankAccount.AccountNum = conpeek(con, 2);
                if (!bankAccount)
                {
                    bankAccount.AccountID = 'МСЭБ_' + emplTAble.EmplId;
                    bankAccount.EmplAccount = emplTable.EmplId;
                    bankAccount.BankGroupId = 'МСЭБ';
                    bankAccount.insert();
                }
                else
                {
                    bankAccount.update();
                }
            }
            else info(conpeek(con,1));
        }
        ttscommit;
    }



} 


[sukhanchik]

Господа! Зачем так извращаться??
Есть совершенно замечательный способ импорта данных через ODBC. Минус правда в том, что ODBC нужно создавать (это обязательное условие). Зато делаешь импорт откуда хочешь.
Я сам делал импорт из .dbf и скажу - что синтаксис SQL-запроса к DBF-нику - практически такой же как в Access (условно - берем Access, импортим туда DBF, создаем запрос, смотрим SQL и переносим в аксапту).
Отлаживать данный SQL запрос можно в SQL Server (причем именно запрос к данному драйверу ODBC).
job не обязателен. Я делал класс, наследуемый от RunBase... и все. Тем более что импорт скорее всего будет периодической операцией а не разовой

[Александр Костоусов]

Благодарю! Сейчас буду разбираться!

[sukhanchik]

Итак, создаем ODBC с именем "My ODBC". В ODBC указываем драйвер и путь к каталогу dbf-ников (у меня есть for_ax.dbf и в нем поле XXX). Я считаю кол-во уникальных записей в поле XXX

PHP код:

    int             total;  
    Str 600         sSQL;       // Строка SQL
    LoginProperty   lp;         // Объект, который передает в строку подключения информацию о логине
    OdbcConnection  connection; // Сам объект connection
    Statement       statement;  // Объект, который позволяет выполнить SQL- команду
    ResultSet       resultSet;  // Объект, в котором содержатся полученные строки (курсор, recordset)
    lp = new LoginProperty();
    lp.setDSN("My ODBC");
    connection = new OdbcConnection(lp);
    statement  = connection.createStatement();
    try
    {
        sSQL = "SELECT COUNT(*) FROM (SELECT DISTINCT XXX FROM FOR_AX)";
        resultSet = statement.executeQuery(sSQL);
        resultSet.next();
        total = str2int(resultSet.getString(1));
     }
     catch
     {
     } 


[Александр Костоусов]

Благодарю! Способ отличный!

И такой вопрос -- как приконнектиться в QueryAnalizer к dbf-нику?

Действительно удобно отлаживать запрос там!

[sukhanchik]

Цитата:

И такой вопрос -- как приконнектиться в QueryAnalizer к dbf-нику?

Это не Query Analyzer. Полноценной отладки по большому счету нет ...
Однако есть следующая возможность:
Открываем Enterprise Manager - свой SQL Server - Data Transformation Services - Local Packages
Делаем New Package
Далее делаем Add Conection. Добаляем SQL Server (на самом деле он не нужен, однако последовательность действий важна)
Далее делаем Add Connection. Добавляем Other (ODBC DataSource). Указываем свой созданный DSN. Жмем ОК.
Выделяем 2 получившихся значка (сначала ODBC, затем SQL Server). Щелкаем правой кнопкой по SQL Server делаем Transform Data Task.
После чего нарисуется стрелка. Ее направление обязательно должно идти от ODBC. Щекаем по стрелке - заходим в Properties. Выбираем не Table а SQL Query.
В окошке пишем запрос. Нажимаем кнопку Preview. Если запрос написан правильно - мы увидим данные. Если неправильно - увидим ошибку. После отладки - запрос копируем один в один в аксапту и присваиваем переменной (у меня sSQL).
Единственный момент. В зависимости от запроса - строка может быть ОЧЕНЬ длинной. Поэтому рекомендую заложиться на длину строки (у меня 600 символов)

[sukhanchik]

Кстати еще рекомендую обратить внимание на тип OdbcDsn_RU и форму (пункт меню display) OdbcAdmin_RU.
Первый поможет создать на диалоге раскрывающийся список ODBC (это уже интерфейс для пользователя)
Вторая - поможет создать на диалоге кнопку вызова самих ODBC. Это очень актуально если база работает под AOS. Потому что только так можно достучаться обычному юзеру до ODBC на сервере не имея прав админа на сервере.

[Александр Костоусов]

С коннектом разобрался!

У меня общий вопрос -- а такая выборка с помощью естественного SQL запроса не противоречит логике Axapt-ы? (Ведь есть же специальные конструкции языка)

[YVAS]

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

[sukhanchik]

Цитата:

такая выборка с помощью естественного SQL запроса не противоречит логике Axapt-ы? (Ведь есть же специальные конструкции языка)

А никто и не собирается использовать естественный SQL при обращении к стандартным таблицам. Он менее удобен и его тяжелее отлаживать. А потом конструкции языка не предусматривают обращение к внешним БД. Поэтому тут все ок

[Александр Костоусов]

Спасибо огромное за советы!! Сейчас разбираюсь!

[sukhanchik]

Цитата:

Использовать для импорта текстовый файл - это вовсе не извращение

Стандартный прием не означает лучший. А потом не зря же сделали механизм ODBC.
И встроенный язык гораздо менее емкий чем естественный SQL. Например в моем примере придется перебирать лишние записи, если решать все это через текстовый файл. Мой вариант - существенно быстрее на больших объемах данных или если импорт производится через интернет-канал.
С моей точки зрения -лучше разбираться в 10 строчках кода с естественным SQL чем в 100 с встроенным в данной ситуации.

[Александр Костоусов]

Особо благодарю sukhanchik!!!!

[YVAS]

2sukhanchik:
Администрирование->Периодические операции->Экспорт/Импорт данных.
При создании группы определения можно задать критерий отбора по какому либо полю. Это несколько строчек кода. И все, почти никакого программирвания.
Кстати, очень спорно ваше утверждение о скорости импорта при больших объемах информации.Хотелось бы услышать доказательства.

[BOAL]

Доказательства??
Хм...

а случай закачки 6 заджойненых таблиц в качестве сводной?
В коде sukhanchik'а - это делается одним запростом и все...

текстовым файлом или стандартными группами тут нужно будет писать много больше - факт
Плюс ручной перегон табличек.

Просто разные потребности... если просто табличка - то можно хоть через ехель стандартом лить
Ну и текстовый файл, конечно, форева

[xonix]

2 sukhanchik

sSQL = "SELECT COUNT(*) FROM (SELECT DISTINCT XXX FROM FOR_AX)";


Такой селект просто супер!
Вариант
SELECT COUNT(DISTINCT XXX) FROM FOR_AX
конечно же, работать не будет!