Обновление первых записей

← →
skiph © (2005-08-31 07:51) [0]

Нужно выполнить запрос вида:
Update fkuude SET ПОЛЕ=НОВОЕ_ЗНАЧЕНИЕ FROM (SELECT TOP 100 * FROM fkuude WHERE некоторый запрос) AS t1 WHERE t1.ID_Rec=fkuude.ID_REC

Т.е. мне нужно изменить не все записи, соответствующие "некоторому запросу", а только первые сто. Но при выполнении этого запроса Delphi ругается на первый FROM (тот, что после SET). Похоже, что здесь он не реализован. Как по другому можно решить эту задачку? Можно, конечно, отдельно выполнить
SELECT TOP 100 *
FROM fkuude
WHERE некоторый запрос
а затем, для каждой строчки, производить Update, но это чрезвычайно долго!
Заранее благодарен

← →
sniknik © (2005-08-31 08:23) [1]

а TOP реализован для используемого тобой движка?
тогда можно попробовать

Update fkuude
SET ПОЛЕ=НОВОЕ_ЗНАЧЕНИЕ
WHERE ID_Rec IN (SELECT TOP 100 ID_Rec
FROM fkuude
WHERE некоторый запрос)

ID_Rec - так понимаю ключевое вернее уникальное (т.к. dBase/FoxPro, нет ключей). (?)
а WHERE t1.ID_Rec=fkuude.ID_REC смысла не имеет, сравнивается то само с собой табличное и из запроса той же таблици, в любом случае будет равно.

← →
Anatoly Podgoretsky © (2005-08-31 08:53) [2]

skiph © (31.08.05 07:51)
Зачем нужно изменять произвольные 100 записей, смысл как бы туманен.

← →
skiph © (2005-08-31 10:44) [3]

> sniknik: Извиняюсь, на BDE я все это делаю. Оп-па, а что BDE топ вообще не поддерживает?
>ID_Rec - так понимаю ключевое вернее уникальное
под ID_Rec, я вообще-то подразумевал набор полей, которые уникально идентифицируют запись.
>а WHERE t1.ID_Rec=fkuude.ID_REC смысла не имеет, сравнивается то само с собой табличное и из запроса той же таблици, в любом случае будет равно.

Почему? В t1 будут отбираться только те записи, которые отфильтровываются по притерию, следовательно для тех ID_Rec, которым не удалось попасть t1, равенство не будет возможным. А вообще я этот пример из SQL BOL сдернул, поэтому в том, что он в MS SQL работает уверен.

>Anatoly Podgoretsky
Просто пользователь обрабатывает заиси порциями по 100 штук. Как раз этот пример должен был отмечать уже просмотренные записи, чтобы они не попали в следующую порцию.

← →
Sergey13 © (2005-08-31 10:54) [4]

2[3] skiph © (31.08.05 10:44)
>Просто пользователь обрабатывает заиси порциями по 100 штук. Как раз этот пример должен был отмечать уже просмотренные записи, чтобы они не попали в следующую порцию.

А если двое сразу смотрят? Я не знаю твоих условий, но ты, ИМХО, не туда роешь.

← →
Val © (2005-08-31 10:56) [5]

Думаю, что лучше работать с набором ид-шников уже выбранной сотни, при апдейте.

← →
Виталий Панасенко (2005-08-31 10:59) [6]

procedure Top100(Tbl : TTable);
var
I : Integer;
begin
for I := 1 to 100 do
if not Tbl.Eof then
begin
Tbl.Edit;
Tbl["ПОЛЕ"] := НОВОЕ_ЗНАЧЕНИЕ;
Tbl.Next;
end;//-if
end;
И по другому (запросом) не сделаешь... LocalSQL не потянет

← →
sniknik © (2005-08-31 11:18) [7]

