Форум: "Базы";
Текущий архив: 2007.07.15;
Скачать: [xml.tar.bz2];
ВнизСортировка ADODataSet Найти похожие ветки
← →
Ega23 © (2007-03-13 16:35) [0]Есть ADODataSet с открытым набором данных.
Как его сортировать по разным столбцам на клиенте, не переоткрывая? IndexDefs добавлять?
← →
Jan (2007-03-13 16:38) [1]ADOQuery1.Sort := "LastName ASC, DateDue DESC"
Note: If the cursor is client-side (the dataset component’s CursorLocation property or that of an associated TADOConnection component is clUseClient) and no index already exists matching the requested field sort order, a temporary index is created. Resetting the sort order by setting Sort to an empty string automatically deletes the temporary index.
← →
sniknik © (2007-03-13 16:38) [2]проще метод sort использовать.
← →
Ega23 © (2007-03-13 16:38) [3]
> Jan (13.03.07 16:38) [1]
Оно. Спасибо.
← →
Ega23 © (2007-03-13 16:39) [4]
> проще метод sort использовать.
Да, про этот не знал. Бум знать.
← →
Ega23 © (2007-03-13 17:39) [5]Ух ты!
Какое хорошее свойство!
← →
MsGuns © (2007-03-13 21:06) [6]>Ega23 © (13.03.07 17:39) [5]
>Какое хорошее свойство!
Там еще кое-что вкусное есть. Например, ReQuery
← →
Ega23 © (2007-03-14 08:57) [7]
> Например, ReQuery
Этот я знаю. Я некую свою обёртку использую.
← →
Jan (2007-03-14 09:03) [8]
> MsGuns © (13.03.07 21:06) [6]
ага и еще Properties где развернуться можно :)
← →
DimonS © (2007-03-15 09:06) [9]А еще вот такая конструкция есть, ее постоянно и использую:
procedure TFrSpr.DBGridEh4TitleBtnClick(Sender: TObject; ACol: Integer;
Column: TColumnEh);
begin
TAdoDataset(DbgridEh1.DataSource.dataset).Sort := Column.FieldName;
end;
← →
logslava (2007-03-27 11:16) [10]Позвольте оживить сабж....
Проблема в том, что Sort не сортирует по lookup-полям датасета..
Можно ли как-то сортировать по таким полям не выполняя ПЕРЕ-запроса типа
...SQL.Text := "select .... order by MyField desc"
...SQL.Text := "select .... order by MyField asc"
← →
Ega23 © (2007-03-27 11:19) [11]
> Проблема в том, что Sort не сортирует по lookup-полям датасета.
И не должен.
← →
logslava (2007-03-27 11:25) [12]может быть, я в Борланде не работаю...
И все-таки, как это делается?
Ну не логично как-то перекачивать все данные снова от сервера на мой клиент только лишь для изменения порядка отображения... Ведь сами данные-то не изменились и это заведомо известно.
← →
stone © (2007-03-27 11:31) [13]
> logslava (27.03.07 11:25) [12]
Как вариант - отказаться от лукап-полей
← →
logslava (2007-03-27 11:36) [14]stone, вы серьезно?
← →
Плохиш © (2007-03-27 11:38) [15]
> logslava (27.03.07 11:25) [12]
Если данные не меняэтся, то выкинуть все лукап-поля и включить их в запрос.
← →
stone © (2007-03-27 11:39) [16]
> logslava (27.03.07 11:36) [14]
> stone, вы серьезно?
Вполне, для отображения в гриде лукап-поля не нужны, а пользоваться ими для ввода данных никто не мешает. Если же данные вводятся непосредственно в гриде, можно написать обработчик, который при попытке сортировать по лукап-полю, будет сортировать по какому надо.
← →
logslava (2007-03-27 11:53) [17]2 Плохиш
Данные не меняются - это я в том смысле, что в случае, когда пользователь смотрит на список (наример как в моем случае) покупок и хочет отсортироваеть его сначала по дате, потом по наименованию, потом еще по чему нибудь он не меняет данных в базе, зачем же в таком случает вновь выполнять запрос и вновь закачивать их в датасет?
Речь не идет о каких-то постоянных, никем не изменяемых данных
2 stone
> для отображения в гриде лукап-поля не нужны
Не нужны т.к. можно как-то иначе эти данные выудить, не через создание lookup в датасете? (я пока другого способа не знаю)
Или же вы имеете ввиду, что лучше вообще избежать их показа пользователю? В моей задаче отображая список покупок нужно отображать и поставщика. Все данные о поставщиках - в справочнике, а связь со справочником таблиц через VendorID
← →
stone © (2007-03-27 11:57) [18]
> logslava (27.03.07 11:53) [17]
Что мешает отображать в гриде результат запроса с уже готовыми полями, отображающими список покупок и поставщика. Сортировать можно будет как угодно.
← →
MsGuns © (2007-03-27 12:16) [19]> не сортирует по lookup-полям датасета.
Что за бред ?
← →
Плохиш © (2007-03-27 12:29) [20]
> Не нужны т.к. можно как-то иначе эти данные выудить, не
> через создание lookup в датасете? (я пока другого способа
> не знаю)
Пора пойитать про связи таблиц в запросах.
← →
Jan (2007-03-27 12:32) [21]лукап - это пережиток. давно уже все делают через join +
самописные контролы или EhLib.
← →
Jan (2007-03-27 12:34) [22]только вот сортировать не рекомендую по left join, лучше сделать два запроса(в одном данные получают через join, а во втором not exists фильтр) и обьеденить их union all.
← →
MsGuns © (2007-03-28 09:06) [23]>Jan (27.03.07 12:34) [22]
глупости
← →
Jan (2007-03-28 10:16) [24]
> MsGuns © (28.03.07 09:06) [23]
Отсортируй в MS SQL по полю которое берется из таблицы, которая присоедена left join. Только так чтобы у тебя в главной было тыс так 200 и в присоедененной тыс 300 и посмотри через сколько минут у тебя база tempdb загнется.
← →
sniknik © (2007-03-28 10:39) [25]> через сколько минут у тебя база tempdb загнется.
tempdb про эту сортировку даже не "догадается", т.к. sort это клиентский метод. и неважно по чему обьеденен начальный запрос, все одно действие над результирующем рекордсетом.
т.что предложенная проба из [24] бессмыслена.
← →
Jan (2007-03-28 10:48) [26]а что будет если я выбрал первые 100 записей? смысл их сортировать на клиенте?
← →
sniknik © (2007-03-28 11:10) [27]а прочитать собственно вопрос обсуждения в [0]? прежде чем давать советы, даже не зная применительно к чему.
← →
Jan (2007-03-28 11:13) [28]это понятно, но вообще-то тема ушла в сторону. на лукап поля и т.п.
← →
Kostafey © (2007-04-17 03:35) [29]У меня появилась аналогичная проблема. Нужно сделать сортировку по LookUp-полям.
И сразу несколько вопросов по ветке:
> procedure TFrSpr.DBGridEh4TitleBtnClick(Sender: TObject;
> ACol: Integer;
> Column: TColumnEh);
И когда такое событие происходит ?
> > не сортирует по lookup-полям датасета.
>
> Что за бред ?
ADODataSet1.Sort:=ADODataSet1LookTipMeropr.FieldName;
Где ADODataSet1LookTipMeropr - lookup- поле не работает.
> лукап - это пережиток. давно уже все делают через join +
>
> самописные контролы или EhLib.
А это что такое. Я имел в виду самописные контролы?
Если попытаться из всей ветки сделать вывод, то можно ли судить о том, что сортировка
по LookUp - полям невозможна (в том числе и в EhGrid), а уж тем более задание фильтра
вывода записей на основе LookUp - полей ?
В этом случае (для целей сортировки и фильтрации) лучше иметь независимый набор данных который
будет исключительно средствами SQL работать с базой данных с последующим выводом например в EhGrid, а
для ввода и модификации данных отдельно использовать уже стабильно работающие наборы данных с LookUp-полями.
Кроме того, для модификации данных в любом случае потребуется набор данных, содержащий все записи таблицы.
Основной недостаток - необходимость для каждой сетки (EhGrid) настраивать DiplayLabel и проч. в зависимости
от выводимого списка полей. В случае с заданными заранее пролями это удобнее.
← →
Jan1 (2007-04-17 10:18) [30]Те Лукап-поля которые реализованы в Делфе - большая пакость. Это источник тормозов и неправильного подхода к проектированию клиентских приложений. Лукап можно спокойно, а главное оптимально реализовать самому. Например, есть две таблицы одна главная другая справочная. Запрос:
select m.id, m.name, m.detail_id, d.name as detail_name
from Master m
left join Detail d on d.id = m.detail_id
Выведет ту же информацию, что и с лукап-поля из Делфи, но(!) быстрее на порядок, с возможность сортировки и фильтрации. Осталось только контролы прикрутить.
← →
Megabyte © (2007-04-17 11:14) [31]1)А каким образом ты сделаешь, чтобы в гриде, кот. выдает данные с джойном, можно было редактировать данные, чтобы не вводить всякие там ключи, а выбирать значения из выпадающего списка справочных таблиц(как в лукап-комбобокс-полях)?
Все равно придется отдельные НД делать для справочников...
2) В чем выражается "тормознутость и неправильный подход к проектированию клиентских приложений" пакостных лукап-полей?
Я не придираюсь, просто интересно!
← →
Jan1 (2007-04-17 11:40) [32]1. Можно подменить контрол, который в зависимости от кол-ва записей в справочнике, будет или кнопку показывать, по нажатию на которую форма с выбором значений - это когда записей больше скажем > 20, или комбобоксик рисовать, если записей <= 20. Да но создавать нужный набор нужно будет только тогда, когда пользователь захочет, а не всегда - как это с лукап-полем.
2. А в том как это все релизовано и как это все работает. Особенно это заметно на больших обьемах.
← →
Kostafey © (2007-04-17 12:23) [33]Что-то я не понял, а к чему приведет редактирование (Edit/Insert) набора данных,
построенного на нескольких таблицах ? Например как:
> select m.id, m.name, m.detail_id, d.name as detail_name
> from Master m
> left join Detail d on d.id = m.detail_id
Это же, например, insert произойдет и в Master и в Detail ?
← →
Jan1 (2007-04-17 12:26) [34]
> Это же, например, insert произойдет и в Master и в Detail
> ?
читал?
http://delphikingdom.ru/asp/viewitem.asp?catalogid=413
И тут все будет полезно:
http://delphikingdom.ru/asp/itemq.asp?mode=1&itemid=128
← →
Jan1 (2007-04-17 12:28) [35]> Это же, например, insert произойдет и в Master и в Detail
> ?
обшибся.
http://delphikingdom.ru/asp/viewitem.asp?catalogid=420
← →
Kostafey © (2007-04-17 12:34) [36]> [34] Jan1 (17.04.07 12:26)
Спасибо, читаю.
← →
Megabyte © (2007-04-17 13:45) [37]
> Jan1 (17.04.07 11:40) [32]
1)А в том как это все релизовано и как это все работает.
2)Особенно это заметно на больших обьемах.
1) Ну хз, я не замечал, хотя скажу, что и не так много делал, чтоб заметить.
2)Ну теоретически разве что на больших объемах справочных таблиц. Но справочников больших объемов пока что не видел ни в одном проекте(в том числе и в чужом).
← →
Jan1 (2007-04-17 13:55) [38]
> 1) Ну хз, я не замечал, хотя скажу, что и не так много делал,
> чтоб заметить.
там локейты, а это сам должен понимать какая-скорость.
> 2)Ну теоретически разве что на больших объемах справочных
> таблиц. Но справочников больших объемов пока что не видел
> ни в одном проекте(в том числе и в чужом).
та какая разница сколько там записей(хотя тоже важно :))? Зачем мне держать 10 справочников открытыми, по которым все время идет локейт, только для того, чтобы вывести их значения? Я могу и запросом это получить. Да есть справочники простые, а есть взаимные ссылки, допустим контакт-контрагент. и в каждой таблице по 1 мл. записей.
← →
Kostafey © (2007-04-17 14:18) [39]А вот еще такая ситуация.
Я заранее не знаю какие именно поля будут отображены в пользовательком датасете.
(пользователь имеет возможность редактировать список отображаемых полей).
Необходимо настроить свойства DisplayLabel и DisplayWidth полей.
Редактировать в Гриде нельзя т.к. неизвестно сколько будет полей и какие.
Так вот корректно было бы получать в Наборе данных все поля,
создавать для каждого поля TField (в Наборе данных) и редактировать только
свойство Visible этих полей ?
← →
sniknik © (2007-04-17 14:21) [40]> Зачем мне держать 10 справочников открытыми, по которым все время идет локейт, только для того, чтобы вывести их значения?
ну например для того, чтобы не закачивать с сервера лишних данных, экономить трафик в условиях его ограниченности.
к примеру работаешь с таблицей на 100 тыс или более у которой одно/несколько поле длинное и часто повторяющееся (вынесены в справочник)... ну например 20 вариантов на все записи первой.
как думаешь, что выгоднее 1 раз скачать все 20 дополнительных записей, а в таблице оригинале только индекс-ссылка(число) на эти записи, или тянуть с сервера 100тыс записей * длинна записи из справочника при запросе объединении. ???
p.s. не надо легковушку в плуг запрягать вместо трактора и все будет в порядке. а уж если запрягаете, то воздерживайтесь от комментариев типа "Лукап-поля которые реализованы в Делфе - большая пакость.".
← →
Jan1 (2007-04-17 14:24) [41]
> Так вот корректно было бы получать в Наборе данных все поля,
Очень плохое заблуждение. Очень. Нужно создавать поля по требованию и делать перезапрос если юзвер добавил новые поля, если убрал, то делать перезапрос не надо.
← →
Jan1 (2007-04-17 14:27) [42]
> ну например для того, чтобы не закачивать с сервера лишних
> данных, экономить трафик в условиях его ограниченности.
сидит себе пользователь грид скролирует, редактировать и не думает, а мы ему затянули все справочники. Вопрос - а зачем? Не проще ли по требованию?
> к примеру работаешь с таблицей на 100 тыс или более у которой
> одно/несколько поле длинное и часто повторяющееся (вынесены
> в справочник)... ну например 20 вариантов на все записи
> первой.
> как думаешь, что выгоднее 1 раз скачать все 20 дополнительных
> записей, а в таблице оригинале только индекс-ссылка(число)
> на эти записи, или тянуть с сервера 100тыс записей * длинна
> записи из справочника при запросе объединении. ???
чего-то не допонял... можно подробнее?
← →
Jan1 (2007-04-17 14:34) [43]
> p.s. не надо легковушку в плуг запрягать вместо трактора
> и все будет в порядке. а уж если запрягаете, то воздерживайтесь
> от комментариев типа "Лукап-поля которые реализованы в Делфе
> - большая пакость.".
Скажите есть у Вас таблицы которые между собой завязаны и записей там по 100 тыс? Как пример, я приводил Контакт-Контрагент. Показываете ли Вы такую связку пользователю, если да то как? Через лукап или нет?
← →
Megabyte © (2007-04-17 14:37) [44]
> Jan1 (17.04.07 13:55) [38]
Я тебя понял.
Но и
> sniknik © (17.04.07 14:21) [40]
тоже. Вот с ним согласен.
← →
Jan1 (2007-04-17 14:54) [45]2 Megabyte © (17.04.07 14:37) [44]
Для начального уровня создания приложений вполне, но никак не с промышленными базами. Так для курсовиков и небольших фирм... Без обид.
← →
Kostafey © (2007-04-17 14:55) [46]> Очень плохое заблуждение. Очень. Нужно создавать поля по
> требованию и делать перезапрос если юзвер добавил новые
> поля, если убрал, то делать перезапрос не надо.
Понятно, что нехорошо, но СУБД локальная практически нет требований к производительности.
Кроме того делать перезапросы при изменении сиска полей само по себе добавляет ручной
работы, но так и не отвечает на вопрос как настраивать такие глупости как DiplayLabel.
Ведь если у нас в Наборе данных будет разное количество полей (в зависимости от запросов
пользователя), то создавать TField в Наборе данных будет уже невозможно.
Это что же предлагаете динамически настраивать DiplayLabel в DBEhGrid в зависимости от
получаемого списка полей? Неужели действительно проще нельзя ?
← →
Jan1 (2007-04-17 15:05) [47]
> Понятно, что нехорошо, но СУБД локальная практически нет
> требований к производительности.
Еще одно заблуждение :(
> Ведь если у нас в Наборе данных будет разное количество
> полей (в зависимости от запросов
> пользователя), то создавать TField в Наборе данных будет
> уже невозможно.
скакой это радости?
← →
Kostafey © (2007-04-17 15:12) [48]> скакой это радости?
А как? Мы насоздавали полей в наборе данных например все поля одной таблицы.
Настроили их свойства.
Открыли НД с полным набором полей, смотрим в DBGrid и радуемся.
Открыли НД с не полным набором полей получаем ошибку про те заранее введенные TFiled,
для которых в этом запросе не получены данные.
← →
Jan1 (2007-04-17 15:18) [49]
> А как? Мы насоздавали полей в наборе данных например все
> поля одной таблицы.
> Настроили их свойства.
> Открыли НД с полным набором полей, смотрим в DBGrid и радуемся.
>
кто тебе мешает это сделать в рантайме?
← →
Kostafey © (2007-04-17 15:22) [50]> кто тебе мешает это сделать в рантайме?
Лень.
Да и вообще, программка того не стоит. Наверное...
← →
Jan1 (2007-04-17 15:26) [51]
> Лень.
что ж трудно Вам прийдется...
← →
Kostafey © (2007-04-17 15:32) [52]> что ж трудно Вам прийдется...
<offtop>
Зря Вы так.
Автоматизация вообще появилась из-за человеческой лени.
Я надеялся, что есть болле простые решения. А от бывало делаешь что-то,
а потом оказывается то же самое можно было бы сделать в 2 раза проще, в
3 раза быстрее и результат был бы эффективнее, я так получается удаление
гланд через ухо и велосипедоизобретательство. Только и всего.
</offtop>
← →
Megabyte © (2007-04-17 15:43) [53]
> Jan1 (17.04.07 14:54) [45]
2 Megabyte © (17.04.07 14:37) [44]
Для начального уровня создания приложений вполне, но никак не с промышленными базами. Так для курсовиков и небольших фирм... Без обид.
Да никаких обид, только, имхо, это не от масштаба зависит, а от конкретной потребности пользователей и устройства БД.
← →
Jan1 (2007-04-17 15:46) [54]
> Я надеялся, что есть болле простые решения. А от бывало
> делаешь что-то,
> а потом оказывается то же самое можно было бы сделать в
> 2 раза проще, в
> 3 раза быстрее и результат был бы эффективнее, я так получается
> удаление
> гланд через ухо и велосипедоизобретательство. Только и всего.
>
есть, но они денег стоят. или самим писать или купить...
← →
sniknik © (2007-04-17 15:46) [55]> Скажите есть у Вас таблицы которые между собой завязаны и записей там по 100 тыс?
да, у меня и поболее есть (5-6 млн) и в них почти все поля берутся из справочников, поля "расшифровки признака", статус, адрес (город,область,регион), и т.д. по сравнению с размером основной все они мизер... (суть вся основная это просто различные комбинации ссылок на справочники)
> Показываете ли Вы такую связку пользователю, если да то как? Через лукап или нет?
по необходимости, и так и так бывает, внесение(/редактирование) полей обычно из лукапа, выбором (руками такие поля не даю забивать, вот те что принадлежат таблице пожалуйста (например адрес - "улица дом кв". они практически уникальны и в справочник не выносятся)).
и показываю по необходимости, как юзер условия задаст столько и показываю... даже миллион если хотят, и не так долго грузится как может показаться.
> сидит себе пользователь грид скролирует, редактировать и не думает, а мы ему затянули все справочники.
пользователь не "пуп земли", не все вокруг него вертится, есть еще репликации, межпрограммный обмен данных , загрузка устройств. где хочеш не хочеш а практически всю таблицу/базу надо закачивать/перемещать.
> Вопрос - а зачем? Не проще ли по требованию?
а если требование именно такое?
чем плохо пользователю сидеть и скролировать грид? если он сам столько данных "заказал", ведь это он решает а не мы. протащится от обьемов раз, другой, глядишь и поскромнее в следующий раз задаст... не за последние 10лет данные, а только за последнюю неделю. благо возможность есть, а вот ограничивать... а вдруг ему именно все эти миллионы и нужны?
← →
Jan1 (2007-04-17 15:47) [56]
> Да никаких обид, только, имхо, это не от масштаба зависит,
> а от конкретной потребности пользователей и устройства
> БД.
ну да или стакан на половину пустой или полон.
Или пользователю сказать - звыняйтэ, Ваш комп тормозит а поэтому ждите пока данные Вам прийдут и отсортируются. или Все-таки поискать глюки в программе и переделать...
← →
sniknik © (2007-04-17 15:52) [57]> Я надеялся, что есть болле простые решения.
убери вообще из грида предопределения столбцов, создадутся автоматом при открытии таблицы. а "дисплейлебел" можно заменить в событии afteropen таблицы... сделать массив соответствий "имя поля"="русское название" по нему и заменить (а то и вообще в таблице держать. и пусть юзеры сами переводят. а если посложнее структуру записи сделать то можно и основные настройки держать... и все при единообразном подходе)
← →
Jan1 (2007-04-17 15:53) [58]
> да, у меня и поболее есть (5-6 млн) и в них почти все поля
> берутся из справочников, поля "расшифровки признака", статус,
> адрес (город,область,регион), и т.д. по сравнению с размером
> основной все они мизер... (суть вся основная это просто
> различные комбинации ссылок на справочники)
ну и представим, сколько нужно сделать действий проге чтобы показать юзверю их значения? или один запрос к серверу, который это все вернет или 1 + запросы на справочники + локейты по ним. Страны, города - их я думаю не мало, а лишних операций Ваша программа сделай ой как много :(
А как вы сортировать собрались? или фильтровать? или пользователь в этом ограничен?
← →
Jan1 (2007-04-17 15:54) [59]
> по необходимости, и так и так бывает, внесение(/редактирование)
> полей обычно из лукапа, выбором (руками такие поля не даю
> забивать, вот те что принадлежат таблице пожалуйста (например
> адрес - "улица дом кв". они практически уникальны и в справочник
> не выносятся)).
опять же неудобство делфийского лукап-поля при больших(даже на 100 записах) это делать ой как не юзабительно :(
← →
Jan1 (2007-04-17 15:56) [60]
> а если требование именно такое?
но только на редактирование а не на просмотр! вот нужно данные для отчета выбрать - Вы что опять будете лукап-поля тулить?
← →
Kostafey © (2007-04-17 15:57) [61]> [35] Jan1 (17.04.07 12:28)
> http://delphikingdom.ru/asp/viewitem.asp?catalogid=420
Странно. Сделал все как в статье.
Настроил
ADODataSetMeropr.Properties["Unique Table"].Value := "Meropr";
ADODataSetMeropr.Properties["Resync Command"].Value :=...
А программа ведет себя как в случае (как сказано в статье) если бы не было
настроено свойство Resync Command.
Т.е. изменяю поле FK_id, а прочие поля не изменяюся.
← →
Jan1 (2007-04-17 15:58) [62]
> ADODataSetMeropr.Properties["Resync Command"].Value :=..
> .
что там?
← →
Jan1 (2007-04-17 15:58) [63]что профайлер говорит.
← →
Kostafey © (2007-04-17 16:00) [64]> массив соответствий "имя поля"="русское название" по нему и заменить
А как же быть если этого поля не окажется в наборе данных?
← →
Kostafey © (2007-04-17 16:01) [65]> что там?
ADODataSetMeropr.Properties["Resync Command"].Value :=
"select * from "+
"( "+
" ( "+
" Meropr "+
" left join TipMeropr on TipMeropr.TMer_id = Meropr.Mer_TMer_id "+
" ) "+
" left join Valute on Valute.V_id = Meropr.Mer_V_id "+
") "+
"left join Location on Location.L_id = Meropr.Mer_L_id "+
"where Meropr.Mer_id=? ";
← →
Jan1 (2007-04-17 16:02) [66]а чего профайлер говорит?
← →
Kostafey © (2007-04-17 16:04) [67]> а чего профайлер говорит?
Я не что-то не понял. Что такое профайлер?
← →
Jan1 (2007-04-17 16:05) [68]C:\Program Files\Microsoft SQL Server\80\Tools\Binn\profiler.exe
← →
Jan1 (2007-04-17 16:06) [69]
> where Meropr.Mer_id=
Mer_id- ПК Meropr?
← →
Kostafey © (2007-04-17 16:07) [70]> C:\Program Files\Microsoft SQL Server\80\Tools\Binn\profiler.exe
Эта штука у меня, конечно есть, но в данном случае я с Access работаю.
← →
Jan1 (2007-04-17 16:08) [71]у тебя в топике MS SQL написано
← →
Kostafey © (2007-04-17 16:08) [72]> [69] Jan1 (17.04.07 16:06)
>
> > where Meropr.Mer_id=
>
> Mer_id- ПК Meropr?
Mer_id - уникальный ключ таблицы Meropr.
← →
Kostafey © (2007-04-17 16:10) [73]> у тебя в топике MS SQL написано
А :).
Тпик-то не мой. Я его поднял потому что там про LookUp-поля было написано.
С них-то все и началось.
← →
sniknik © (2007-04-17 16:12) [74]> А как же быть если этого поля не окажется в наборе данных?
пропускаешь и ничего не делаешь...
> но в данном случае я с Access работаю.
для него можно русские поля из дескрипторов брать, их у него через схемы несложно вытащить. в дескрипторы их естественно ктонибудь должен внести.
← →
Kostafey © (2007-04-17 16:21) [75]> пропускаешь и ничего не делаешь...
Тоже верно. :) Спасибо, это получилось.
← →
Kostafey © (2007-04-17 16:33) [76]> [61] Kostafey © (17.04.07 15:57)
> > [35] Jan1 (17.04.07 12:28)
>
>
> > http://delphikingdom.ru/asp/viewitem.asp?catalogid=420
>
> Странно. Сделал все как в статье...
Повторил для "пустого проекта" - то же самое.
Значения своств
ADODataSetMeropr.Properties["Unique Table"].Value := "Meropr";
ADODataSetMeropr.Properties["Resync Command"].Value :=...
задаются при Form1.Show
← →
sniknik © (2007-04-17 16:40) [77]> ADODataSetMeropr.Properties["Unique Table"].Value := "Meropr";
> ADODataSetMeropr.Properties["Resync Command"].Value :=...
это все? а где "Update Resync"? по умолчанию только автоинкремент обновляется.
либо твоя ресинк команда с ошибкой
← →
Kostafey © (2007-04-17 16:42) [78]> [76] Kostafey © (17.04.07 16:33)
О! Получилось. Написал:
procedure TForm1.ADODataSet1AfterPost(DataSet: TDataSet);
begin
ADODataSet1.Refresh;
end;
И стало все хорошо изменяться. Так правильно?
← →
Kostafey © (2007-04-17 16:47) [79]
> это все? а где "Update Resync"? по умолчанию только автоинкремент
> обновляется.
А как "Update Resync" использовать ?
← →
sniknik © (2007-04-17 16:48) [80]> Так правильно?
нет, должно само. и потом ты перезапрашиваешь весь рекордсет, а ресинк команда только одну запись.
← →
sniknik © (2007-04-17 16:49) [81]> А как "Update Resync" использовать ?
также как и другие, это свойство которое нужно установить "по вкусу", как тебе надо.
статью читал?
← →
Kostafey © (2007-04-17 16:57) [82]Гм.
ADODataSet1.Properties["Update Resync"].Value := adResyncAll;
Пишет: Undeclared identifier: "adResyncAll".
В справке adResyncAll вообще не находит.
← →
Kostafey © (2007-04-17 17:04) [83]
> Пишет: Undeclared identifier: "adResyncAll".
adoInt
Ура ! Все работает !
← →
Kostafey © (2007-04-17 17:44) [84]Подскажите, пожалуйста, существует ли способ отобразить
изменения значений связанных полей до выполнения Post набора данных?
Если вызвать ADODataSet1.Resync([])
от изменения вообще не будут внесены.
Страницы: 1 2 3 вся ветка
Форум: "Базы";
Текущий архив: 2007.07.15;
Скачать: [xml.tar.bz2];
Память: 0.69 MB
Время: 0.043 c