Re: BIN_NOT
Oleg Deribas wrote: Да, кстати, если нет никакой возможности явно указать тип константы CAST чем не устраивает? -- Дмитрий Еманов
Re: BIN_NOT
Dmitry Yemanov wrote: Да, кстати, если нет никакой возможности явно указать тип константы CAST чем не устраивает? Ну да, точно, sorry. -- Oleg
Stack Trace
Здравствуйте! Во-первых, хотелось бы сказать спасибо Владу за вывод сообщений об ошибках, содержащий где и что случилось - так называемый Stack Trace. Он очень помогает в отлове багов и вообще разработке. Но вот такой ламерский вопрос: Можно ли его как то сделать выключаемым или чтобы не для всех показывался, или хотя бы намертво разрешеался/запрещался где нить в конфиге? Объясняю почему: У нас часто используется отслеживание различных блокировок на уровне сервера, т.е. при изменении например каких то данных, если операция недопустима - выдается исключение в триггере типа Действие запрещено, идите на Т.е. Их в принципе не надо отлавливать, так как они нужные, но пользователю выдается сообщение вида: Идите на в тринггере в процедуре... И короче за этим становится очень трудно уловить смысл сообщения. Вот такое пожелание/вопрос. С уважением, Стариков Алексей
Re: Stack Trace
St. Alex wrote: Идите на в тринггере в процедуре... И короче за этим становится очень трудно уловить смысл сообщения. Вот такое пожелание/вопрос. Распарси самостоятельно статус-вектор и убери лишнее. -- Дмитрий Еманов
Re: к вопросу о производительности FB
Может покажусь нудным, но на самом деле, знания о том, что выдавил из сервера все что мог,а дальше нужно нарашивать железо и определяют специалиста, достойного оплаты от Да, это точно. Где б таких спецов найти... Поскольку тема подходящая, спрошу заодно. Может кто поможет. Вообщем чувствую я, что из своего сервера под линуксом я далеко не все выдавил. Вкратце : Материнка Asus, проц - P4 3 Гц, памяти 2 гига, 4 SATA. Вообщем немного усиленная рабочая станция. Порядка 30 рабочих станций. На сервер взгромаздил все. DNS, DHCP, Samba в качестве контроллера домена и FB (знаю, что плохо). Из дисков сделал 2 зеркала. На одном зеркале стоит система и Samb-овские шары. На втором - FB. По ночам делается backup файлов с одного зеркала на другое и наоборот соответственно. Вообщем старался добиться максимальной надежности. Сейчас замечаю, что под виндой вообщем-то поживее как-то было. Хотя на тоже на одном сервере все установлено было. Единственное что не было софтового зеркала... Установил утилитку, которая показывает загрузку системы. Вообщем узкого места не обнаружил. Своп практически не используется. Процессор загружен процентов на 10. Скопировал большой файл с сервера на рабочую станцию. В этот момент нагрузка на диски и сетевую карту увеличилась. А так, в обыкновенном режиме, видно, что нагрузка на диск и сетевую не достигает тех значений, которые были при копировании большого файла... Вообщем может кто подскажет как определить узкое место. Ну и что улучшить можно при описанном раскладе. Пока пришло в голову (чего-то сразу не сообразил, пока систему ставил), что надо бы сделать raid-диск c чередованием и на нем разместить все временные файлы. Насколько эффективно будет перекомпилировать ядро? Стоит ли скомпилить FB? Может в настройках дисков покопаться? (как не знаю кстати). Может еще какие настройки системы есть, на которые стоит обратить внимание... With b/r. Gleb.
Re: Stack Trace
ну если только так, то придется изголятся. У меня правда никаких статус векторов нет, придется мессаж парсить. Только еще и в куче мест видимо. Ну ладно, нет так нет. Спасибо С уважением, Стариков Алексей
Re: Stack Trace
St. Alex wrote: У меня правда никаких статус векторов нет Через что с базой работаешь? Неужто все от тебя спрятали? придется мессаж парсить Структура/текст сообщения могут измениться в будущем. -- Дмитрий Еманов
Re: к вопросу о производительности FB
Мадорский Г.В. wrote: Насколько эффективно будет перекомпилировать ядро? Лучше не надо. Стоит ли скомпилить FB? Это, кстати, интересный вопрос. Можно попробовать собрать со всеми оптимизациями и под конкретный процессор. Может в настройках дисков покопаться? (как не знаю кстати). man hdparm -- Oleg
Re: к вопросу о производительности FB
Вкратце : Материнка Asus, проц - P4 3 Гц, Сдай в утиль, купи QUAD. Типа 6600 (2.4G) - он щас вообще копейки стоит. И памяти ~4GB, если не DDR3 - тоже смешные деньги. И не парь себе моск. У меня однопоточные тяжеловестные вещи в полтора раза быстрее стали трудится. И это под Vista Ultimate x64 Не говоря про реальную возможность разведения зоопарка на такой машине :-) Был XP+ASUS+прескотт 2.8+3.2GB+RAID0 из двух SATA ... правда HDD тоже поменял. Я вообще все поменял :-) Коваленко Дмитрий.
Re: к вопросу о производительности FB
Мадорский Г.В. [EMAIL PROTECTED] сообщил/сообщила в новостях следующее: news:[EMAIL PROTECTED] Вообщем чувствую я, что из своего сервера под линуксом я далеко не все выдавил. У нас тоже такая проблема ... была :-) Единственное что не было софтового зеркала... Вот здесь основная проблема. Нужно делать аппаратный рэйд. По два диска в зеркало и на них страйп. (все время путаю кто 10 и 01). Настройки рэйда: Размер страницы БД = Размер буфера диска. Размер блока страйпа = 2*Размер буфера диска. -- Галимов Артур Амирзянович. ФармМедСервис (Сочи).
Re: Stack Trace
Через что с базой работаешь? Неужто все от тебя спрятали? Структура/текст сообщения могут измениться в будущем. Дим, ты знаешь много людей, которым реально нужен доступ к статус-вектору? Коваленко Дмитрий
Re: Stack Trace
Kovalenko Dmitry wrote: Дим, ты знаешь много людей, которым реально нужен доступ к статус-вектору? Нет. Но можно было бы и предоставить такую возможность :-) -- Дмитрий Еманов
Re: Stack Trace
Дим, ты знаешь много людей, которым реально нужен доступ к статус-вектору? Нет. Но можно было бы и предоставить такую возможность :-) За отдельные бабки - да ради бога. Ты же сам знаешь. А так - есть более увлекательные извращения. Массивы, например. Бугага. Коваленко Дмитрий.
Re: Stack Trace
Через что с базой работаешь? Неужто все от тебя спрятали? Как обычно :-) Через dbExpress пока что :-) С уважением, Стариков Алексей
Re: Stack Trace
Через что с базой работаешь? Неужто все от тебя спрятали? Как обычно :-) Через dbExpress пока что :-) Да уж, респект. По сравнению с этим, массивы - это детский лепет 8-) Коваленко Дмитрий.
Re: Stack Trace
Да уж, респект. По сравнению с этим, массивы - это детский лепет 8-) Массивами честно говоря вообще не разу не пользовался в FB. И даже чето не тянет :-) Стариков Алексей
Re: BIN_NOT
äÁ Ñ ÎÅ ÒÕÇÁÀÓØ. ñ ÜÔÉÍÉ ÆÕÎËÃÉÑÍÉ ÎÅ ÐÏÌØÚÕÀÓØ, ÍÎÅ ÐÒÏÓÔÏ ÌÏÇÉËÁ ÓÔÒÁÎÎÏÊ ÐÏËÁÚÁÌÁÓØ. ïÂÙÞÎÁÑ ÂÉÎÁÒÎÁÑ ÌÏÇÉËÁ - ÌÉÂÏ ÓÄÅÌÁÌÉ, ÌÉÂÏ ÎÅ ÓÄÅÌÁÌÉ :-) ó Õ×ÁÖÅÎÉÅÍ, óÔÁÒÉËÏ× áÌÅËÓÅÊ
Implementation limit exceeded
Здравствуйте!
Объясните пожалуйста почему запрос
select cast('a' as varchar(25000)),
cast('b' as varchar(25000)),
cast('c' as varchar(25000))
from rdb$database
приводит к ошибке
Dynamic SQL Error.
SQL error code = -204.
Implementation limit exceeded.
block size exceeds implementation restriction.
Почему он так интерпретирует varchar ? Ведь сам запрос меньше 64 К.
Тестировал с версией 2.1
С уважением, Вадим
Re: Implementation limit exceeded
Bewahrer wrote:
Объясните пожалуйста почему запрос
select cast('a' as varchar(25000)),
cast('b' as varchar(25000)),
cast('c' as varchar(25000))
from rdb$database
приводит к ошибке
Dynamic SQL Error.
SQL error code = -204.
Implementation limit exceeded.
block size exceeds implementation restriction.
Патамучта длина записи резалт-сета ограничена 64К.
--
Дмитрий Еманов
Re: BIN_NOT
St. Alex wrote: Да я не ругаюсь. Я этими функциями не пользуюсь, мне просто логика странной показалась. Обычная бинарная логика - либо сделали, либо не сделали :-) Логика троична. ХЗ забыл. -- Regards. Ded.
Re: Stack Trace
St. Alex wrote: Да уж, респект. По сравнению с этим, массивы - это детский лепет 8-) Массивами честно говоря вообще не разу не пользовался в FB. И даже чето не тянет :-) И это правильно. Не обращай внимания на извращенцев :-D -- Regards. Ded.
Re: АААААААААААААААААААА!!!!!!!
вот так-то...
OOOOOOOOOOOOOOOOOOOOOO!!!!
La vida habrá la vida
Re: OOOOOOOOOOOOOOOOOOOOOO!!!!
La vida habrá la vida Я после первого тайма и предположить не мог, что будет 3:0... Дмитрий