> Почему? В t1 будут отбираться только те записи, которые отфильтровываются по притерию, следовательно для тех ID_Rec,
> которым не удалось попасть t1, равенство не будет возможным.
по этому условию построится обьеденение, неявное. и обновятся(должны) те записи для которых равенство совпадает. те. возможно обновятся даже больше 100 записей (хотя по логике ты этого не предусматривал), при условии дубликатов по условию.
но я посчитал ID_Rec уникальным и этот вариант не рассматривал.

вообщето надо бы проверить. только неохота, да и смысла для BDE все одно нет, не поддерживается. и автоинкремента у тебя нет (хоть както top сэмулировать) и движок не позволяет порядковый номер в запросеиспользовать (как VFP, для аналогичного TOP эмулировать).

← →
skiph © (2005-09-01 04:27) [8]

>Sergey13 © (31.08.05 10:54) [4]
>А если двое сразу смотрят?

Как только пользователь подает запрос на эту сотню записей, она автоматически редактируется (то бишь как раз этот запрос должен выполняться), так что вероятность того, что 2 пользователя одновременно подадут 1 запрос практически нулевая.

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

В любом случае, всем спасибо!

← →
Sergey13 © (2005-09-01 09:26) [9]

2[8] skiph © (01.09.05 04:27)
>так что вероятность того, что 2 пользователя одновременно подадут 1 запрос практически нулевая.
Не понял я твоей уверенности.
2 узера запросили записи. Первый чуть раньше, и потому "пометил" "свою" сотню. Второй получит только вторую сотню, потому что первая уже помечена как просмотренная (но не им!!!), и соответственно пометит ее. Если продолжать дальше то 5 узеру может вообще вернуться пустой запрос.
А как и когда снимать метки "просмотренности"? Как различать метки Иванова и Петрова? Как... Короче геморой ты себе придумал, ИМХО.

Вместо этого, ИМХО, надо работать над тем, что бы давать узеру только то, что нужно, а не сотни считать.

← →
Anatoly Podgoretsky © (2005-09-01 10:01) [10]

Sergey13 © (31.08.05 10:54) [4]
Я не знаю твоих условий, но ты, ИМХО, не туда роешь.

Известно куда - в могилу

← →
Виталий Панасенко (2005-09-01 10:14) [11]

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

А зачем фильтр и тд.. FindKey/Locate не быстрее будет ? Или индексов нет (или табу на использование индексов - есть у меня такой знакомый... НИ В ОДНОЙ ИЗ ПРОГРАММ НЕ ИСПОЛЬЗУЮТСЯ ИНДЕКСЫ - у него, наверное, индексофобия..:-)... Правда они и не большие... )))

← →
skiph © (2005-09-02 05:38) [12]

> Sergey13 ©

Ладно, раз пошла такая пьянка, придется видимо углубляться в назначение всего этого. Сие есть база телефонов клиентов/потенциальных клиентов. Периодически их нужно обзванивать. Обзванивают несколько человек с домашних телефонов. Поскольку одному человеку за день несколько тысяч фирм обзвонить не реально (и в то же время нужно, чтобы дважды за день в одну фирму не звонили), то и вводится дробление базы по частям (не обязательно на сотни, это уже пользователь сам указывает, я только для примера назвал это число). Т.е. приходит утром Иванов (формированием будет заниматься только один человек, 2-й даже не нужен, отсюда и уверенность), формирует списки по количеству телефонистов и отдает им. Все. Даже если Иванову будет помогать Петров, то различать метки совсем не обязательно.

>Виталий Панасенко. Вообще база не моя, я тут человек временный, на время болезни человека, поэтому радикально менять прав таких не имею (мне так и сказали). А вот насчет Locate это я действительно забыл, попробую, поэкспериментирую. Спасибо.

← →
Sergey13 © (2005-09-02 09:30) [13]

2 [12] skiph © (02.09.05 05:38)
Я и говорю - не туда ты роешь. 8-)
В таблице клиентов есть первичный ключ? Если нет - добавь обязательно. Если есть, то давай телефонистам диапазон первичного ключа. Если таблица сильно модифицируемая (сомневаюсь), можно добавить отдельное поле типа "номер по порядку", которое периодически обновлять для исключения больших дыр и соответственно более равномерного распределения нагрузки для телефонистов.

