Да хоть сорок значений. На стороне сервера это найдется гораздо быстрей, чем крутить это же на клиенте. Просто потому, что сервер под это заточен. Ну, в принципе, я вас не уговариваю, но правильный путь тут - как раз спросить, как это сделать на стороне сервера, а не запрягать лощадей в автомобиль просто потому, что вы не знаете, с какой стороны лючок бензобака.
Я вам запрос, по сути, написал в первом сообщении. Если вам надо найти все значения, где дат больше одной. Если нужно четко, где дат будет три, то:
select min(m_date), count(*) from tbl_table group by m_date having count(*) = 3
Нет, коллега. Не делается это на php и не должно. Давайте порассуждаем. Вам надо вытащить ровно три значения. Если сделать это на стороне сервера:
- недостаток: процессор сервера мы дополнительно загрузим. С учетом того, что сервера под такую нагрузку и расчитаны, это не недостаток вообще.
- достоинства:
Первое и основное - вы не будете тянуть на клиента дополнительные данные. Все, вот это уже перекрывает все остальное. Но плюс мы еще и не заставляем более слабые клиенты этим заниматься.
Просто логически: вам надо купить три буханки хлеба. Вы ж не будет хватать и набивать хлебом всю корзину, чтобы на кассе сказать: "а теперь отберите мне отсюда три штуки!"
чудес, Золушка, не бывает. Речь пока идет не о базе данных, а о сервере. Сервер-то виден? И уж потом надо смотреть на базу. Возможно, просто не стартовал автоматически сервис MS SQL? Зайди в сервисы и проверь, запущен ли он.
Именно процедуру поиска? Теоретически, если там только то, что вы рассказываете, делается - т.е. сравнение на два поля и все, то можно это условие убрать. Но надо быть уверенным, что эта процедура используется только для поиска.
Функцию конвертации тоже можно попробовать восстановить. Тем же профайлером посмотреть, одни и те же символы каждый раз одинаково конвертируются или нет.
Буду рад, если вы мои ответы таки будете помечать, как таковые.
Федор: Конечно, расскажу. Профайлер - это мощнейшая штука, отслеживающая все обращения к вашему серверу и все, что на нем происходит. Меню tools - и прямо первая же строка сверху. Далее рекомендую поставить фильтр на, допустим, свою учетку (logins) и под ней выполнить то, что хотите посмотреть.
Точно нет в самой таблице, в этих двух полях значений по умолчанию? Обычно именно так делают.
Seintero: не пустыми, а NULL :) NULL - это ничего, не число, не строка - ничто вообще. Сравнить NULL мы ни с чем не можем, нужно преобразование. либо nz - почитай про него, либо как я написал в ответе - тупо прибавь к значению пустую строку. Тогда Null станет строкой и можно с ним сравнивать строку.
то ли вам, то ли не вам, май френд, я совсем недавно говорил...
Делать так - ИЗВРАТ! Так делать не надо, это неправильно, порочно, гнусно и отвратительно.
Вставка в цикле работает всегда медленней вставки за один прием. Я даже не знаю, откуда такой подход вообще может взяться... Вы раньше писали на чем-то типа fox pro первых версий?
Напишите ОДИН запрос. Подставьте в него значения всех переменных и выполните один раз. Тем более, у вас все элементы на форме уже есть.
Нет. Setfocus - это получение фокуса любым образом. Таб нажимай - при переходе им на твой элемент setfocus будет, а мышь вообще в кладовке может лежать.
в вашем случае, с оценками в американском стиле можно и комбобоксы. Дело-то не в элементах, а в странных идеях, вам не надо обновлять все записи студента, работу с кучей записей над в транзакцию оборачивать.
Вы продумайте сначала требования. Потому что сейчас похоже на то, что вы просто экспериментируете, что и как будет. Рабочую систему так не создать.
Например:
Что я хочу с оценками студента? Я хочу сохранять ее, когда она введена или обновлять. Надо ли мне проверять, что у него уже есть оценка? Надо ли мне ограничивать права доступа тем, кто может поставить/поменять оценку?
Сохраняю ли я дату-время вставки и, отдельно, дату обновления, а равно логин того, кто это сделал?
Проверяю ли я, что студент вообще учится на этом направлении, ограничиваю ли выбор студентов?
Это вот так, первые же возникающие вопросы. Полезны они? :)
Теперь, дети, давайте подумаем, нужен ли нам вообще подзапрос. И мы тут же поймем, что он не нужен, что лазить во вторую таблицу вообще не надо, все данные можно достать только этим самым подзапросом и оперировать только с ними.
Надо мне отобрать определенные записи из таблицы. Я могу херачать выборку из таблицы всей. Это глупо, да?
Хотя сейчас именно так и сделано.
Что еще я могу? Создать индекс на дату. Это будет быстрый, хороший индекс. Тогда решение задачи сведется к:
0. Отобрать минимальный id за текущую дату. Скажем, это 14597889
1. Сказать серверу: отбери мне все данные, у которых rid больше, чем 14597889
Будет это быстрей? Будет. Все, на этом вашу задачу с подзапросом вообще можно считать решенной.
Дорогой мой человек. Вот я вам в самом первом ответе смотрите, что написал:
"И совершенно непонятно, зачем брать абсолютно все данные и их потом переворачивать. Добавьте, например, условие сюда же по дате, или брать не все данные, а половину только и скорость увеличится".
Никакого иного чуда не случится. Ускорить выборку подстановкой правильного условия - это и есть ваше решение. Моё, вернее. Не надо пытаться объяснять, как вы написали запрос. Это и так очевидно.
Опишите, какой результат вы хотите получить и почему не можете тупо подставить условием id
минимальный за сегодняшний день, например.
Почему и кто вам запрещает добавить автоинкрементное поле, например.
Подзапрос выбрал информацию по группам. Зачем вам лезть в еще одну таблицу, зачем создавать временную, зачем все эти чудеса, если у вас уже есть информация по группам?
DrunkMaster: Нет, это вы не поняли. Берутся 20 последних, а не максимальных.
Давайте просто попробуем, что я предложил. Найдите в таблице vkmembers среднее значение.
Допустим, сто записей, тогда это значение будет 50. Если тысяча - это будет 500 и так далее.
SELECT `group_id` FROM `vkmembers` where group_id > 50 ORDER BY `members` DESC LIMIT 0,20
Попробуйте этот запрос, если он чудесным образом станет работать значительно быстрей - приходите, поговорим дальше. :)
и id_group можно еще раз в vkgroups не искать. Они есть уже, если требуется их уникальность, то можно с этими данными работать, а не лезть в другую таблицу. В общем, странное решение задачи.
Евгений: ну. Один в один то, что я вам давал, только вы это таки упростили. Причем в процессе отломили еще обработку ошибок непонятно зачем. Сервер недоступен будет - что ваш код скажет?
А теперь еще раз послушайте меня: это работающий, но НЕправильный вариант. Когда часть обновления идет на стороне акцесса, а часть на стороне сервера - вы пользуетесь костылем. Кривым.
Просто подумать - "а вот когда я делаю сначала вставку данных, а потом еще дополнительно шлифую ее апдейтом - уж не делаю ли я криво? Может, мне надо сразу же инсерт делать правильно?" Все надо делать на стороне сервера. Сделайте сторку и передавайте в нее параметры.
