Re: Различия версий снапшотов
>> Кто эти люди? Sergey Mereutsa serj собака dqteam -- Banzai, Dmitriy Kovalenko
Re: Различия версий снапшотов
> Кто эти люди? Republic of Moldova, Chisinau. -- Banzai, Dmitriy Kovalenko
Re[2]: ÑÑÑойÑивоÑÑÑ Firebird
> ÑанÑÑе Ñакое на локалÑном ÑеÑвеÑе вÑоде пÑокаÑÑвало Ðа 11 Ð»ÐµÑ ÑабоÑÑ Ñ InterBase и Firebird ÐÐ Ð ÐÐУ (ÑплÑнем ÑÑи Ñаза) не падали базÑ. ÐоÑÑилиÑÑ Ð¿Ð°ÑÑ Ñаз индекÑÑ Ð¿Ð¾ мелоÑи, но база, ÑÑÐ¾Ð±Ñ ÐºÐ°Ðº-Ñо ÑпаÑÑÑ - ÐÐÐÐÐÐÐ. ХоÑиÑе веÑÑÑе, Ñ Ð¾ÑиÑе неÑ. Ðо кÑайней меÑе, в моем пÑиÑÑÑÑÑвии :) ÐÐ¾Ð¶ÐµÑ Ð±ÑÑÑ Ð¿ÑоÑÑо вÑе дело в пÑавилÑном Ð¿Ð¾Ð´Ñ Ð¾Ð´Ðµ к ÑнаÑÑдÑ? (Ñ) :) -- Regards, Dmitriy Kovalenko
Re[2]: ÑÑÑойÑивоÑÑÑ Firebird
> Ðногие Ñанее невиннÑе дейÑÑвиÑ, как Ñо даже копиÑование Ð±Ð°Ð·Ñ Ð¿Ñи > вклÑÑенном локалÑном клиенÑе. RTFM: http://ibase.ru/develop.htm#doc 1. ÐÑÑÑ Ð¼Ð¾Ð»Ð¾Ð´Ð¾Ð³Ð¾ бойÑа и оÑвеÑÑ Ð½Ð° ÑаÑÑÑе вопÑоÑÑ: или инÑоÑмаÑÐ¸Ñ Ð´Ð»Ñ Ð½Ð°ÑинаÑÑÐ¸Ñ , а Ñакже пÑодолжаÑÑÐ¸Ñ . 2. ЧÑо ÐРнадо делаÑÑ Ð² InterBase и Firebird 3. ÐÑÐ½ÐºÑ 23 (на ноÑÑ 3 Ñаза) -- Regards, Dmitriy Kovalenko
Re: Off. ЧÑо Ñ Devrace?
> РподдеÑжка BDS 2009 планиÑÑеÑÑÑ? Ðа. -- Regards, Dmitriy Kovalenko
Re: ÐÑÑÑавиÑÑ ÑпаÑÑ! ÐÐ Ñ ÐмиÑÑÐ¸Ñ ÐÑзÑменко!!!!
> ÐÐµÐ½Ñ Ð Ð¾Ð¶Ð´ÐµÐ½Ð¸Ñ ÐмиÑÑÐ¸Ñ ÐÑзÑменко! ÐÑÑÑÐ»Ð°Ñ ÑÑим ÑекÑÑом Ñвои наилÑÑÑие поздÑавлениÑ. -- Regards, Dmitriy Kovalenko
Re[2]: OFF: Delphi и C++ Builder 2009 для Windows
> Позволяет-ли Delphi 2009 разрабатывать 64 разрядные приложения? Это в следующей версии (Commodor), судя по текущим роадмапам. -- Banzai, Dmitriy Kovalenko
Re[2]: OFF: Delphi и C++ Builder 2009 Ð´Ð»Ñ Windows
> ÐодÑеÑкнÑ, ÑÑо Embarcadero наÑелена на кÑоÑÑ-плаÑÑоÑменнÑе пÑÐ¸Ð»Ð¾Ð¶ÐµÐ½Ð¸Ñ > и ÑабоÑÐ°ÐµÑ Ð¸Ð¼ÐµÐ½Ð½Ð¾ в ÑÑом напÑавлении, и пÑивÑзка к единÑÑÐ²ÐµÐ½Ð½Ð¾Ð¼Ñ > вендоÑÑ Ð½Ðµ Ð²Ñ Ð¾Ð´Ð¸Ñ Ð² наÑи планÑ. ÐÑо бÑло Ð±Ñ Ñо, ÑÑо вÑе ожидаÑÑ, но боÑÑÑÑ ÑказаÑÑ Ð²ÑлÑÑ :) > ÐодÑобнее об ÑÑÐ¸Ñ Ð¿Ð»Ð°Ð½Ð°Ñ ÐÑ ÑзнаеÑе в 2010 годÑ. ЧеÑез полÑоÑа года?! -- Banzai, Dmitriy Kovalenko
Re: ÐРСÐÐÐÐÐ DY !!!
ÐоздÑ. УÑа. -- Regards, Dmitriy Kovalenko
Re: Single isql command exceeded maximum buffer size
On 18 июн, 15:28, Dmitriy Kovalenko <[EMAIL PROTECTED]> wrote: > Мистика... Виноват. Разобрался. Еще до выполнения скрипта с процедурами ехал другой скрипт, который содержал закомментированный код от первой строки до последней, что в целом было около 72K и вероятно isql подавился им аки одной командой. Протрахался полдня, блин... :\ Надо отдохнуть.
Re[2]: Single isql command exceeded maximum buffer size
> Какой-то стейтмент в скрипте имеет длину более 64К. Это я знаю. Но вопрос в том, что в каких случаях _еще_? Или только в этом онли? Я уже уточнил примером странное поведенеи isql. А сейчас вообще очистил файл от кода и... оно тупо выдало такое же сообщение! Т.е. в скрипте ничего нет кроме заремленой шапки со служебной строкой от системы контроля версий Мистика... -- Regards, Dmitriy Kovalenko
Re: Single isql command exceeded maximum buffer size
On 18 июн, 15:11, Dmitriy Kovalenko <[EMAIL PROTECTED]> wrote: > Моя твоя не понимай (с) Или вот так создает процедуры и ругается сабжем: INPUT '..\sql\.connect.sql'; SET BAIL ON; SET AUTODDL OFF; INPUT '..\sql\022\000.main.sql'; COMMIT; INPUT '..\sql\022\001.procedure.sql'; COMMIT; А так НЕ создает процедуры и ругается: INPUT '..\sql\.connect.sql'; SET BAIL ON; SET AUTODDL OFF; INPUT '..\sql\022\000.main.sql'; -- COMMIT; INPUT '..\sql\022\001.procedure.sql'; COMMIT; Здесь вариант с коммитом, после основного скрипта с объектами. Ругается сабжем в обеих случаях, но в одном создает процедуры, а в другом нет, что и вызвает непонятку. Запутался - ни хрена не понимаю уже...
Single isql command exceeded maximum buffer size
Всем привет. FB 2.0.4.13130 Embedded В каких случаях, окромя превышения размера текста процедуры, isql может выдавать сабж? Есть скрипт с процедурами, который успешно (!) выполняется отличными от isql инструментами, но в isql не выполняется (т.е. процедуры не создаются). Также странность вызвает тот факт, что если перед этим скриптом добавить инструкцию коннекта, то isql создаст все процедуры успешно, однако, все равно в лог напишет сабж. Моя твоя не понимай (с) -- Regards, Dmitriy Kovalenko
ÐÑÑниÑа 13
Jim Starkey leaves MySQL. http://www.theopenforce.com/2008/06/falcon-and-jim.html -- Regards, Dmitriy Kovalenko
Re[6]: ÐÑÐ¾Ð±Ð»ÐµÐ¼Ñ Ñ Ð¿ÐµÑÐµÑ Ð¾Ð´Ð¾Ð¼ Ñ FB 2.0.3 на 2.1
>>Ðоложили Ð±Ñ Ñайлик в коÑÐµÐ½Ñ Ð´Ð¸ÑÑÑ 2.1 > Я в "коÑенÑ" не ÑмоÑÑÑ, надо пÑодÑблиÑоваÑÑ Ð² bin. ХоÑеÑÑ Ð½Ðµ Ñ Ð¾ÑеÑÑ, а диÑÑÑибÑÑив, как и вÑÑка жизнÑ, наÑинаеÑÑÑ Ñ ÐºÐ¾ÑнÑ. ÐоÑÑÐ¾Ð¼Ñ Ð¿Ð¾ пÑÑи долгого ÑÐ»ÐµÐ´Ð¾Ð²Ð°Ð½Ð¸Ñ Ð² bin, пÑедÑÑÐ¾Ð¸Ñ Ñаки вÑÑÑеÑиÑÑÑÑ Ñ ÐºÐ¾ÑневÑм йÑÑ Ð² лÑбом ÑлÑÑае. -- Regards, Dmitriy Kovalenko
Re[4]: ÐÑÐ¾Ð±Ð»ÐµÐ¼Ñ Ñ Ð¿ÐµÑÐµÑ Ð¾Ð´Ð¾Ð¼ Ñ FB 2.0.3 на 2.1
> Ðз пÑавилÑного меÑÑа ? > http://www.firebirdsql.org/index.php?op=files&id=engine_210 ÐонеÑно из пÑавилÑного :) http://www.firebirdsql.org/download/snapshot_builds/win/ ÐЫ ÐонимаÑ, ÑÑо ÑелизноÑеÑÑ Ð²ÐºÐ»ÑÑаеÑе ÑолÑко в доки Ñелизов. ÐовеÑÑÑе и Ñам кÑаÑнÑй Ñлажек. ÐÑÑÑ Ð¶Ðµ Ñайл readme_snapshot.txt. ÐалейÑе какой-нибÑÐ´Ñ readme_upgrade.txt или лÑÑÑе !upgrade.txt. РвоÑ, ÑмоÑÑиÑе, здеÑÑ http://www.firebirdnews.org/?p=1725 Ð¸Ð´ÐµÑ Ð»Ð¸Ð½Ðº на еÑе одно "пÑавилÑное" меÑÑо :) Ðоложили Ð±Ñ Ñайлик в коÑÐµÐ½Ñ Ð´Ð¸ÑÑÑ 2.1 - намного Ð±Ñ ÑвелиÑили веÑоÑÑноÑÑÑ Ñого, ÑÑо болÑÑинÑÑво лÑдей во вÑÐµÐ¼Ñ Ð°Ñаки на гÑабли Ñже бÑли Ð±Ñ Ð² каÑÐºÐ°Ñ :), в незавиÑимоÑÑи Ð¾Ñ Ñого, как им доÑÑалÑÑ Ð´Ð¸ÑÑÑибÑÑив, пÑÑÑÑ Ð´Ð°Ð¶Ðµ не ÑовÑем ÑелизнÑй. -- Regards, Dmitriy Kovalenko
Re[2]: ÐÑÐ¾Ð±Ð»ÐµÐ¼Ñ Ñ Ð¿ÐµÑÐµÑ Ð¾Ð´Ð¾Ð¼ Ñ FB 2.0.3 на 2.1
> ÐÑли Ð±Ñ gbak 2.1 вÑполнÑл ÑÑÑ Ð¾Ð¿ÐµÑаÑÐ¸Ñ > авÑомаÑиÑеÑки - ÑÐ°ÐºÐ¸Ñ Ð·Ð°Ð¿Ð°Ñ Ð±Ñ Ð¸ не бÑло... ÐодозÑеваÑ, ÑÑо ÑÑо ÑлиÑком доÑÐ¾Ð³Ð°Ñ Ñена Ñ ÑоÑки зÑÐµÐ½Ð¸Ñ ÑазÑабоÑÑиков Ð´Ð»Ñ ÑеÑÐµÐ½Ð¸Ñ Ð¸Ñкомой "пÑоблемÑ" пеÑÐµÑ Ð¾Ð´Ð°. ÐÐÐ¥Ð, пÑавилÑно пÑинÑли ÑеÑение замÑÑиÑÑ ÑеÑез ÑеÑез ÑкÑипÑÑ. Ðо полÑÑилоÑÑ Ð¸Ð¼ÐµÐ½Ð½Ð¾ _замÑÑиÑÑ_. ÐоÑÐ¾Ð¼Ñ ÑÑо нелÑзÑ, ÐÐÐ¥Ð, пÑÑÑаÑÑ Ð¿Ð°Ð¿ÐºÑ upgrade в Ð¿Ð°Ð¿ÐºÑ misc. ÐÐ¾Ñ Ñ ÑолÑко ÑÑо ÑкаÑал 2.1.1.17910, а в нем Ð½ÐµÑ pdf. ÐÑкÑда Ñ Ð´Ð¾Ð³Ð°Ð´Ð°ÑÑÑ, ÑÑо мне надо делаÑÑ? ÐÐÐ¥Ð, Ñайл, Ñипа, !Upgrade.txt Ñ Ð¾Ð´Ð½Ð¸Ð¼ пÑедложением see more misc\upgrade\*.txt в коÑне диÑÑÑибÑÑива Ð´Ð»Ñ Ð²ÐµÑÑий, коÑоÑÑе ÑÑебÑÑÑ ÑепаÑаÑного ÑÑÑка в бÑбен в дополнение к клаÑÑике b/r бÑло Ð±Ñ Ñамое оно. ÐеÑево и ÑеÑдиÑо. Рглавное ÑÑÐ°Ð·Ñ Ð¿Ð¾Ð½ÑÑно и обÑаÑÐ°ÐµÑ Ð½Ð° ÑÐµÐ±Ñ Ð²Ð½Ð¸Ð¼Ð°Ð½Ð¸Ðµ. -- Regards, Dmitriy Kovalenko
Re: Проблемы с переходом с FB 2.0.3 на 2.1
> Все проходит без ошибок, но при попытке подключиться к ней ловим > ошибку: Может это поможет: http://ibase.ru/firebird/21/metadata_charset.htm -- Regards, Dmitriy Kovalenko
Re[2]: Разработчик Delphi Firebird
> Все лучшее детям (с) :) Более того, если кто-то без кого-то жить не может, то приходите парами :) -- Regards, Dmitriy Kovalenko
Re: Разработчик Delphi Firebird
> Возник вопрос. Есть ли возможность работать не полный рабочий день? См. почту. ЗЫ Если кому-то "мешает" отпуск, в который он собрался летом поехать и поэтому не хочет сейчас переходить на правильную новую работу, то мы решим этот вопрос положительно! Все лучшее детям (с) :)
Re: Разработчик Delphi Firebird
> Или встречаются еще вменяемые руководители? Выращиваем :) ЗЫ Используя феномен пятницы в своих корыстных целях, поднимаю данное сообщение в топы, т.к. есть еще свободная вакансия.
Re: CodeGear приглашает на семинар по InterBase, 29 мая 2008 года
> отложим албанский, возьмемся за испанский :) Вроде как имя CodeGear сохраняется и дополнительно создается подразделение DatabaseGear. Чем они будут заниматься можно догадаться из самих названий.
Re[2]: CodeGear приглашает на семинар по InterBase, 29 мая 2008 года
>> Embarcadero > Кстати, я сейчас перевел с испанского, это название > переводится как "причал". Символично, не правда ли? Еще символичней позиционирование именем на страны 3-го мира, как их в советской программе "Время" называли :) Что, в общем, вполне отражает ситуацию. Так что... отложим албанский, возьмемся за испанский :) -- Regards, Dmitriy Kovalenko
Re[10]: [JOB] Разработчик Delphi Firebird
> А меня простота уже задрала. И очень давно :) Вся сложность в простоте. Вот это загнул... каюсь. -- Regards, Dmitriy Kovalenko
Re[8]: [JOB] Разработчик Delphi Firebird
> Фоновая картинка моего десктопа. Ты мне это... людей-то не распугивай, да? У нас все по-проще будет, да и закручивается все явно безхитросно... :) -- Regards, Dmitriy Kovalenko
Re[6]: [JOB] Разработчик Delphi Firebird
> У нас в городе как то раз крутилась реклама "Опытному программисту требуется > 17-летняя помощница." > Что лишний раз подтверждает мысли о том, чем на самом деле создается > программное обеспечение... Или после чего? А почему тогда все говорят о том, через что именно оно всегда сделано? :) -- Regards, Dmitriy Kovalenko
Re[4]: [JOB] Разработчик Delphi Firebird
> А мне мама, а мне мама ... Да я вам тут щас всем морды набью :) Это уже только завтра, когда выпью водки :))) -- Regards, Dmitriy Kovalenko
Re[4]: [JOB] Разработчик Delphi Firebird
> я днем поспал целых два часа :) То-то я смотрю... на фотографии потянуло! -- Regards, Dmitriy Kovalenko
Re[2]: [JOB] Разработчик Delphi Firebird
>> PS. Завидуйте мне звери, я днем поспал целых два часа :) > Пааадумаешь, я послезавтра уже буду дрейфовать в пучине Красного > моря :-P А я... а я а я завтра просто выпью водки за 9 мая! -- Regards, Dmitriy Kovalenko
Re[4]: Разработчик Delphi Firebird
> Угага. Отож (с) -- Regards, Dmitriy Kovalenko
Re[2]: Разработчик Delphi Firebird
> издержки на сорняки, недород и голодные годы, просто закладываем в расходы. Это за рамками моей компетенции, ничего здесь не скажу. > платить крутому спецу со стороны - бессмысленно. > средненького оставить - ему и зарплату как большому. потом, по результатм. > IMHO, есс-но Я тоже придерживаюсь примерно такой же точки зрения. Но везде есть ньюансы. Для проекта, который обслуживает внутренний софт компании время на выращивание своего специалиста позволено быть большим, чем для проекта, который должен выйти на рынок в разумно минимальные сроки с соотвествующим качеством и начальной функциональностью. Здесь уже надо парочку энтузиастов, говорящих друг с другом на одном языке в плане уровня понимания и ценностей, так сказать, чтобы сдвинуть машину с места в правильном (субъективно) направлении. У нас в компании (_не_ софтверной, это издательство) есть оба вида проектов. Но самое главное и везде - это люди и их уровень слаженности между собой, начиная от идейного уровня, заканчивая культурным, как это ни прискорбно звучит. Знания и опыт они всегда прийдут, в этом нет ничего страшного, век живи - век учись (с). И вот когда такие люди находятся, то очень важно сохранить это достижение как можно дольше. Как пример, у нас работает с 2002 года человек (у него сейчас отдельный проект, самый дорогой по цене для клиентов), пришедший к нам через объявление здесь. Один из лучших наших разработчиков! :) Еще хочу! :) -- Regards, Dmitriy Kovalenko
Re[2]: Разработчик Delphi Firebird
> Не знаю как в Киеве, а в Беларуси есть законодательные ограничения на > размеры зарплат, с привязкой к тарифной сетке и прочим мраком. Не, у нас вроде с этим все спокойно в коммерции (про казенные организации не в курсе). Ессно, налог от Родины на з/п ацццкий, но и здесь есть выход: в градиенте от светло-серого до мрачно черного. -- Regards, Dmitriy Kovalenko
Re: Разработчик Delphi Firebird
> Например, я просто не в состоянии был > предложить работу тому, кого бы я хотел видеть у нас, т.к. у моего > работодателя денег еле-еле хватает на одного такого человека и он уже > работает. Поправка на ветер. Денег нет не потому, что их нет (суслик он есть), а просто по каким-то непонятным причинам (имхо ментальным) они не выделяются на з/п.
Re[2]: [JOB] Разработчик Delphi Firebird
> Если честно рад что хоть одна нормальная фирма есть, во всяком случае по > описанию ;) :) Нормальная - это относительная категория :) Например, я с нее уже один раз увольнялся, в 2003 году :) Но, должен отметить, сдвиги в положительную сторону есть, иначе я бы не вернулся в 2006 точно. > В работе может и был бы заинтересован, но только > удалённо. Как можно работать удаленно, когда рядом с тобой сидят две незамужние и симпатичные, комсомолки, спортсменки и просто хорошие девушки (с) ? :) Похоже, что надо было в вакансии в обязательном порядке указать, что в проекте 2 тестировщицы о 25 годах от роду имеются. На счет удаленной работы. Технически все готово. Но не отработано, поэтому не предлагается. Может в будущем, я слишком пока занят, чтобы еще этот фронт отрабатывать. Удаленно предлагали работать только человеку, который уже проработал в проекте некоторое время и по некоторым причинам был вынужден уехать из Киева. Причем, с сохранением в штате фирмы! Т.е. для любителей полный шоколад - сиди дома и работай. Он отказался, т.к. для себя посчитал нецелесообразным такого рода работу "в одиночистве". Так что удаленка _пока_ предлагается только для тех, кто работал уже в проекте и уходит по адекватным причинам. -- Regards, Dmitriy Kovalenko
Re[2]: Разработчик Delphi Firebird
>> Все вилки на http://www.developers.org.ua/. > ИМХО, этот ресурс - помойка нытиков. Может и так, я вообще не почитатель сего ресурса, поэтому сказать тут мне нечего. Однако, у них там есть попытка аналитики с 2006 года з/п программистов как по всей Украине в целом, так и по Киеву в частности. Посему, имеет смысл воспользоваться данной информацией к размышлению, тем более, что по моим частным каналам цифры в общем находят реальное подтверждение. /* Пользуясь случаем, что сегодня квазипятница, т.к. завтра выходной, пишу дальше */ Очень часто реально в небольших проектах, где требуется человек 5, ситуация выглядит таким образом, что работодатель более-менее оплачивает работу одного программиста (в край двух), типа, ведущего или главного или старого или опытного, как хотите. А на привлечение еще парочки толковых человек просто нет ресура. Вот и все. Вместо того, чтобы двоим-троим программистам, скажем так, с более высокой квалификацией и опытом, сесть и сделать все в разумные сроки, вынуждены заполнять клетки тем, чем, извините, прийдется за такие деньги (понятное дело, что все хорошие программисты уже пристроены на самом деле и редко просто так вывалится кто-то со своим резюме). В результате, проект постоянно тонет в говнокоде, люди меняют друг друга, как времена года, и в целом все начинает напоминать больше курсы повышения квалификации за счет работодателя. В то время, как главный программист на этом фоне становится тупым пожарником, в буквальном смысле этого слова. Например, я просто не в состоянии был предложить работу тому, кого бы я хотел видеть у нас, т.к. у моего работодателя денег еле-еле хватает на одного такого человека и он уже работает. Про то, что фирма при таком раскладе начинает тратить много больше на тушение гиенны огненной, чем на саму разработку, говорить не приходится. Это все превращается в банальный пример того, что скупой платит дважды, а в военное время трижды-четырежды. Я просто не понимаю такой математики, когда фирма тратит деньги на группу товарищей, которые оставляют после себя 0 и даже -1, в сумме, превосходящей ресур на приобретение 2-3 человек, которые оставят +1. Но видимо, для всего требуется время и некоторое количество попаданий на одни и теже грабли, чтобы понять, что ситуацию надо менять в своей консерватории. Мое вышестоящее руководство дает добро на достижение результатов качественными показателями, а не количественными. Соответсвенно моя задача теперь создать необходимую атмосферу и подобрать к ней соотвествующих людей. -- Regards, Dmitriy Kovalenko
Re[2]: Разработчик Delphi Firebird
> э-э-х... Все, что ни делается - все к лучшему (с), а также лучше поздно, чем никогда (с) :) -- Regards, Dmitriy Kovalenko
[JOB] Разработчик Delphi Firebird
Всем привет. С вашего позволения наспамлю здесь нашей вакансией. *** Новый проект от компании, работающей 14 лет в области информационного обеспечения фармрынка, ищет к себе в ряды субъективно для него правильных разработчиков. Нас не интересует ваш возраст, мы отдаем предпочтение единомышленникам. Мы пишем на Delphi 2007 for Win32 для Firebird 2.x.x, строго придерживаясь определенных CodeGear соглашений по оформлению исходного кода, который находится под управлением сервиса http://www.assembla.com/. Так что вы сможете поработать при желании у себя дома или даже на отдыхе. Мы не используем дизайнер среды для разработки форм и их визуальное наследование, из сторонних наборов компонент обходимся EhLib и FIBPlus. Пишем документацию, используя DocBook, в любом текстовом редакторе, что может попасть под руку. Разрабатываем базы данных версионными SQL скриптами, вместо логов разницы между "той" и "этой" базами. Клиентское приложение строится на основе механизма загружаемых BPL, где пользовательский интерфейс собирается в runtime при помощи минимальных наследников TComponent, TForm, TAction и IInterface на основе регистраций, определяемых в простых текстовых файлах. Все проекты собираются одним кликом из SVN до InnoSetup через MSBuild. Ознакомиться с общим концептом приложения можно здесь (1.16M): http://runningmaster.googlepages.com/ide3050install.zip З/п белого цвета аккуратно кладется бухгалтером на пластиковую карточку два раза в месяц, определяется по результам собеседования и гарантированно будет иметь соответствие тенденциям, отображаемым на сайте http://www.developers.org.ua/. Полный рабочий день + гибкий график, оплачиваемые больничные и отпуска, отсутствие ограничений для работы в сети Интернет. Из офиса до ближайшей станции метро можно добежать за 30 секунд. Наш адрес: Киев, Бажана 10-А этаж 7 (М.Осокорки) Контакт: [EMAIL PROTECTED] (044)585-9710 Катерина -- Regards, Dmitriy Kovalenko
Test
Test -- Regards, Dmitriy Kovalenko
Re[2]: Обращение к переменным в PSQL
> двоеточия с левой стороны знака равенства не может и не должно быть. Еще в epsilon.public.interbase вроде как определились по этой теме, что если идет обращение к значению параметра(переменной), то ставим двоеточие перед последним(ей), ежели в этот параметр (эту переменную) присваивается значение, то не ставим двоеточие. PARAM_OR_VAR_1 = 7; IF (:PARAM_OR_VAR_1 = 7) THEN BEGIN PARAM_OR_VAR_2 = :PARAM_OR_VAR_1; END PARAM_OR_VAR_1 = :PARAM_OR_VAR_3; Я все правильно напутал? :) Хотя оно, конечно, работает и так и эдак. Что и приводит к путанице и вопросам. -- Regards, Dmitriy Kovalenko
Re: Битии Index вроде
> Сегодня в одном месте сильные тормоза бдруг появились, подозреваю > что индекс полетел. Привет. К слову. Я уже 2(ДВА) раза (в марте и в июне сего года) столкнулся с крайне неприятной ситуацией: вдруг откуда не возьмись появился... тормоз при элементарной вставке данных в элементарную таблицу. Тормоз длиной в 2 минуты, а для покупателя - длиной в жизнь. Полная катастрофа здесь в том, что это вставка позиции в чек на кассе. Лечение: бекап/рестор. Валидации с командной строки показывают, что с базой все ОК. Это на FB 2.0.1.12855. Казалось бы, причем тут Дятел? :) ЗЫ Могу оформить БД с этим тормозом - уже таких две в коллекции :( -- Regards, Dmitriy Kovalenko
Re: [OFF/2] ÐÑо окÑÑгление и NUMERIC
> ÐÑо как ÑеÑÐ°ÐµÑ ÑÑÑ Ð¿ÑоблемÑ? ÐÑивеÑ. 1. ÐÑе ÑиÑла Ñ Ð¿Ð»Ð°Ð²Ð°ÑÑей запÑÑой Ñ ÑÐ°Ð½Ñ Ð² DOUBLE PRECISION 2. Ðогда надо окÑÑглиÑÑ ÑезÑлÑÑаÑ, Ñо ÑÐ·Ð°Ñ ÑобÑÑвеннÑй UDF_ROUND, на оÑнове ROUTINES FOR ROUNDING IEEE-754 FLOATS TO SPECIFIED NUMBER OF DECIMAL FRACTIONS - ÑÑо из модÑлÑ, взÑÑого мной из CodeCentral. -- Regards, Dmitriy Kovalenko
Re[2]: OFF: Delphi 2007 Enterprise Trial
> и так далее. New IDE features since Delphi 7 http://dn.codegear.com/article/34323 New VCL features since Delphi 7 http://dn.codegear.com/article/34325 New Delphi language features since Delphi 7 http://dn.codegear.com/article/34324 http://www.stevetrefethen.com/blog/VCLAndRTLEnhancementsSinceDelphi7D7.aspx -- Regards, Dmitriy Kovalenko
Re[2]: [ANN]
> Что важнее: сделать тул быстрее или изучить что-то новое - это вам > решать. Видимо вам важнее тул. Сдается мне, что пользователь вряд ли будет оплачивать из своего кармана обучение разработчиков таким явным образом... Я не буду скрывать, что много думаю про "переход" на Net (лично для себя), но здравый смысл в моей реализации, а также обстоятельства, пока не разрешают мне тратить на это свое время. -- Regards, Dmitriy Kovalenko http://metadataforge.com --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
Re[2]: [ANN]
> А вобще разговор начался с тому почему нет тулов под виртуальные > машины (Java или NET). Мне преимущества от этого кажутся очевидными. > В принципе если оно будет написано, то мне пофиг на жабе или на C#. > Поэтому я вопрос ставил не что лучше, win32 или виртуальная машина, > а почему вобще не пишут тулов для виртуальных машин, а пишут ещё > один такой же, но другой, из ряда имеющихся под win32. Зачем делать под Win32 на C#, если это можно сделать, к примеру, на Delphi Language, на обучение которого ты не будешь тратить годы(!)? Зачем делать на С#, если 98% потенциальных потребителей твоей программы сидят и будут сидеть на Win32? Зачем брать на себя карму разработчиков Net/Mono при глюкаловах, несовместимостях и еще какой-то ущербности из-за "универсальности" технологии, ибо для пользователей это все будет исходить от тебя, как разработчика продукта? Сравнение перехода с DOS на Windows, ИМХО, абсолютно некорректное при употреблении его в контексте проблемы начала XXI века - "Net vs Win32". Потому как Net в Windows сидел, сидит и сидеть будет на Win32 (в будущем на Win64) и WinAPI вместе со средствами разработки отменять в обозримом и необозримом будущем никто не собирался. Зачем платить больше? Что Win32, что C# под виндой "генеритует" одинаковый результат для глаз пользователя (речь про обычную программу - winforms). Для программеров, конечно, Net (как все новое) дает более продвинутые возможности (в обмен на какие-то новые свои недостатки :)) как по языку, его библиотекам, так и по IDE. Это уже вопрос соотношения пользы для плода и вреда для матери. Другой вопрос, что все бабло под чутким руководством MS уходит в Net, вместе с армией новых программистов. Это уже отдельная песня... А есть еще песня про то, что потом это бабло пойдет с высокой вероятностью в некий MegaCoolNet, объявивший вне закона Net теперешний, но все также остающимся на Win32 в своей основе :) И вообще, разве телевизор Net сегодня уже также одинаково хорошо показывает на всех осях, как на Windows? Тут, блин, win32 проги глючат между Win2000 и WinXP... :))) -- Regards, Dmitriy Kovalenko http://metadataforge.com --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
Re[2]: [ANN] ?????? SQLHammer
Привет. > кстати, разработчикам аналогичных инструментов - по умолчанию > делайте имена объектов в UPPERCASE, без кавычек!!! > И только если разработчик 3 раза попросит, делайте кавычки. В кавычки должно браться по правилам. Если разработчик попросит 7 раз, то все равно такое поле, как "My Field" должно быть взято в кавычки в 3 диалекте. > Была б моя воля, я вообще раз в месяц дня на три отрубал бы > все эти "оглупляторы" типа "интерактивное создание таблицы", > и заставлял все делать в sql editor, ручками. Программа и так сделана в парадигме "АНТИоглуплятор", т.к. априори ручная, как для GUI-инструмента. -- Regards, Dmitriy Kovalenko http://metadataforge.com --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
Re[2]: [ANN] ����������������
Привет. > Скачал я 1.7 вместо 1.4.х - как брались имена полей в кавычки два > раза, так и берутся. Где? (мог забыть, много времени прошло) > Вобще 1.7 отличается от 1.4.2 хоть чем-нибудь? Правками некоторых из выявленных багов. -- Regards, Dmitriy Kovalenko http://metadataforge.com --~--~-~--~~~---~--~~ -~--~~~~--~~--~--~---
Re: Порядок вызовов UDF
> Сделай их вложенными. > UDF1 (..., UDF2 (..., UDF3 (...))) > > ЗЫ: я промолчу, но все понимают об чём я молчу... Со мной можешь не стесняться - говори, что считаешь необходимым :) Спасибо за подсказку. Дмитрий Коваленко
Порядок вызовов UDF
Всем привет. Возможно ли как-то явно задать порядок вызова UDF, например, для такого запроса: SELECT UDF1 (...), UDF2 (...), UDF3 (...) FROM MY_TABLE ? Эксперимент показывает, что порядок вызовов UDF не соблюдается (возможно такой вопрос уже поднимался в эпсилоне). Дмитрий Коваленко
Re: Вакансия в Киеве
> А как вообще ситуация с файрбердщиками в Киеве ? В целом плохо (по нашему опыту поиска). Дмитрий Коваленко
Re: Вакансия в Киеве
> ога! тожа интересно, скiльки ж у нього записiв в найбiльшiй таблицi? :-) Если уже просто распирает - пиши в приват, узнаешь цифру. Дмитрий Коваленко
Re: Вакансия в Киеве
> И как с поиском сотрудника ? Нашли ? Привет. Ищем. Дмитрий Коваленко
Re: Кажись, сбывается мечта многих (идиотов? :-)
> угу, "якобы" : > > a) x = COALESCE(a, b, c) > > b) x = CASE WHEN a IS NOT NULL THEN a > WHEN b IS NOT NULL THEN b > WHEN c IS NOT NULL THEN c > ELSE NULL >END > Дело предпочтений. Не всегда сокращенный таким образом код есть благо (с логической точки зрения). Кто-то предпочтет более "прозрачную" читабельность кода, для себя вполне обоснованно, даже если физически кода будет больше (как в вышеприведенном тобой примере). Дмитрий Коваленко
Re: Кажись, сбывается мечта многих (идиотов? :-)
> Е> coalesce неудобно, невозможно запомнить, как пишется это дурацкое слово > > Это потому, что в голове опилки. Привет. COALESCE "удобнее" тем, что (якобы) сокращает код относительно эквивалента в CASE, однако, поддерживаю, что (лично мне) это слово в голову тяжело помещается :\ Но уже таки запомнил :) Дмитрий Коваленко
Re: Вакансия в Киеве
> При чем тут размер БД и число записей в таблице и количество объектов? Привет. Две большие разницы - когда приходит человек после базы (IB/FB) в 10 таблиц и 20 процедур и когда приходит человек после, например, 100 таблиц (где есть таблицы-миллионники) и 400 процедур. Эти люди уже совсем по другому относятся к жизни :) Как минимум, эта информация поможет нам определиться, как организовать вхождение человека в проекты. Дмитрий Коваленко
Re: есть ли способ проверить идентичность
> Хотелось бы именно формальный железный вариант: > БД1=БД2 по таблицам A, B, C БД1=БД2 по таблицам A, B, C проверяется по метаданным. > и при этом не хотелось бы делать потабличное сравнение каждой записи - > записей в таблицах около полумиллиона. Проще тогда уже _пакет передаваемых_ данных 10 раз проверить на месте, не отходя от кассы "эталонной" базы. Все равно, это не поменяет полезной сути оптимистического подхода :)
Re: есть ли способ проверить идентичность д
> Нужен "быстрый" способ проверки правильности установки обновления -
> сравнения идентичности эталонной БД и БД, полученной в результате
> обновления
Нет ошибок - значит все верно. Такой вот
простой вариант ("оптимистический
подход") не подойдет?
Re: Инструмент размещает свои метаданные в БД (?)
> По-моему, уже все привыкли к этому. IBE именно это и делает. IBE и иже с ним "лезут" своими метаданными в базу _по желанию_ пользователя (опционально). Моя же теоретическая "проблема" в том, что есть радикальный момент, который заключается в том, что размещение в базе данных собственных метаданных будет _априори_ необходимым условием для работы такого инструмента. Радикализм подхода доходит до такой степени, что даже банальное получение имен объектов должно производиться путем спроса, например, хранимой процедуры, а не посыла текста запроса с клиента. Склейка объектов DDL также на стороне сервера. Использование UDF и т.д. и т.п. Другими словами инструмент должен состоять из server-side и client-side кода. > чтоб инструмент предупреждал о всех необходимых изменениях в базе и > объекты именовал однообразно, типа: XXX$... Это конечно.
Re: Инструмент размещает свои метаданные в БД (?)
> Если фиксированное постоянное кол-во, то нормально. Если на каждый > пользовательский объект по своей процедуре/триггеру/таблице, то не знаю. Да, фиксированное малое количество, имена префиксированные, конечно же. Пользовательские объекты НЕ затрагиваются _никак_.
Re: Инструмент размещает свои метаданные в БД (?)
> Неужто репликатор? Нет. Возможно пока нет :).
Re: Инструмент размещает свои метаданные в БД (?)
> Я понимаю или догадываюсь зачем. Но по-моему это плохая идея. Как бы сам так думаю, однако, можно кое-чего скинуть на сторону сервера: и быстрее будет (до упора в буквальном смысле) и на клиенте много проще и надежнее код. Поэтому просто спрашиваю. Сам я, как пользователь, плохо отношусь к размещению метаданных инструмента в базе данных и не использовал никогда такие возможности. Но, если бы у инструментов была жирная кнопка "зачистить все" (которой я в упор не вижу в них), то мог бы изменить свое мнение. Какой-то момент больше из области психологии...
Re: SQLHammer
> Как дела на фармацевтическом рынке? > Всех конкурентов победил? Прошу задать вопросы другими словами, так как не совсем понял их тайный смысл.
Инструмент размещает свои метаданные в БД (?)
Всем привет. Теоретический вопрос. Как бы уважаемые отнеслись, например, к такому инструменту для работы с базой данных, который бы в обязательном порядке для своей работы размещал бы в ней некоторые свои метаданные (таблицы, хранимые процедуры, триггера и т.п.)? Конечно же, с одной большой кнопкой для полной зачистки оных одним махом. -- Regards, Dmitriy Kovalenko http://metadataforge.com
Re: SQLHammer
> На пенсию-то нам еще рано:) Какой новый проект, если не секрет? Возвращен в предметную область - фармацевтический рынок. > Одну вещь я бы хотел посмотреть, а именно что делаешь с PageControl, чтобы > он так выглядел. Не мудрствуя лукаво, нагло позаимствовал код из какой-то демки, уже не помню из какой. Замена оконной процедуры TPageControl с обработкой одного сообщения. Залью на досуге пример на ftp. Всего несколько строчек кода и не надо делать своего наследника.
Re: SQLHammer
> Если нет возможности ни разрабатывать продукт, ни выгодно продать его > кому-либо, значит надо выносить в open source. Иначе банально умрет > результат пары лет работы. Он, разумеется, может и в случае open source > умереть, но так хоть отсрочка будет. Первым делом я должен получить согласие от Паши Шибанова на такой шаг, т.к. открываться будет и его код тоже, которого не слабо. В любом случае, есть некий SQLHammer 2 (рабочее название кода Mumonkan) только с моим кодом, от которого можно хорошо оттолкнуться. Далее, у меня нет опыта работы над open source проектами... Другими словами, каким образом идет там разруливание работы? Например, с "раздачей" исходников все понятно, но если каждый будет править на свое усмотрение код в CVS, то хаос неизбежен (?) Должны быть какие-то организационные мероприятия. Общедоступный CVS, хороший хостинг и прочая организация процесса уже, ессно, в наличии. В общем, кому интересно, пишите в почту, обсудим.
Re: SQLHammer
> Сам юзаю - приятная и шустрая штучка. Дык, я тоже юзаю :) Есть нечто, что сделал через ж$пу и под влиянием (надо переписать на досуге), за то быстро работает и мне самому всего хватает. -- Regards, Dmitriy Kovalenko http://metadataforge.com
Re: SQLHammer
> Что-то на сайте сабжа тихо. Затишье перед бурей или проект закрылся? Привет. Спасибо за вопрос. У меня, по всей видимости, плохая карма :( Я не работал над этим кодом с конца ноября месяца прошлого года. Поэтому имеем то, что имеем (с). К слову, думал сделать проект открытым, но не уверен, интересно ли это кому-нибудь, кроме меня, будет? -- Regards, Dmitriy Kovalenko http://metadataforge.com
Re: CURRENT_TABLE
> но я так и не понял что тут упрощает Current_Table. Просто упрощает _написание_ и _чтение_ кода. Вместо того, чтобы прописывать в дизайнтайм (или клеить в рантайм при создании) в каждом триггере имя таблицы аки константу строковую, можно элегантно использовать "псевдоним" CURRENT_TABLE. И если реализация CURRENT_TABLE в сервере гроша ломанного не стоит по стоимости своей, то почему бы и нет (с учетом уже сделанных всевозможных CURRENT_XXX)? Другое дело, что может быть не все так просто - тогда другой разговор и CURRENT_TABLE тогда однозначно в сад или в далекое будущее. Спору нет. > нормальное блокирование всемогущего SYSDBA. Так вот кто заказывал узнать программно пароль SYSDBA в базе? :))) > Зато с самолётиками - хоть залейся. Из самолетиков складывается эскадрилья приятных мелочей. Речь не идет о том, чтобы поставить приоритет для CURRENT_TABLE выше, чем для SMP или таблиц подобных в IB7.
Re: CURRENT_TABLE
> Резюме: > По полезности далеко не на первом месте фича, скорее она вредна т.к. > порождает новое поколение проктологов. Конечно, не на первом. На счет вредности в образе зачатия молодых проктологов есть сомнения. Перефразируя известную пословицу, скажем таким образом: хорошему проктологу яйца не мешают :) Другими словами, для таких профессий на ibase.ru есть целая статья, которая говорит, что не надо делать в первую очередь. К слову, если вылезти из танка и выглянуть из люка, то можно получить знание о том, что представители некоторых других серверов причисляют к проктологам всех нас вместе взятых, только при упоминании имени сервера, с которым ты работаешь. Это, конечно, оскорбительно и неприятно и не соответсвтует действительности, в общем... Однако, как говорится, дыма без огня не бывает...
Re: CURRENT_TABLE
> На клиенте просто проще со строками работать. Вот-вот. С этого и надо начинать. Имея CURRENT_TABLE можно иметь возможость не переносить такой код на клиента, из-за того, что он существенно теперь упростится на стороне сервера (не надо вычислять и затем "вклеивать" имена таблиц).
Re: CURRENT_TABLE
> Хм, хоть и не встречались давненько, но я ещё помню - когда ты > начинаешь говорить много, горячо и убедительно, знач пошла демагогия ;) Просто внимательно смотри начальные посты. >Имхо облегчение жизни программиста - это когда его не имеют в хвост и > в гриву ежедневно за то что программа не работает или еле ползает. Ты здесь смотришь со стороны вытекающих. Ведь такой результат (когда не имеют программиста), можно добиться и проктологией в том числе. Мне же более по душе, когда меня не имеет сам проктологический процесс (когда не хватает очевидных вещей на ровном месте). Откуда вывод, что из-за CURRENT_TABLE у меня все тормозить будет? > А некоторые очень хочут получить FB в карманных компах. И я > их понимаю. И я очень хочу тоже. И не раз спрашивал сам :) Пользуясь случаем (с) еще раз хочу! :) >Какая именно польза - я от тебя пока так и не добился. Польза - и всё > тут ;) - Повторяю: польза в том, что в коде триггера можно "программно" узнать, для какой таблицы выполняется его код. - Этого недостаточно? Мучает вопрос зачем это надо? :) Может мне не хочется делать вещи дедовскими способами (в прямом и переносном смысле :)) > Всё-ж таки, что ж эта процедура будет делать? Код, сьестра, код! Да пох абсолютно, что это будет. Причем тут код? > И потом в триггере таблицы Execute Statement S_Return? Или где? Домашнее задание: найти упоминание в моих постах из этого треда, где я говорю об использовании EXECUTE STATEMENT в логирующих триггерах. (Правильный ответ: я не использую EXECUTE STATEMENT в логирующих триггерах). >То есть, не трогая их триггеров вообще? Волшебный супертриггер > всеобщего логирования что ли? Не трогать определения (код) таблиц (добавление полей в них). Это просто триггер. Просто обычный триггер. Самый настоящий триггер. Только который может знать через CURRENT_TABLE на КАКОЙ таблице он исполняется. Это проктология? Проктология здесь в моем понимании как раз не иметь возможность в рантайм иметь в руках эту информацию. >Хде? Хто? Предлагал? >Хде? Хто? Предлагал? >Хде? Хто? Предлагал? Перечитай еще раз и выбери по авторам. Я ж не с потолка взял, а перечитал все, выбирая упомянутые решения. >Лично я предлагал и предлагаю статические триггера генерируемые влёт > совершенно несложной приблудой. Ты может будешь удивлен, но я тоже. Более того, если бы у меня была возможность CURRENT_TABLE, то это я сделал бы ЕЩЕ ПРОЩЕ. Так понятно, из-за чего вопрос о CURRENT_TABLE снова возник? :) Кучу CURRENT_XX сделали? А там нельзя было обойтись "с клиента" или десантом с Марса? А ввод Емановым универсальных триггеров на события? Зачем? И без них все было прекрасно... >Если ты очень настаиваешь, я таки сделаю тебе генератор триггеров > процедурой, получающей на вход имя таблицы. Дык, я ни на чем не настаиваю. Такого добра у самого в достатке. >А кому-то зачем-то надобиццо название базы... А кому-то зачем-то имя > хоста... А кому-то зачем-то пароль SYSDBA... И это уже так или иначе практически есть (см GET/SET CONTEXT), окромя пароля. > Дим, чем слезу давить и тельняшку рвать, ответил бы самому себе хотя бы на > ОВСФ сначала вразумительно, а? Не давлю. Просто я спрашиваю про одно, а меня лечат какой-то хренотенью совершенно не по теме. Я не выношу на обсуждение сейчас механизмы, в которых мне понадобился бы CURRENT_TABLE. Я говорю, что с ним мне было бы легче и проще их реализовать и спрашиваю, чем заканчивались ранее обсуждения этой темы.
Re: CURRENT_TABLE
> Моё отношение к прогрессу: > 1. Докажи, что без этого чего-то сделать невозможно. > 2. Не смог - докажи, что это даёт существенное увеличение > производительности СЕРВЕРА, а не программиста, в достаточно широком > классе задач, Гм... может я в чем-то ошибаюсь, но я вижу, что весь мир движется по направлению к облегчению жизни именно программистов, читай людей, а не "серверов". Другое дело, что кто-то может переусердствовать, не будем упоминать в суе кто именно :) К примеру, добавление Олегом в Yaffil встроенных функций демонстрирует гуманный подход к людям в своем лучшем виде. Ведь без них же можно смело обойтись, сделав реализацию в UDF! Однако, как приятно и УДОБНО, что этого делать не надо. Я уже не говорю про экономию времени и сил на сотворение _элементарных_ UDF и их неминуемую отладку, что еще не гарантирует, что багов в результате не будет. Вопросы разного рода логирования и репликации были, есть и, смотрю, долгое время еще будут актуальными в нашем народном сервере. Потому как все "лучшее" серверу, а программистам - в очередь на курсы по проктологии :) Еще надо смотреть с точки зрения сложности реализации фичи в сервере и на соотношение стоимость реализации/польза на выходе. К слову, никто из Чапаев не высказался по этому вопросу. И если там делов "на две строки и на бутылку пива", то польза от CURRENT_TABLE будет многократно больше (плюс уже куча всяких CURRENT_XXX имеется), не смотря, что могут сделать только к версии 4.0. Если там гиенна огненная это делать, тогда совсем другой разговор и CURRENT_TABLE этого просто не заслуживает. > а не в той личной проктологии, в которую ты сам себя > загнал, забивая болт на правила проектирования. На правила проектирования и проктологические аспекты тоже может быть разное видение. К примеру, вместо того, чтобы, допустим, в коде каждого триггера (отдельного) просто повторить ОДНУ строку: EXECUTE PROCEDURE (CURRENT_TABLE, NEW.ID/OLD.ID, <тип операции>); и при этом НЕ ТРОГАТЬ логируемые таблицы вообще на каком-либо уровне, включая логический (это значит, что можно добавить/изъять или включить/выключить целую функциональную логическую часть системы, что другие части даже об этом _не догадаются_ - обращаю на это внимание отдельно) поступают предложения: - прописывать руками имена таблиц как строковые константы (вспоминаем Коваленко, когда он говорил, что где-то забыл триггер сделать, здесь можно просто сделать ошибку в букве) - добавления доп полей в таблицы (размазывать логику логирования по всем таблицам в виде доп полей) - использования DEFAULT полей с именем (в каждое таки надо прописать руками имя таблицы) - упоминание про GET/SET CONTEXT - кто-то еще призагнул про какие-то ветвления по имени таблицы, вообще не разобравшись в сути треда (это уже проблемы индейцев и где-то таки может быть удобным) И это все менее проктологичнее одной строки кода, плюс сделанной автоматически? (конечно, при прочих равных условиях) Чем плохо, когда пользователь просто пометит чекбокс на клиенте в сетке напротив имени таблицы, а в это время для этой таблицы _на стороне сервера_ сгенерится триггер на поддержку логирования? Стоимость решения на клиенте - стремится к 0. Т.е. просто включить/отключить чекбокс с коммитом. Т.е. вообще ничего, по сути. Вместо этого мне надо делать на клиенте код генерации триггеров? Это дешевле? Он у меня есть, но в данном случае, я хочу, чтобы даже его не было (в общем, это не относится к CURRENT_TABLE). > 4. Ничего доказать не смог - иди в сад со своими хотелками. Голос из сада :))): имхо, если в триггерах кому-то надобится иметь непосредственное название таблицы, то CURRENT_TABLE уже автоматически лучше, со всеми вытекающими, чем прописывать 'MY_TABLE_NAME' в каждом разе. И это все просто БЕЗОТНОСИТЕЛЬНО к разного рода проктологическим приемам.
Re: CURRENT_TABLE
> > Ладно, каков вывод делать? CURRENT_TABLE - > > отказать на принципиальном уровне? > > Прям сразу и в обидки :) На каком основании такой вывод? :) Я абсолютно ровно отношусь к этой проблеме. Обходной путь есть, просто с CURRENT_TABLE, как-то красивше было бы, если можно так выразиться. Тем более с учетом _уже_ размноженных CURRENT_XX с информацией об "окружении". В этом контексте и возникла реинкарнация вопроса о некоем CURRENT_TABLE, который поднимался уже не один раз. Т.к. по результатам обсуждения больше просматривается "нет", чем "да", то резюмирующий вопрос имеет отрицательный смысловой оттенок. > Вишь - Чапаи молчат, знач думают. Печёнка > чует, что где-то должен быть с неё какой-то толк. Но вот где и какой - > придумать не может. Безопасный COPY-PASTE кода триггеров :))) Кстати, не совсем смешно, а даже очень и очень (с) :) Т.к. именно ошибки, порождаемые этой технологией наиболее трудны в своем выявлении... > То, что тебя к ней сподвигло, динамика в > SQL-выражениях в триггере - прямой путь к тормозам. Да нет никакой динамики :) Я просто хотел (иметь возможность) оформить _одинаковое_ тело для всех искомых триггеров наиболее простым способом, не прописывая _в каждом_ из них руками имя таблицы-овнера аки строковую константу в кавычках, а просто элегантно указать CURRENT_TABLE. Другими словами, код может быть более читабельным и "переносимым" (между триггерами).
Re: CURRENT_TABLE
> Я это предлагал пару лет назад ;) Я помню, что это уже обсуждалось. Может быть даже не один раз. Ладно, каков вывод делать? CURRENT_TABLE - отказать на принципиальном уровне?
Re: CURRENT_TABLE
> > _через_ EXEC STATEMENT _из другого места_ > >Заметьте, не я это предложил (C) :-D :))) > Это уже в триггере логируемой таблицы, как я понимаю? А UDF, в таком > разе, коннектится к той же базе, извлекает список полей из > RDB$Relation_Fields и конструирует логирующий стейтмент? Ну, это уже не > простая проктология, а каскадная, через UDF ;) Да нет, это _не_ в триггере логируемой таблицы. Это в другом месте (ставлю уже (с) : Т.е. в триггере на таблице - списке таблиц, подлежащих логированию. Дергается, предположим и не вдаваясь в подробности, ОДИН раз для создания триггера с "нативным" кодом _для_ логируемой таблицы. Ладно, забудем про UDF, вопрос о соотношении пользы для плода и вреда для здоровья матери от контекстой переменной CURRENT_TABLE, по которой в коде триггера можно "программоно" изъять название таблицы, для которой исполняется код триггера.
Re: CURRENT_TABLE
> > "* Any DDL (except Create/Drop Database).", должно работать... > После коммита. Ну, нормально. В общем, может повеять жестким садо-мазо-прокто от такой идеи, однако, иметь некий "указатель"на Self (информацию о контексте) в теле триггера/процедуры может пригодиться для роботизированного сотворения некоторой логики. Совсем необязательно для нужд репликации/логирования... Конец концов, уже есть CURRENT_CONNECTION, CURRENT_TRANSACTION, CURRENT_USER и CURRENT_ROLE, а бедный триггер до сих пор не в курсе, для какой таблицы он исполняется. Павидло просто какое-то... (с) :)
Re: CURRENT_TABLE
> Таки тоже потянуло на старости лет в проктологию? ;)
Ну за чем же? :)
Просто в этом триггере (или через вызов
одной процедуры) можно было написать
нечто подобное (автоматом, через EXEC
STATEMENT из другого места)
INSERT INTO MY_TRACER (
TABLE_NAME,
OPERATION_TYPE,
PRIMARY_KEY_ID
)
VALUES (
CURRENT_TABLE,
/* Здесь переменная со значением в
зависимости от DELETING, INSERTING или UPDATING*/
NEW.ID или OLD.ID для DELETING);
Хотя, в общем, задача решаема через
возвращения текста DDL для EXEC STATEMENT из UDF:
---BOF--
SELECT UDF_GET_LOGDDL('имя таблицы') FROM RDB$DATABASE INTO
:V_DDL;
EXECUTE STATEMENT V_DDL;
---EOF--
Re: CURRENT_TABLE
> Да и элементарный аудит действий пользователя... И здесь тоже. И еще может где сгодится в хозяйстве. > Вообщем сейчас придем к одному триггеру для всех таблиц :))) Даже, если в конструкции CREATE TRIGGER имя таблицы можно будет задавать через зяпятую (одевая железную каску) :), то все равно для программного разруливания CURRENT_TABLE желателен, т.к. логика обработки может отличаться (мальчики налево, девочки направо и т.п.) для "единого" триггера в зависимости от таблицы.
Re: CURRENT_TABLE
> А потом - Current_Table_Current_Columns_Set? ;) Один чёрт триггера > генерировать неким (полу)автоматом на клиенте. Или по каждому чиху в > триггерах в rdb$relation_fields лазать будешь и execute statement > складывать? Долго и упорно я оттягивал свое знакомство с конструкцией EXECUTE STATEMENT, поэтому не скажу, буду ли я перед ней лазить в RDB$RELATION_FIELDS... Но могло бы быть удобным из триггера на таблице (предположим, список имен таблиц, подлежащих некоему логированию), создавать "логирующий" триггер для необходимых таблиц. Удалять (или (де)активировать) там же. Впрочем, можно текст такого триггера в UDF сгенерить и вернуть... Если можно сделать все на стороне сервера, то не хочется размазывать по клиенту эту логику (ИМХО). Смотрю в описание ES, вижу: "* Any DDL (except Create/Drop Database).", должно работать...
Re: CURRENT_TABLE
> Т.е. ты пишешь триггер, но не знаешь для какой таблицы ??? Я хочу (скажем, размечтался :)), чтобы в коде триггера можно было узнать имя таблицы, для которой он выполняется в данный момент. Как минимум, можно было бы иметь _один_ код для всех таблиц. И если EXECUTE STATEMENT позволяет создать триггер (не пользовал еще эту чудесную конструкцию, сейчас посмотрю доку), то можно вообще кое-что делать просто одним "легким движением руки" (с)
Re: CURRENT_TABLE
> Чую, чую - над репликацией задумался? :) Правильный ход мысли :) Задумался... и подумалось, что такая приятная мелочь, как CURRENT_TABLE, мог бы заметно упростить жизнь в деле "автоматизации" сего процесса.
CURRENT_TABLE
Всем привет. Имеется ли возможность (вопрос теоретический, адресуется шаманам) сотворить некую контекстную переменную, видимую в теле триггера, да бы в нем "программно" знать, для какой таблицы выполняется искомое тело триггера? Если такой вопрос рассматривался уже, то чем закончился? Избили ногами вопрошающего или "шанс" остался? :)
Re: FW: Jim, Ann, and Netfrastructure
> I will be working full time for MySQL Ох$ть, дайте две (с) С другой стороны, что не делается, то к лучшему. Еманов/Хорсун и Ко еще больше работать будут (?) :)
Re: OFF: Delphi 2006, C++Builder 2006, C#Builder 2006 Trial now available for download
> а чего тебя понесло, на сервак да еще на R2 > среду разработки ставить? :-) Ну я воспринимаю Win2003 более продолжением линии NT4-Win2000, нежели балалайку с кодом XP... :) Может по теории это не совсем верно, однако, из моей собственной практики для себя сие следует со всей очевидностью. > и что теперь, Борланд виноват в том, что микрософтовский > .Net 1.1 криво ставится на микрософтовскую же операционку? Поиска виновных нет. Просто факт, с которым я столкнулся. О чем сообщаю, кому-то может пригодиться загодя. > Дима! Тут же почти все программисты, неужели непонятно, > что ОДНУ среду проще сопровождать чем ТРИ? Здесь прежде всего люди, которым тяжело терпеть измывательства над их молодыми организмами такой вещью как IDE от BDS в стиле VS :) Конечно, я понимаю, что они (Borland) попытались наесться рыбы сидя кое на чем. Но мы то тут причем? :) Как по мне, движение в сторону такого IDE только усугубляет ситуацию (кстати, виден откат в обратную сторону - отделение дизайнера форм от кода и т.д.). Когда из 2/3 мест на экране на тебя смотрит голодными глазами ALM Made in Borland, который я не собираюсь юзать. Такие фичи по дефолту должны быть отключенными и _доставляться_ в IDE экспертами _по необходимости_. Посмотрю на работе еще, может можно действительно поотрубать пакеты какие-то из среды. Прежде всего это среда разработки, в которой все должно быть первым делом затачиваться для удобства этой самой разработки, а не управления жизненным циклом ПО. Управление это хорошо, но когда в IDE торчит из каждого места начальник по управлению циклами ПО, то это уже превращается все в одну большую Ж, а не в серду разработки конкретной программы, которую ты пишешь. Я уже из-за политкорректности не говорю про его глючность (неотрисовка доставленных кнопок на тулбаре, смертельная пропажа главного окна приложения, что даже на F10 не реагирует, глюкалово с дизайнером форм по F12 в определенном режиме), несмотря на Update1. О, а попугаистые тулбары с градиентами - вот без чего не могли жить программисты! :) Это просто маразм. Наверное в след версии можно скины ожидать... Еще сильная вещь - все теже мультики при отрисовках и переключениях (конечно, не так аки в 2005) и это на очень хорошей по современным меркам машине (AMD64 3000/1Gb/SATA). Конечно, это не Borland, это MS Net. Просто Borland кидает насильно в это Г всех тех, кто туда сам пока не собирается...А это неприятно :) Еще я просто в бешенстве от автоматического переключения палитры, когда меняется форма/редактор. Т.е. нет формы, я не вижу какие компоненты стоят в среде. Что-то я не нашел, можно ли этого робота где-то зашибить насмерть опциями... :( Т.е. ощущение мрачноватое тем, что, с одной стороны, хотелось бы для новых проектов (Win32) брать D2006, все таки приятных в коде и компонентах мелочей и немелочей достаточно по сравнению с семеркой... Но все это гадит сама среда, в которой тогда прийдется работать (мега ИМХО) :(. Понравилось: направляющие при отравнивании контролов аки в Lazarus, токмо покруче ессно. Это просто здорово. Редактор кода понравился, особенно линия, по которой видно, где код отличается. Мелочь, но забойная для практики. -- Regards, Dmitriy Kovalenko http://metadataforge.com
Re: OFF: Delphi 2006, C++Builder 2006, C#Builder 2006 Trial now available for download
> от клоуны! кому он нужен теперь? К слову, я столкнулся с проблемой инсталляции BDS2006 на Win2003R2. Ошибки сыпет из RegAsm.exe (это из Net Framework) при установке. При установке апдейта также. BDS.exe, ессно, после этого также не стартует. На Win2003SP1 все хорошо. ЗЫ Вообще, мрачняк полный - затянули win32 в это притыренное нетовское IDE (мега ИМХО, конечно). Пришлось кое-что новенькое в D7 перетягивать путем из разряда заднепроходных :) Что за жизнь? Со слезами на глазах надеюсь, что новый владелец средств разработки вернет нам то Delphi, которое мы все любили. -- Regards, Dmitriy Kovalenko http://metadataforge.com
Re: Многопоточность и Embedded
> > Сейчас нельзя, а как потом будет - пока неизвестно (?). > > Ась? Embedded всегда позволял несколько коннектов к базе. Во, бл$, сказали рабочие. Я прибывал в полной уверенности (полном невединии получается), что только в Вулкане можно из тредов коннекты делать, а в фаере только один _вообще_ из приложения. -- Regards, Dmitriy Kovalenko http://metadataforge.com
Re: Завтра пятница
> http://caricatura.ru/black/korsun/593/ > http://caricatura.ru/strip/podvitski/26/ http://www.theregister.co.uk/2006/01/31/google_goes_desktop_linux/ -- Regards, Dmitriy Kovalenko http://metadataforge.com
Re: Проблема с fb2: не могу подключить базу
> у меня 2.0.0.12180, коннект нормальный. > instreg делал? У меня сейчас даже > после instreg от FB 1.5 двойка запускается > и работает через fbserver -a. К слову, про instreg в двойке... Он регистрит двойку в ветку полуторки в реестре. И сдается мне, что так не должно быть. Например, когда одновременно хочется работать с FB15 и FB20 как с приложениями и еще юзать gback от каждого соответсвенно (кстати, если не сделать instreg, то gback не работает, видать он в реестр заглядывает). -- Regards, Dmitriy Kovalenko http://metadataforge.com
INFO: Free CVS Hosting
Всем привет. Не корысти ради рекламы акаянной, а исключительно из могучей потенциальной полезности для каждого разработчика, рекомендую на досуге обратить внимание на сервис https://freepository.com. -- Regards, Dmitriy Kovalenko
Re: Проблема с конфой
> мой ридер глючит? Thunderbird глючитЪ. -- Regards, Dmitriy Kovalenko
JOB[Киев]: разработчик бд
Всем привет. Есть такое объявление. === Крупное издательство, работающее на фармацевтическом рынке, ищет разработчика баз данных для развития проекта по обработке некоторого потока информации. Основные требования: FIREBIRD - язык хранимых процедур и триггеров, Borland Delphi. Полный рабочий день. З/П от $700. Резюме присылать на адрес dmitriymorion.kiev.ua с темой "DEVELOPER.SQL". ===
Re: Вопрос по локализации сообщений Firebird
> До сего дня, здесь никого не красили. :) А это все Google. У меня Чередниченко оранжевый, а Бузаджи синий. -- Regards, Dmitriy Kovalenko
INFO[Киев]: Х.Борри "Firebird. Руководство разработчика"
Получил нотификацию от менеджера http://tk.com.ua/ (Техническая Книга на Петровке), что сегодня пришел сабж. Цена 74,82 грн. Можно заказать, привозят с 13:00 до 18:00 по Киеву бесплатно. -- Regards, Dmitriy Kovalenko http://metadataforge.com
Re: Архивы epsilon
Oleg Deribas wrote: > > Могу экспортировать в unix mailbox. > > Только вот надо ли? > ОК. Наверное не надо пока что. Привет. Могу залить полный архив конференции от 22.05.2001 по сей день к себе на хостинг (каналы хорошие, чтобы качать и траффик позволяет). В 7-zip получается 42 метра (база из Outlook Express 6). Повесим постоянный линк и нехай те, кому надо, себе отдельно и тихо качают. -- Regards, Dmitriy Kovalenko http://metadataforge.com
Re: test
Test from Firefox Тест через веб
