Главная страница
    Top.Mail.Ru    Яндекс.Метрика
Форум: "Базы";
Текущий архив: 2005.12.11;
Скачать: [xml.tar.bz2];

Вниз

DataSet.recNo   Найти похожие ветки 

 
йцукен   (2005-10-26 10:56) [0]

Результат запроса query отображен в DBGRID
Если идет работа с Парадоксом то сабж отображает номер активной записи.
А вот если задействован MSSQL  то сабж показывает -1, при этом конечно query открыт и DataSet.RecordCount показывает все верно.
Подскажите в чем может быть дело


 
Desdechado ©   (2005-10-26 11:15) [1]

RecNo для sql-серверов смысла не имеет, поэтому во многих датасетах просто не реализован
используй первичный ключ или суррогатное поле, имеющееся только в запросе


 
Johnmen ©   (2005-10-26 11:17) [2]

В том, что записи реально не получены клиентом.
Никогда и нигде не пользоваться RecNo и RecordCount !!!


 
msguns ©   (2005-10-26 11:18) [3]

>Johnmen ©   (26.10.05 11:17) [2]
>Никогда и нигде не пользоваться RecNo и RecordCount !!!

Опять за старое ?


 
Johnmen ©   (2005-10-26 11:25) [4]

>msguns ©   (26.10.05 11:18) [3]
>Опять за старое ?

Истины бывают вечными. И не старятся...:)


 
йцукен   (2005-10-26 11:31) [5]

Спасибо
Обошелся через Bookmark и selectrows


 
Desdechado ©   (2005-10-26 11:33) [6]

> Никогда и нигде не пользоваться RecNo и RecordCount !!!
Двумя руками за! Ибо поведение разных видов датасетов для этих свойств разное, нюансы иногда меняются между версиями. Поэтому при необходимости перехода от одного вида датасета к другому (привычки-то сохраняются!) возникают проблемы именно с этими свойствами.


 
msguns ©   (2005-10-26 11:59) [7]

>Johnmen ©   (26.10.05 11:25) [4]
>Истины бывают вечными. И не старятся...:)

Вечны только глупость человеческая. И упрямство ;)

>Desdechado ©   (26.10.05 11:33) [6]
>Двумя руками за!

Еще один !!!

>Ибо поведение разных видов датасетов для этих свойств разное, нюансы иногда меняются между версиями.

Ты имеешь в виду unidirectional ? Так не о них речь

>Поэтому при необходимости перехода от одного вида датасета к другому (привычки-то сохраняются!) возникают проблемы именно с этими свойствами.

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

Еще раз напомню вечную мудрость: иногда лучше покашлять, чем сказать.


 
Johnmen ©   (2005-10-26 12:06) [8]

>msguns ©   (26.10.05 11:59) [7]

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

А причём тут свойства RecNo и RecordCount???

>Еще раз напомню вечную мудрость: иногда лучше покашлять, чем сказать.

Вечны только глупость человеческая. И упрямство ;) (c) msguns ©   (26.10.05 11:59) [7]

:)))


 
msguns ©   (2005-10-26 12:40) [9]

>Johnmen ©   (26.10.05 12:06) [8]
>А причём тут свойства RecNo и RecordCount???

Затем, что использовав их, можно не "тревожить" сервере и не заморачиваться с текстами запросов.

Тебе просто охота поспорить, ага ?


 
Desdechado ©   (2005-10-26 12:45) [10]

2 msguns
еще один момент по нюансам:
в Си, например, реализация short int, int, long int очень сильно зависит от платформы (разрядность, например). И многие написанные ранее вещи в условиях нынешних компиляторов странно себя ведут при перекомпиляции. Хотя все в пределах стандарта. Это я к тому, что если есть возможность не использовать скользких свойств, то лучше их не использовать.


 
Digitman ©   (2005-10-26 12:51) [11]


> msguns ©   (26.10.05 11:59) [7]


к людЯм нужно помягше, а на вещи смотреть ширше)

Johnmen в [2] ведет речь (и правильно ведет !) о том, что рано или поздно может возникнуть необходимость адаптации алгоритма кл.приложения к иной СУБД, в которой эти самые RecNo и RecordCount , будучи работающими под старой СУБД и посему употребленными "в лоб", попросту летят коту под хвост, что потребует либо отказ от их использования либо основательную перетряску алгоритма... в то время как BOF/EOF, будучи употребленными к месту, обязаны и будут работать в клиентской среде любой СУБД.

Надеюсь, мысль ты ущучил ?


 
Sergey13 ©   (2005-10-26 12:55) [12]

Опять холиваром запахло. 8-)
Кину тогда я две копейки что ли.
Использовать можно все что работает. Но с умом. И помня, что нет ничего, что работает всегда и везде одинаково. Ну и в справку почаще глядеть.

ИМХО, все разумеется.


 
msguns ©   (2005-10-26 13:12) [13]

