Как грамотно сформировать строковый литерал MSSQL

[belugin]

Я хочу зафигачить xpo-шник в мемо поле при помощи ODBCConnection

SQLSystem.sqlLiteral не помогает: например переводы строк не искейпит

Пошарившись по форумам нашел только следующие прправила (нормально надо использховать конечно запрос с параметрами, но statement такого сервиса не предоставляет):

*одинарную кавычку заменять двумя одинарными кавычками
*перевод строки заменять '+CHAR(10)+CHAR(13)+'

Как узнать исчерпывающий список таких правил

[sukhanchik]

практическим способом я вышел также на эти правила. Хотя если пользоваться ODBCConnection - то тут все зависит от драйвера ODBC. У каждого ODBC-драйвера есть свои заморочки и они отличаются. К сожалению - про исчерпывающий список сказать не могу - но возник вопрос. xpo-шник будет КАК фигачиться в мемо-поле? я имею в виду через SQL-запрос? (Statement.executeUpdate()) или еще как?
Просто интересно так сказать из чистого любопытства

[belugin]

А как еще? Хотя я не уверен что всякий xpoшник туда влезет.

[sukhanchik]

ага, я так и думал. Просто есть одна маааленькая грабелька. В метод executeUpdate равно как и executeQuery передается SQL-запрос. Так вот - параметр который там стоит - обрезается на 1000 символов (ограничение типа str). Учитывая размеры xpo - не думаю - что он туда поместится (там еще будут инструкции типа INSERT/UPDATE). Мне в свое время для добавления записи в базу клиент-банка (налоговое платежное поручение) - пришлось разбить INSERT на INSERT+UPDATE - т.к. не влезло.
А тут фиг разобьешь XPO.
Глобально - я не придумал как красиво преодолеть такую грабельку. Если только предварительно сохранять в таблице Аксапты данные, а затем напрямую экспортить данные из этой таблицы. Но это не всегда удобно
Это же ограничение касается и ADO (все равно там COMVariant применяется)

[belugin]

в принципе можно попробовать что-то типа

executeUpdate("update table where id=1 set xpo=xpo+'xxxxxxx'")

и так размер/1000 раз

[belugin]

Цитата:

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

ага, я так и думал. Просто есть одна маааленькая грабелька. В метод executeUpdate равно как и executeQuery передается SQL-запрос. Так вот - параметр который там стоит - обрезается на 1000 символов (ограничение типа str)

а почему

strLen((strRep('x', 2000)))==2000

[sukhanchik]

Мдя... в общем признаю свою неправоту.. Хотя может это KR2 ? В общем на KR2 работает точно.

    LoginProperty    lp;           
    OdbcConnection   connection;
    Statement        statement;
    str              sSQL;
    str              bigstr;
    ;
    lp = new LoginProperty();
    lp.setDSN("test");
    connection      = new OdbcConnection(lp);
    statement       = connection.createStatement();
    bigstr          = strRep('x', 5000);
    sSQL = "INSERT INTO testTable (xx) VALUES ('" + bigStr + "')";
    statement.executeUpdate(sSQL);

Был неправ. Беру свои слова обратно

[Gustav]

Всей задачки не знаю, но, а если построчно хрошник порезать и строки загрузить в нормальный варчар(255)? Хотя, как показывает практика, там даже и 100-120, вроде, хватает. Или геморрно потом восстанавливать?

Помнится, развлекался тем, что выгружал вручную весь узел Classes (полтора миллиона строк) в таблицу Access (MDB). Довольно интересно было изучать и в таком виде, начиная со всяких смешных запросов типа "В скольки строчках встречается слово container?"

[belugin]

Цитата:

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

Всей задачки не знаю, но, а если построчно хрошник порезать и строки загрузить в нормальный варчар(255)? Хотя, как показывает практика, там даже и 100-120, вроде, хватает. Или геморрно потом восстанавливать?

Помнится, развлекался тем, что выгружал вручную весь узел Classes (полтора миллиона строк) в таблицу Access (MDB). Довольно интересно было изучать и в таком виде, начиная со всяких смешных запросов типа "В скольки строчках встречается слово container?"

