Hello, Александр!
Александр Свириденков wrote:
INET/inet_error: read errno = 10054
Насколько я понял, обычно это связано с плохой работой каких-то
сетевых устройств.
Влад правильно сказал - "или программ".
Но к сожалению, из самого лога не понять какой клиент отваливается.
Нет ли планов
"Александр Свириденков" ...
В логах FB 2.1.3 много сообщений вида
(Server) Mon Sep 14 19:31:40 2009
INET/inet_error: read errno = 10054
Насколько я понял, обычно это связано с плохой работой каких-то
сетевых устройств.
Или сетевых программ
Но к сожалению, из самого лога не понять какой
СГ>
СГ>> хм, а почему? просто любопытно?
СГ>> Я наоборот стараюсь все через SP делать.
СГ>> Даже от логики в триггерах хочу отказаться.
СГ>
СГ> Такова специфика и конъюнктура. Объяснять долго.
СГ>
понятно в принципе причины я теоретически знаю многие. ;)
--
С уважением
Кочмин Александр
Firebir
СГ>
СГ>> но ведь есть SP.
СГ>> В них все это делается элементарно.
СГ>> У меня вообще больше трех таблиц не объединяется практически никогда.
СГ>> Все что сложнее - SP и там уже разворачиваешь как хошь.
СГ>
СГ> SP пользуем только в крайнем случае.
хм, а почему? просто любопытно?
Я наоборот стара
On Mon, 25 Dec 2006 18:39:09 +0300, Ded <[EMAIL PROTECTED]> wrote:
> Тебе же уже сказали, бестолковый - джойн это слишком сложно. А уж
> тем более лефт. Ты только представь всё многообразие запросов, которые
А если сюда ещё RIGHT JOIN добавить, то ещё в два раза больше вариантов.
--
Сергей
WildSery wrote:
On Mon, 25 Dec 2006 17:57:44 +0300, Самохвалов Григорий <[EMAIL PROTECTED]>
wrote:
Первый запрос игнорирует беспаспортных.
Решение то же, что и для второго - LEFT JOIN.
Тебе же уже сказали, бестолковый - джойн это слишком сложно. А уж
тем более лефт. Ты только предст
On Mon, 25 Dec 2006 17:57:44 +0300, Самохвалов Григорий <[EMAIL PROTECTED]>
wrote:
> Первый запрос игнорирует беспаспортных.
Решение то же, что и для второго - LEFT JOIN.
--
Сергей Смирнов.
СГ> Что можно сделать join-ом делается join-ом, спору нет.
СГ> Но есть много того, что join-ом сделать крайне проблематично.
но ведь есть SP.
В них все это делается элементарно.
У меня вообще больше трех таблиц не объединяется практически никогда.
Все что сложнее - SP и там уже разворачиваешь к
Самохвалов Григорий wrote:
Я то еще надеялся что имеются ввиду select from select, который появился в
FB2. Но с ним, по крайней мере у меня, ничего подобного тоже не получается.
Тут вроде приводили пример решения с помощью derived tables, но он не
совсем примитивен. Что-то типа:
select e.
Я то еще надеялся что имеются ввиду select from select, который появился в
FB2. Но с ним, по крайней мере у меня, ничего подобного тоже не
получается.
Ежели в записи об документах будет присутствовать интервал действия оных, то
твой select можно свести к элементарному join. У меня вот так
Что тебе мешает это сделать с помощью ХП или execute block?
--
Сергей Смирнов.
Может я чего не понял и пишу очевидные
вещи, но, по-моему, имелось в виду что-то
вроде:
select K_EMPLOY.* FROM K_EMPLOY, K_EMPLOY_DOCS.*
from K_EMPLOY
left join K_EMPLOY_DOCS on K_EMPLOY_DOCS.IDLINK = K_EMPLOY.ID
where K_EMPLOY_DOCS.TYP = 21
order by <здесь поля сортировки из K_EMPLOY>,
K_EMPLOY_
Речь идет о решении задачи в общем случае. Если мне скажут алгоритм, по
которому любой запрос указанного вида можно свести к join-у буду очень рад!
Кхм...
SELECT ...
JOIN (SELECT ...)
Самохвалов Григорий wrote:
Планируется ли в каких-либо последующих версиях Firebird-а сделать так чтобы
подзапросом можно было бы выбирать несколько полей.
Да.
select (select * from table where condition), field1, field2 from
other_table
А чем это принципиально лучше джойна?
--
Дмитрий
"Plotnikov Y." <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]
> Дя887 классик, вин 2003 сервер.
Я тут посмторел и вспоминл, что это уже правилось и на 889 такого быть не должно
--~--~-~--~~~---~--~~
-~--~~~~--~~--~--~--
> Знаешь скоко долго я в унынии пребывал?... Пока не снизошло...
>
> Вообще-то проэто писали в конфе пару раз
просмотрел, значит.. иначе бы думаю не забыл.
--~--~-~--~~~---~--~~
-~--~~~~--~~--~--~---
OL> Да, исправлтся будет тока в новой сборке.
Сорри за "опять нескромный вопрос".
А КОГДА ОНА БУДЕТ?
With best regards, Леонид. E-mail: [EMAIL PROTECTED]
--~--~-~--~~~---~--~~
-~--~~~~--~~--~--~---
"Plotnikov Y." <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]
>
>
> Знаешь скоко долго я в унынии пребывал?... Пока не снизошло...
Вообще-то проэто писали в конфе пару раз
"Oleg LOA" <[EMAIL PROTECTED]> сообщил/сообщила в новостях
следующее: news:[EMAIL PROTECTED]
> "Plotnikov Y." <[EMAIL PROTECTED]> wrote in
message news:[EMAIL PROTECTED]
> >
> > Вопрос - так и должно быть что они подкручиваются? (т.е. растут, причем
на
> > строго определенное значение).
>
> Да, и
"Plotnikov Y." <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]
>
> Вопрос - так и должно быть что они подкручиваются? (т.е. растут, причем на
> строго определенное значение).
Да, исправлтся будет тока в новой сборке.
> Еще странность - в одной таблице 16710 записей. "Ее" генератор ра
Добрый день всем!
Мы тут затеяли перенос базы данных на новый сервер, в связи с чем написали
скрипты для автоматического бакап/рестора (например по ночам). Для пущей
верности результата написали компарер.
Он сравнивает:
1) количество объектов в базе
2) количество записей для каждой таблицы
3) ра
21 matches
Mail list logo