>Digitman ©   (26.10.05 12:51) [11]
>к людЯм нужно помягше, а на вещи смотреть ширше)

Так я ж вродя мягенько так, вежливенько ;)))

>Johnmen в [2] ведет речь (и правильно ведет !) о том, что рано или поздно может возникнуть необходимость адаптации алгоритма кл.приложения к иной СУБД, в которой эти самые RecNo и RecordCount , будучи работающими под старой СУБД и посему употребленными "в лоб", попросту летят коту под хвост, что потребует либо отказ от их использования либо основательную перетряску алгоритма... в то время как BOF/EOF, будучи употребленными к месту, обязаны и будут работать в клиентской среде любой СУБД.

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

Кстати, а есть полная уверенность, что в ближайшем будущем все новые компоненты лоступа будут поддерживать упомянутый BOF,EOF ?
И еще. Значицца, чтобы выяснить кол-во извлеченных записей, непременно надо "исползать" вдоль и поперек (от BOF до EOF) весь курсор ? Или я чего-то не "ущучил" ?


 
Desdechado ©   (2005-10-26 13:21) [14]

для узнавания количества записей вовсе не нужно тащить данные на клиента, достаточно select count(*)
а если надо совместить, то, имхо, корректнее (для больших выборок) будет в одной транзакции сначала select count, а потом select данные с одинаковыми условиями
хотя и несколько тяжеловесно


 
Desdechado ©   (2005-10-26 13:27) [15]

да, и про коровник с крокодиловой фермой сравнение некорректное
просто программные средства имеют тенденцию часто и разнообразно меняться, особенно расширяться
и в рамках использованных ранее технологий не получается (или заказчик не хочет) решить новые задачи, переход на что-то новое (НП, новый вид датасета) - это простое решение с многими граблями. И хочется их уменьшить.


 
Anatoly Podgoretsky ©   (2005-10-26 13:29) [16]


> Кстати, а есть полная уверенность, что в ближайшем будущем
> все новые компоненты лоступа будут поддерживать упомянутый
> BOF,EOF ?
> И еще. Значицца, чтобы выяснить кол-во извлеченных записей,
>  непременно надо "исползать" вдоль и поперек (от BOF до
> EOF) весь курсор ? Или я чего-то не "ущучил" ?


1. Обязательно будут, без этого работа не возможно.
2. Если хочешь гарантировано и при том для любых наборов данных , то будешь ползать. Наприм однонаправленные наборы, к тому же по коммуникационному порту.


 
msguns ©   (2005-10-26 13:34) [17]

>Anatoly Podgoretsky ©   (26.10.05 13:29) [16]
>1. Обязательно будут, без этого работа не возможно.

Ну-ну, Толя.. 15 лет назад я (да разве ж я один) считал виндуз неудачной попыткой "украшения" дос.

>2. Если хочешь гарантировано и при том для любых наборов данных , то будешь ползать. Наприм однонаправленные наборы, к тому же по коммуникационному порту.

Без "крокодилов" все же не обошлось ;(

Семеро на одного ? Ладно, сдаюсь, надоело из пустого в порожнее.
В [12] в принципе все сказано. Достаточно ичерпывающе.


 
Digitman ©   (2005-10-26 13:40) [18]


> msguns ©   (26.10.05 13:12) [13]



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


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

А то что завтра его скороспелая "куриная продукция" будет неактуальна (не рентабельна, не модна, куры сдохнут от гриппа и т.д - нужное подчеркнуть) его, "куриного бизнесмена", нимало не сношает  ..


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


потому что этот "табуреточных дел мастер" завтра придет в этот же Форум и начнет канючить, мол, почему сделанная мной по вашим дурацким советам табуретка в одночасье рухнула под слоновьих размеров задницей)


> есть полная уверенность, что в ближайшем будущем все новые
> компоненты лоступа будут поддерживать упомянутый BOF,EOF
> ?


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


> чтобы выяснить кол-во извлеченных записей, непременно надо
> "исползать" вдоль и поперек (от BOF до EOF) весь курсор ?


не язви)... ты прекрасно понимаешь, что для этого есть Last/First .. и если в одной СУБД вызов RecordCount "в лоб"  (т.е сразу после открытия НД) приведет к ожидаемым результатам, то в другой СУБД та же логика приведет к краху, ибо эта другая СУБД для отражения числа записей в НД требует, например, позиционирование на последней его записи.


 
Fay ©   (2005-10-26 15:00) [19]

2 msguns ©   (26.10.05 11:18) [3]

Этого мало?
>> А вот если задействован MSSQL  то сабж показывает -1


 
Карелин Артем ©   (2005-10-26 15:08) [20]

Интрересно, как бы уважаемые МАСТЕРА сделали бы потомка DBGrid, в котором надо было бы раскрасить к примеру все нечетные записи серым цветом.
На что бы они ориентировались, кроме как RecNo?


 
Johnmen ©   (2005-10-26 15:13) [21]

>Карелин Артем ©   (26.10.05 15:08) [20]

