Приветствую, Уважаемые мастера.

После продолжительной работы с компонентами доступа ADO вернулся к связке IBX + FireBird 2.1
И столкнулся с такой проблемой (или не проблемой):
При динамическом изменении IBDataSet.SelectSQL при включенном ParamCheck сбрасываются все значения параметров.
т.е.
IBDataSet1.SelectSQL.Text := ' select * from MyTable where MyField = :pMyParam ';
IBDataSet1.ParamByName('pMyParam').value := 1;
IBDataSet1.SelectSQL.Text := IBDataSet1.SelectSQL.Text + ' order by 1 ';
// После этой строки значение pMyParam какое угодно кроме 1.

В ADODataSet таких проблем не было, и все значения оставались на месте.

Может, конечно, это просто особенность.
Данная конструкция была удобна при использовании библиотеки EhLib и ее стандартными сортировками.

> Maks Zyuzin ©   (23.08.09 22:56)  

Ну так ССЗБ.
То, что в адо такого небыло - это косяк в адо (!)

Где-то тут недавно sniknik приводил что-то подобное как пример того как не надо работать с SQL.Text.

> пример того как не надо работать с SQL.Text.
не путай человека, не с SQL.Text а с SQL.Add т.к. именно он вносит(/вносил в каких то версиях дельфи) запрос частями.
потом речь была исключительно об ADO, про IBX не знаю как он ведет себя при вносе запроса частями, есть у него действия по обработке запроса, и актуально ли это для него.
ну и даже если есть, то тут меняется целый запрос, с правильного на правильный. т.е. и в ADO это было бы нормально.

> это косяк в адо (!)
а то, что например дельфи в некоторых случаях сохраняет редактируемую программу на момент компиляции, и восстанавливает потом при сбое это глюк дельфи (!). и вообще все, что где то сумели предусмотреть полезные действия, это глюк!.
да?

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

> // После этой строки значение pMyParam какое угодно кроме 1.

А какое оно еще может быть, поскольку после смены запроса значение параметра не установлено.

> А какое оно еще может быть, поскольку после смены запроса значение параметра не установлено.
в ADO коллекция параметров не трогается при смене запроса без реальной необходимости, т.что изменение запроса не меняющее сам параметр оставит его в "живых".
ну, так как он на IBX переходит с ADO это сбивает с толку. хотя это дополнительный сервис, и везде его внедрять никто не обещал. (и в ADO такое поведение не из-за желания добавить удобств, как понимаю, а из-за общей логики получения параметров, они там инфу о типах запрашивают от движка, что делает их добавление слегка тяжеловесным, ну, напряжнее чем просто парсинг и создание объектов на клиенте, поэтому чтобы минимизировать "тяжёлые" действия, их и не делают без необходимости. ИМХО, на самом дело о причинах можно только догадываться...)

Спасибо за ответы.
Привык просто пользоваться связкой EhLib + ADO удобно и быстро настраивать сортировки по столбцам. А здесь видимо придется все обработки руками прописывать.

> Привык просто пользоваться связкой EhLib + ADO удобно и быстро настраивать сортировки по столбцам.
ADO и само умеет сортировать локальный рекордсет, без перезапросов. так как делал ты (показано в [0]) для ADO явная глупость... по привычке.

>sniknik ©   (24.08.09 09:53) [7]
То что было в 1 - был один из примеров и использовалось при фильтрации и первом запуске формы (когда из файла настройки загружалась информация о порядке, ширине, видимости и порядке сортировки столбцов)

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

> Вообще. просто у меня фильтры на основные таблицы вынесены в отдельные формы с галочками ...
да неважно где, как и почему ты делаешь, речь о другом, о цели ради которой ты это делаешь...  
т.е. если бы эти фильтры были ради запроса новых данных из базы по изменившимся критериям, это было бы нормально.
но ты то делаешь(/делал) пере-запрос, "напрягаешь" базу просто ради пересортировки по другому полю, что ADO ЭЛЕМЕНТАРНО делает и на клиенте. цель у тебя не та. вот это то и есть глупость (мало того что "напрягается" сервер, так еще и логика страдает, кликает например юзер на заголовок, отсортировать по нему имеющиеся 3-и записи, раз а там уже 10-ть... неправильно это, сортировка это сортировка отбор это отбор, и даже если в отборе имеется возможность сортировать отбираемое, все равно не стоит их смешивать).

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

>sniknik ©   (24.08.09 19:05) [9]
Я понял твой посыл. Дело в том что ты не совсем меня понял. все эти рассуждения велись к тому что IBDataSet не умеет локальную сортировку делать и по этому приходится делать ее на сервере. 99% таблиц в приложении отфильтрованы по каким то параметрам, по этому во всех запросах есть параметры, вот с ними и возникла проблема.
А фильтрациях вроде Maks Zyuzin ©   (24.08.09 10:10) [8] сортировка в конце добавлена как бонус, дабы лишний раз после выборки не пересортировывать датасет на клиенте. все сортировки делались только локально (в ADO).

>сейчас как понимаю уже выбора нет
Да нет. выбор то как раз есть. вот я и выбираю. Приложение только начинаю разрабатывать... и уже думаю не пойти ли мне к Firebird-у через ADO

Кстати условия задачи очень щадящие для сервера. в основную рабочую таблицу будет добавляться максимум 50-100 записей в день. и они же будут изменяться.

FIBPlus? там есть опция "Сохранять сортировку"... т.е. кеш ФИБов сортируется.. правда, не бесплатные(но и не дорогие, по карману практически любому :-) ).. но 100% поддерживают (и по кличу компании, будут поддерживать) все фишки ФБ..

> sniknik ©   (24.08.09 09:18) [5]


> в ADO коллекция параметров не трогается при смене запроса
> без реальной необходимости,

Сам факт изменения текста запроса - уже реальная необходимость.

>Виталий Панасенко(дом)   (24.08.09 22:05) [11]
С ними не работал, и они, как вы верно заметили, платные, а это проблема.

http://www.devrace.com/ru/fibplus/.. цены реально доступные...обновление лицензии - 50%