> А зачем ты обращаешься к несуществующему параметру?
я к нему не обращаюсь. это я пробовал [21], [24]

> Но как в таком случае мне отследить событие окончания приезда
> всех данных? Я положился на пример использования dbExpress,
>  где так и было open - for .. recordcount - next - close
> - и всё работает.




(с) Псой Короленко.

> сделал сразу же, результат в [8]
там нет результата, там уверения "все правильно".
вот если бы были приведены варианты ответов, с мышкой(ошибка) и без(ок), вот тогда "результаты".

> перечислять их все через запятую?
именно так рекомендуется в любом мануале любого (пока не встречал исключений)  sql сервера.

> вот тот самый метод полностью
жуть. как сценарист ужастиков не пробовался? :)

во первых параметры
во вторых for j := 0 to Qry.RecordCount-1 do ???
в третьих определение по имени поля внутри цикла
в четвертых нет дизейбла контролов (датасет/стринггрид)
в пятых ошибки вести в лог, и разделять в каком блоке произошли, абсолютно одинаковые не информативны.
в шестых Application.ProcessMessages; в цикле позволяет извне выполнить "левые" операции, например закрытие/перезапрос запроса, т.к. сам "кверик" - глобальная переменная (экономишь?), где проверка после него?
в седьмых сама "идея" перекладки в стрингрид бред.
ну и в восьмых код без применения "советов", нафига он нужен? убедить нас что все правильно?

гм, признаю, я лох
стоило заменить

на

И всё стало прекрасно. Никакой больше ошибки.

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

14 часов, 33 поста.
Может завязать отвечать на вопросы, раз ответы нафиг никому не нужны?
И конкуренции меньше на рынке будет...

> Ты его, похоже, с Мегавольтом путаешь.

Не путаю, смотри пост 28

> Anatoly Podgoretsky ©   (15.12.10 12:34) [35]
> > но, если
> > TDateTime(Trunc( datetimepicker.date))
> Ты зачем так делаешь, вроде бы достаточно грамотный программист.

от отчаяния, когда перепробовал сначала много способов, логически более очевидных.

Ну вот не найду никак ту тему, жалко..
короче, ну дык и пишу же
       case Q.Params[i].DataType of
         ftDateTime: Q.Params[i].AsDateTime := P[i];
         else Q.Params[i].Value := P[i];
вот все равно, просто trunc от startoftheday получался, что отличался

> megavoid  (15.12.2010 12:39:40)  [40]

Я не пристаю
(с) Тайна третей планеты.

> Не путаю, смотри пост 28

пардон, спутал.


> Ну вот не найду никак ту тему, жалко..
> короче, ну дык и пишу же

параметры вручную прописывал, или по Paramcheck получил?
просто с ручными у меня никогда никаких проблем не было, ни под MSSQL, ни под Postgres, ни под FB.
Да, это более муторное занятие. Писанины больше. Но зато никаких проблем.

> 12  (15.12.2010 12:58:46)  [46]

Загубишь ты так промышленность нашу.

@sniknik
там есть результат.
без(ок), с мышкой - получали мессаджбокс
Qry: Field 'dtime' not found
SELECT * FROM z WHERE ddate='2010-14-12';
[OK]

> именно так рекомендуется в любом мануале любого (пока не встречал исключений)  sql сервера.
И если на следующий день заказчик захочет добавить ещё одно поле в базу, придётся ходить и везде его приписывать? В других запросах, где мне требуются только отдельные поля, я указываю их. Если нужны все - ставлю *.
Сервер MySQL гордо и одиноко стоит на core i5, 4 Гб, и по всем логам не напрягает процессор больше чем на 1% в час пик. Расширения не планируется, так что его не жалко.

> жуть. как сценарист ужастиков не пробовался? :)
Обязательно попробую после этой трёхстраничной простыни ужасов :)

> во первых параметры
ну сделаю я Qry.Params.Add(ddate=date); - это будет мне очень неудобно - sql запрос req конструируется разный, в разных местах, с разными параметрами

> во вторых for j := 0 to Qry.RecordCount-1 do ???
это да, я лох, уже догадался сам :)

> в третьих определение по имени поля внутри цикла
это из области фильмов ужасов, ага, но - работает

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

> в пятых ошибки вести в лог, и разделять в каком блоке произошли, абсолютно одинаковые не информативны.
модуль лога пишется, скоро будет

> Application.ProcessMessages;
да, не подумал. Но извне, пока работает FillGrid, никаких сообщений не придёт - всё однопоточное. Разве что может быть вариант, когда юзер нажмёт обновить, и, не дождавшись, снова нажмёт обновить - тогда в qry получится полная каша. На практике такого не случалось ни разу.

> перекладки в стринггрид
В полном соответствии с требованиями заказчика. Для справки, в этом же проекте совсем рядом есть DBGridы, прекрасно работающие - но перекладывать в стринггрид мне всё равно пришлось - вот отсюда и этот страхокод :)

> ну и в восьмых код без применения "советов", нафига он нужен? убедить нас что все правильно?
всё применял, все они в коде, всем спасибо за ответы!