Для скорее текстовые индексеры применяются. Вот у меня знакомый сделал для BAANа нечто подобное Pride.search: Поиск по скриптам

[Владимир Максимов]

Цитата:

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

Я хочу зафигачить xpo-шник в мемо поле при помощи ODBCConnection

Я так понимаю, задача сводится к тому, чтобы закачать файл в поле типа TEXT на MS SQL? Для этого можно использовать команду самого MS SQL сервера BULK INSERT.

Т.е. логика примерно такая

static void Job_Connection(Args _args)
{
    str         strQuery;
    FileName    fileName;
    Connection  connection;
    Statement   statement;
    ;

    fileName = "\\\\MyServer\\ShareDir\\MyFile.xpo";
    strQuery = "SET NOCOUNT ON"+
                " IF Object_ID('tempdb..#tmpFile') IS NOT NULL DROP TABLE #tmpFile"+
                " CREATE TABLE #tmpFile (Content TEXT)"+
                " BULK INSERT #tmpFile FROM '"+fileName+"' WITH (ROWTERMINATOR='`')"+
                "";

    connection = new Connection();
    statement = connection.createStatement();
    statement.executeQuery(strQuery);
}

Здесь единственная проблема в том, что все это добро будет выполнятся со стороны сервера. Т.е. путь доступа к файлу надо писать именно со стороны сервера. Проще всего, иметь специальную расшаренную папку куда и класть файлы для закачки.

В качестве разделителя строк указываешь символ, которого заведомо не может быть внутри твоего XPO. Тогда весь файл будет закачан в одно поле.

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

Если опцию ROWTERMINATOR не указывать, то запись XPO произойдет построчно. Каждая строка XPO - отдельная строка в таблице #tmpFile.

Как удобнее хранить - одним куском или построчно - решай сам.

Ограничение в 1000 символов есть на поле таблицы, но не на символьные строки. Тут ограничивающим фактором будет не то, сколько сможет поддерживать AXAPTA, а то, сколько сможет "проглотить" драйвер ODBC или ADO через которые будет устанавливаться соединение с сервером. Это надо доку по соответсвующему драйверу читать.

[belugin]

А просто так TEXT не конкатенируется... UPDATETEXT (Transact-SQL)

[belugin]

а потом такой же гемморой, чтобы его оттуда извлекать?

[Владимир Максимов]

Цитата:

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

а потом такой же гемморой, чтобы его оттуда извлекать?

Это кому вопрос? Проблемы с извлечением будут в любом случае. Каким бы способом файл ни запихивали в поля таблицы.

Кстати, еще вариант - это построчное чтение XPO как обычного текстового файла (объект asciiIO) и такая же построчная закачка его в строки таблицы с дополнительным признаком "Порядковый номер".

В этом случае все решается достаточно просто. Символов перевода строки не будет по определению (содержимое одного поля - это одна строка текстового файла).

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

Чтение вообще будет элементарным. Считываешь все строки в порядке возрастания "Порядкового номера" и складываешь их с добавление символа переноса строки.

[belugin]

Так и сделал в конечном итоге. Кстати sqlLiteral обрезает такЮ чтобы получившийся литерал бюыл длиной 130

[Gustav]

Господа, разрешите пару попутных OFF-вопросов по ходу дела:

1. Способ экспорта проекта в виде xpo-файла - это единственный способ выгрузки кода из системы или существует какая-то магическая техника, позволяющая получить класс в нормальном текстовом виде, т.е. без всяких диезов, а также служебных ограничителей типа SOURCE/ENDSOURCE ?

2. Можно ли задать свой собственный порядок расположения методов при экспорте вместо алфавитного порядка, задаваемого системой ?

Заранее спасибо.


P.S. (копипаст не предлагать)

[belugin]

я знаю только AOTGetSource и AOTGetProperties. Для выгрузки проектов из за ошибки трёшки делали через AsciiIO

[belugin]

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

[sukhanchik]

в отношении ускорения не знаю - но вот нашел свою же ветку - http://www.axforum.info/forums/showt...5137#post65137
в которой написаны грабли ODBC-драйвера для SQL Server. Кстати (специально не проверял) - может именно этот драйвер "обрезает" SQL-строку? (мой пример выше проверялся на Access)