← →
Виталий Панасенко (2005-09-02 09:52) [14]

> Sergey13 © (02.09.05 09:30) [13]
> 2 [12] skiph © (02.09.05 05:38)

← →
Виталий Панасенко (2005-09-02 09:56) [15]

сорри, не туды кликнул с просонья....

> Sergey13 © (02.09.05 09:30) [13]
> 2 [12] skiph © (02.09.05 05:38)

> то давай телефонистам диапазон первичного ключа.

человек дело говорит.. тогда и страдания твои отпадут (наверное..:-))
select * from table where keyfield between 1 and 100
select * from table where keyfield between 101 and 200
и тд... Это тривиально...
но идея очень (мне так кажется) хорошая..

← →
Anatoly Podgoretsky © (2005-09-02 10:00) [16]

Виталий Панасенко (02.09.05 09:56) [15]
select * from table where keyfield between 1 and 100
select * from table where keyfield between 101 and 200
и тд... Это тривиально...

Это тривиально, но в принципе неправильно, такое работает только на таблицах, в которых запрещено удаление

← →
Sergey13 © (2005-09-02 10:05) [17]

2 [16] Anatoly Podgoretsky © (02.09.05 10:00)
Работает это везде без исключения. Просто важно решить - устроит ли заказчика результат работы. 8-)

← →
Anatoly Podgoretsky © (2005-09-02 10:13) [18]

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

← →
Виталий Панасенко (2005-09-02 10:54) [19]

> Anatoly Podgoretsky © (02.09.05 10:13) [18]
> Привожу цитату "а только первые сто", указаный тобой запрос
> не удовлетворяет эту условию, кроме особых случаев.
> Решение есть, оно близкое, но оно другое.

Поменять движок...:-))) АДО(даже с этим форматом TOP 100 работает),ЖарПтица...:-)))

2 Anatoly Podgoretsky © (02.09.05 10:00) [16]
Это тривиально, но в принципе неправильно, такое работает только на таблицах, в которых запрещено удаление

можно после каждого удаления делать апдейт поля.
конечно будет меняться содержание списка, но оно и так будет меняться...

2skiph © а сколько записей в базе? есть зависимые таблици?

Sergey13 © (02.09.05 10:05) [17]
Исключено по причине принципов работы БД и SQL и казаном варианте запрос и указаном требовании именно 100 записей, а не записи между 1 и 100. Подумай внимательнее, не сгоряча.

← →
wertolet (2005-09-02 14:19) [22]

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

2 [21] Anatoly Podgoretsky © (02.09.05 13:29)
Ты напираешь на "именно 100 записей". В сабже так и сказано. Правильно. Но по смыслу (как я понял), автору надо кучу записей делить на примерно равные кучки.

[12] skiph © (02.09.05 05:38)
> то и вводится дробление базы по частям (не обязательно на сотни, это уже >пользователь сам указывает, я только для примера назвал это число).

И с этим предложенный мной вариант справится. Может и не идеально, но справится. А с оговоркой из [13] про доп.поле справится почти идеально.

В прочем, я и не настаиваю на единственности этого решения.

Sergey13 © (02.09.05 14:21) [23]
Не на примерно равные, а на равные и именно по 100, за исключением последней конечно. Пока он ничего другого не указывает и это не вся информация которая нужна для решения, возможно и решение не может быть. Просто взгляни на задачу шире.

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

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

2[26] skiph © (05.09.05 05:01)
Ну тогда я бы предложил решение "в лоб".
1.Формируешь нужный список
2.Определяешь количество записей в списке
3.Определяешь количество телефонистов
4.Делишь первое на второе и получаешь среднюю загрузку на человека
5.В цикле апдейтишь полученный набор вставляя дату и исполнителя
6.Печатаешь списки по исполнителям на дату.

Обновление первых записей Найти похожие ветки