> megavoid  (15.12.2010 13:29:50)  [50]

Ну так нету же, правильно сообщает, там вообще никаких параметров нет.

> megavoid  (15.12.2010 13:29:50)  [50]

"И если на следующий день заказчик захочет добавить ещё одно поле в базу,
придётся ходить и везде его приписывать?"

Я уже говорил, что ленивым нечего делать в программирование. Тебе надо в
менеджеры и чтобы кресло пошире.

> И если на следующий день заказчик захочет добавить ещё одно
> поле в базу, придётся ходить и везде его приписывать? В
> других запросах, где мне требуются только отдельные поля,
>  я указываю их. Если нужны все - ставлю *.


Вот теперь я, как администратор БД, беру и меняю порядок полей в таблице. Или, например, добавлю в данную таблицу блоб-поле, в которой битмап для каждой записи будет лежать. Метра так на 2.
И теперь ты по своей * будешь тащить на каждый чих по 100 записей дополнительно 200 мегабайт картинок.
Это первое.
Второе: а тебе и так и так придётся переписывать. Добавлять fieldByName и заносить его в определённый столбец твоего StringGrid.


>  это будет мне очень неудобно - sql запрос req конструируется
> разный, в разных местах, с разными параметрами


скажи, а зачем такой изврат нужен? Ну, в смысле, один DataSet на всё приложение? Заведи себе их столько, сколько нужно. Аккуратно пропиши параметры. Выстави Prepared (скомпилируй заранее).
Получишь афигенный выигрыш на скорости, проверено неоднократно.


> > в третьих определение по имени поля внутри цикла
> это из области фильмов ужасов, ага, но - работает


Вот тут я со sniknik не согласен. FieldByName - в целом более правильное обращение. Fields[Index] - это только если ты строго уверен, что НД пришёл в строго определённом порядке полей. Что сильно повышает неустойчивость в случае, если работаешь с хранимой процедурой, а её код может кто-то модифицировать.


> нет. юзеры всё равно ничего не успеют сделать, пока получаем
> данные
> сильно подозреваю, что тоже из ужастиков


Зря подозреваешь. Смотри код TDataSet. Года 2.5 -3 назад аккурат на этом форуме я вопрос поднимал. Простейшая операция disable|enable controls дала прирост производительности то ли в 30 раз, то ли в 70.


>  Но извне, пока работает FillGrid, никаких сообщений не
> придёт - всё однопоточное.


Да ну? Ты, видать, плохо разбираешься, что такое Application.ProcessMessages.
простой пример.
У тебя, запрос, который выполняется 5 секунд (это только Open). За эти 5 секунд ты наделал кучу всякой разной фигни мышкой. Что будет - предлагаю тебе самому на чистом проекте испытать.

> Вот тут я со sniknik не согласен. FieldByName - в целом более правильное обращение. Fields[Index] - это только если ты строго уверен
не выдумывай отсебятины... Fields[Index] я сам нигде не использую и другим не советую.
> в третьих определение по имени поля внутри цикла
где тут Fields[Index]? здесь про "внутри цикла", вынести "за" и все дела, а не менять на что то самопридуманное.

> не выдумывай отсебятины... Fields[Index] я сам нигде не
> использую и другим не советую.


Тогда я тебя не понял. Поясни "в третьих определение по имени поля внутри цикла"

> Поясни "в третьих определение по имени поля внутри цикла"
> вынести "за" и все дела

> Вот теперь я, как администратор БД, беру и меняю порядок
> полей в таблице. Или, например, добавлю в данную таблицу
> блоб-поле, в которой битмап для каждой записи будет лежать.
>  Метра так на 2.

В данном конкретном случае администратор БД управляется мной же, и я просто не пропущу большой блоб. Когда это писалось, я закладывался на полный контроль всего комплекса со стороны меня, что и позволяет мне достаточно вольно писать мой говнокод, точно помня что, где и как расположено.


> скажи, а зачем такой изврат нужен? Ну, в смысле, один DataSet
> на всё приложение?

Экономия, всё верно выше подметили. Над завести много датасетов - подумаю.


> Простейшая операция disable|enable controls дала прирост
> производительности то ли в 30 раз, то ли в 70.

Прописал disable/enable. На глазок по скорости выполнения то же самое, но глазок не профайлер, вечером замерю без и с disablecontrols.


> Application.ProcessMessages

Там только ради WM_PAINT. Не 5, а 2-3 секунды :) WinSight у меня частенько открыт. Ну, даже если придёт LBUTTONDOWN или CLOSE - как это собьёт мне Query? Если пришлют DESTROY - ну тут и так понятно что хана, никакой квери уже нафиг не нужен будет.

ЗЫ. А кресло у меня большое-большое, ага :) А программирование мне больше по душе :)

> > вынести "за" и все дела
Куда "за"? Оно потому и внутри цикла, что я получаю данные из полей в цикле.

> Ega23  (15.12.2010 13:54:53)  [53]

Ты где такие маленькие битмапы нашел.