День добрый ! подскажите , в чем может быть причина медленной вставки данныйх через компоненту ТIBScript ? 10000 записей вставляет 7 секунд, а через IBExpert - около секунды тем же скриптом ?
почему же так ? Спасибо ....

простите, ошибся 1000 записей за 7 секунд ...... медленно , однако ....

> а через IBExpert - около секунды тем же скриптом

Так IBExpert наверняка выполняет все эти вставки в контексте одной и той же транзакции и не коммитит ее при каждой вставке ..

гм, так и я не коммичу ...
стартую транзакцию , запускаю скритп с 1000 записей типа


после того делаю  Transaction.Commit;

Тогда есть предположение, что запрос на стороне твоего клиента препарируется тобой (возможно неявно) всякий раз заново перед каждой экзекуцией ..

тоесть , у TIBScript такое дивное свойство , препарить каждую строку ? но ведь выполняет он его целиком , вернее выполняет сервер, а TIBScript только передает ...неужто он его построчно передает ?
код банален




параметры trnsWrite
 read_committed
 rec_version
 nowait

т.е. в Memo у тебя среди прочего необходимого 1000 одинаковых последовательно расположенных строк, содержаших одно и то же INSERT-предложения, так ?

ну типа вот такого


и так  1000 раз ....

А в чем "прелесть" ?
Чем не угодил циклический вызов параметрического запроса (IBQuery или IBDataset) на вставку ?

> Чем не угодил циклический вызов параметрического запроса
> (IBQuery или IBDataset) на вставку ?
тем, что перебором , на каждую запись вызывается запрос....
просто пробовал и запросом на клиенте вставлять , и вызывать процедуру из базы с передачей ей параметров .... все медленно , скриптом быстрее всего, но тоже не очень

> ну типа вот такого
> ...
а там не пройдет типа как в mssql, и не будет ли быстрее  



?

не ручаюсь за синтаксис но сам смысл.

> а там не пройдет типа как в mssql, и не будет ли быстрее
>  
> insert into pfb_payf_temp

было, делал, НО ! нарвался на интересную деталь : количество UNION не более 255 раз :-) идея хороша, почти сработало, но .... 255 и не более

255 всего или в одном обьединении?
а то
select * from (
 select ... union all
 ... 253 ...
 select ... union all
)
union all
... 253 ...
select * from (
 select ... union all
 ... 253 ...
 select ... union all
)

255*255 = 65025, ну и дальше "расширить" можно аналогично, пока на ограничение по вложенности не нарвешься.

да , так думал сделать .....цикл в 254 шага, потом поворение ..... , наверно, единственный выход , но будет ли он быстрее

> тем, что перебором , на каждую запись вызывается запрос


Так он же, этот запрос, препарируется  ОДИН раз, при первом  Execute ..
А при последующих он уже препарирован и время на препарацию не тратится ..

гм .. не понял , как это только при первом .... я так понимаю, предлагается следующие :
есть набор данных, на основании к-го генерируется запрос вставки, пусть это строки в МЕМО
,значит, читаем мемо построчно и на каждую строку выполняем либо INSERT в DataSet с параметром или вызов ХП тоже с передачей параметров, так ?
что-то типа :
  while memLog.Lines.num <=memLog.Lines.Count
   do begin
       qryIns.paramByName('par1','par2','par3','par4').value=memLog.Lines.value //ну примерно
      qryIns.Execute;
   end
тоесть , запрос препарится при первом шаге, а при последующих, он как бы уже препаренный ??? странно это ...

> странно это ..

Что странно-то ?

Справку открой по теме "ExecSQL method (TIBQuery)" и убедись сам ..

ладно, спорить не буду , попробую перебор .....
но интересно всеже, почему IBExpert выполняет скрипт за 1,5 секунды, а на клиенте  через IBScrept - 7секунд ... вот в чем вопрос ...

> но интересно всеже, почему IBExpert выполняет скрипт за
> 1,5 секунды, а на клиенте  через IBScrept - 7секунд ...
> вот в чем вопрос ...


Думается, что проблема в IBScript, раз такая разница.
Скорее всего, обычный препарированный запрос INSERT с параметрами сравняет скорость.
(Честно говоря, не помню ситуации, когда скорость INSERT у меня опускалась ниже 5000 записей в секунду)

sniknik ©   (19.02.10 10:30) [12]
> 255 всего или в одном обьединении?
....
> 255*255 = 65025, ну и дальше "расширить" можно аналогично, пока на ограничение по вложенности не нарвешься.

Предложенный Вами способ не подходит, и упирается все далеко не в TIBScript.

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

Изменить это значение можно в разделе констант исходников и пересобрав Firebird самостоятельно.

-----------------------
По теме топика: у автора ошибка в 17 строке. Иные варианты объяснения не подходят. у Хвастунова в IBExpert-e  далеко не "космические технологии" и "прямая связь с богом", те же самые допиленные [IBX]->[FIBPlus ранних версий] -> [компоненты доступа IBExpert]. И, как мы видим, все работает на ура.

Другой момент: раз уж автор взялся пользовать поделку IBX, хоть бы почитал про объекты TIBOutputDelimitedFile/TIBInputDelimitedFile, их связку с TIBSQL и про то как все кошерно и красиво делается этими объектами. Я имею в виду выгрузку/загрузку пакета большого записей из базы в базу.

В общем, читать "IBSql.pas" до полного просветвления.

> PEAKTOP ©   (22.02.10 03:23) [19]


> те же самые допиленные [IBX]->[FIBPlus ранних версий] ->
> [компоненты доступа IBExpert]

откедова дровишки? всегда дума что там фибы.. без допиливаний..

> откедова дровишки? всегда дума что там фибы.. без допиливаний.

Хвастунов постоянный читатель форумов в Firebird Foundation и на SQL.RU. Очень редко что-то постит, в основном ответы на пинки по поводу егойного IBExpert.

Да, там FIBPlus ранних версий. Допиленная. Поэтому в сборки не включаются свежие версии FIBPlus.