"уважаемые МАСТЕРА"
1. не занимаются наряжанием ёлок
2. но если бы их насильно заставили, то придумать пару тройку вариантов без рекно им бы не составило труда...
:)


 
Карелин Артем ©   (2005-10-26 15:14) [22]


> Johnmen ©   (26.10.05 15:13) [21]

Я так и думал :))


 
Desdechado ©   (2005-10-26 15:44) [23]

> В [12] в принципе все сказано. Достаточно ичерпывающе.
Да, вот только границы каждый себе устанавливает сам (или его начальник :). Так что [12] скорее обобщает все мнения, т.е. не привносит ничего нового.
Кстати, тут достаточно часто мелькает мнение, что "программы пишутся для людей". Так вот человек, вынужденный разбираться или, что еще хуже, дорабатывать чужой код, будет долго плеваться на всякие частности вроде RecNo, которые то работают, то не работают.
А для себя - пожалуйста, хоть на машинных кодах в одну строку.


 
Sergey13 ©   (2005-10-26 15:54) [24]

2[23] Desdechado ©   (26.10.05 15:44)
>т.е. не привносит ничего нового.
А я то думал.... Э-э-э-эх! 8-)

>на всякие частности вроде RecNo, которые то работают, то не работают.
Что значит "то работают, то не работают"? В одних условиях? В одной программе в этих одних условиях? Если пишешь сразу и под Парадокс и под МС сервер, то естественно надо понимать, что это несколько разные вещи. Если пишешь только под Парадокс, то почему это "то работают, то не работают"? Это будет работать.
Много ли програм, работающих все равно на какой БД? И портирование на другую БД это тоже отдельная пестня.

ИМХО все исключительно.


 
Johnmen ©   (2005-10-26 16:03) [25]

>Sergey13 ©   (26.10.05 15:54) [24]

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


 
Anatoly Podgoretsky ©   (2005-10-26 16:10) [26]

Карелин Артем ©   (26.10.05 15:08) [20]
Только не на RecNo, например для dBase это физический номер, как не меняй сортировку, и я молчу про filter.


 
Sergey13 ©   (2005-10-26 16:21) [27]

2[25] Johnmen ©   (26.10.05 16:03)
А вдруг ТДатаСет вообще отменят? Что делать то будем? 8-)


 
Digitman ©   (2005-10-26 16:27) [28]


> Sergey13 ©   (26.10.05 16:21) [27]


> вдруг ТДатаСет вообще отменят?


> Что делать


снимать штаны и бегать)

а вдруг двигатель внутреннего сгорания отменят ?)


 
Desdechado ©   (2005-10-26 16:28) [29]

возьмем старые исходники VCL и RTL - и буде он как феникс


 
Johnmen ©   (2005-10-26 16:37) [30]


> Sergey13 ©   (26.10.05 16:21) [27]
> А вдруг ТДатаСет вообще отменят? Что делать то будем? 8-
> )


Как в том фильме...
"- А если б он вёз патроны?
- А если б макароны?" (с)
:^)


 
msguns ©   (2005-10-26 16:58) [31]

Языки не болят еще ?


 
Sergey13 ©   (2005-10-26 17:01) [32]

2[31] msguns ©   (26.10.05 16:58)
Сам бучу заварил, а потом осуждает. 8-)


 
Digitman ©   (2005-10-26 17:45) [33]


> msguns ©   (26.10.05 16:58) [31]


Ты, Серега, мог бы и промолчать).. Вроде не без головы на ногах)
Тем более  что ты, думаю, надуваешь проблему як шарик воздушный)
Нельзя в дан.контексте использовать данный метод ? Нельзя. Не используй !
Можно в дан.контексте использовать данный метод ? Можо. Используй !


 
Digitman ©   (2005-10-26 17:44) [34]

Удалено модератором



Страницы: 1 вся ветка

Форум: "Базы";
Текущий архив: 2005.12.11;
Скачать: [xml.tar.bz2];

Наверх





Память: 0.55 MB
Время: 0.033 c
6-1125308417
Irinka
2005-08-29 13:40
2005.12.11
Пересылка и получение файлов с помощью сокетов


5-1116228247
Николай
2005-05-16 11:24
2005.12.11
Создание компонента


14-1132285349
Тома
2005-11-18 06:42
2005.12.11
InterBase


14-1132583518
ArtemESC
2005-11-21 17:31
2005.12.11
Как програмно выключить или перезагрузить компьютер?


14-1132314851
Udaff
2005-11-18 14:54
2005.12.11
розыскиваю книги автора





Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French
Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latvian Lithuanian Macedonian Malay Maltese Norwegian
Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Bengali Bosnian
Cebuano Esperanto Gujarati Hausa Hmong Igbo Javanese Kannada Khmer Lao Latin Maori Marathi Mongolian Nepali Punjabi Somali Tamil Telugu Yoruba
Zulu
Английский Французский Немецкий Итальянский Португальский Русский Испанский