RE: Курсы валют
Привет! Позволю себе немного оффтопа, благо тема эта тут уже поднималась ;) Кто-то (уже не помню кто) обсуждал проблему закачивания курсов валют. Т.е. выкачивания их из инета, Банки обычно выкладывают курс валют в удобоваримой форме (txt,xls). Берешь Indy, пишешь лоадер из инета (тут вообще без инди можно обойтись). анализ и залив в базу данных. Примитивный парсер преобразующий данные из полеченного файлика в INSERT INTO (...) + IBEScript или ISQL или еще чего... Интересно - получилось ли у кого нибудь? 5 лет - полет нормальный. WBR,Dmitry Beloshistov AKA [-=BDS=-]
Re[2]: fb 2.1 ods
Hello DmitryLe, Monday, January 7, 2008, 4:00:30 PM, you wrote: Иные дебаты меня просто умиляють. :( Представим ситуацию: Вы написали програму и возможно даже ее продаете. Выпустили новую версию, изменили структуру БД Включили в инсталяцию пункт Изменение БД Написали что он обязателен для выполнения на той машине где стоить БД. После этого вам в супорт приходить письмо я поставл новую версию но такойто функционал не работаеть по тому что я не читал ваши хреновы инструкции. Ваши действия? Наши очень просты: 1. В БД пишеться версия продукта 2. При несовпадении отлуп - версии не совпадают. Даже если метаданные не поменялись. Все Аглы. :))) D Жаль. Даже очень жаль. Я считал это сильной стороной FB. Я с удовольствием послушаю доводы, простые чистые доводы. В чем сила брат? (с) Тема Дня: День пpопал не зpя! До не скорой встречи в аду, Maxmailto:[EMAIL PROTECTED]
Re: like escape
Hello, Attid! You wrote on Wed, 9 Jan 2008 11:00:59 +0300: Дополнительная наводка: документация к FB существует только в виде документации от IB6.0 + все релизноты последующих версий FB. Хотя думаю что like со времен IB6 не менялся. A спасибо конечно, но в том то и дело что я даже в ИБ6 ничего A по этому поводу не нашел. A так что либо его не посчитали достойным либо я не там искал =) Книжка. Мартин Грабер. SQL. Там точно про LIKE есть. -- Удач Alexander A. Venikov, Tobolsk, Russia
Re: Курсы валют
Спасибо! Решение, похоже, найдено
Re: like escape
Hello, Attid! Attid wrote: спасибо конечно, но в том то и дело что я даже в ИБ6 ничего по этому поводу не нашел. так что либо его не посчитали достойным либо я не там искал =) поиску подвергся поисковик по всем ФБ местам а также ib60releasenotes.pdf Firebird_v2.0.0.ReleaseNotes.pdf Firebird_v1.5.3.ReleaseNotes.pdf LANGREF.PDF а при чем тут release notes ??? ESCAPE для LIKE описан в embedsql.pdf - страница 118. с примерами. -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: fb 2.1 ods
Hello, Max! Max Rezanov wrote: Написали что он обязателен для выполнения на той машине где стоить БД. 1. В БД пишеться версия продукта в техникуме в нашей группе был парень, который не слышал мягких знаков. Т.е. в диктантах писал кон, ден, и т.д. У тебя, похоже, наобороть. :-) -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: FB 2.1.0.17698 RC1
On Wed, 02 Jan 2008 14:17:04 +0300, Attid [EMAIL PROTECTED] wrote: а интересно генерил ли кто идею сделать возможность создавать процедуры работающие вне транзакций как генераторы Только если с помощью UDF. На iBase даже где-то пример был, с мьютексами. Вот только надо ли... -- Сергей Смирнов.
Re: FB 2.1.0.17698 RC1
Á ÉÎÔÅÒÅÓÎÏ ÇÅÎÅÒÉÌ ÌÉ ËÔÏ ÉÄÅÀ ÓÄÅÌÁÔØ ×ÏÚÍÏÖÎÏÓÔØ ÓÏÚÄÁ×ÁÔØ ÐÒÏÃÅÄÕÒÙ ÒÁÂÏÔÁÀÝÉÅ ×ÎÅ ÔÒÁÎÚÁËÃÉÊ ËÁË ÇÅÎÅÒÁÔÏÒÙ ôÏÌØËÏ ÅÓÌÉ Ó ÐÏÍÏÝØÀ UDF. îÁ iBase ÄÁÖÅ ÇÄÅ-ÔÏ ÐÒÉÍÅÒ ÂÙÌ, Ó ÍØÀÔÅËÓÁÍÉ. ÷ÏÔ ÔÏÌØËÏ ÎÁÄÏ ÌÉ... ÄÁ ÍÎÅ ÐÏËÁ ×ÏÏÂÝÅ ÎÅ ÎÁÄÏ =) ÜÔÏ ÐÒÏÓÔÏ ÍÙÓÌØ =) ÈÏÔÑ Á×ÔÏÎÏÍÎÙÅ ÔÒÁÎÚÁËÃÉÉ ÜÔÏ ËÏÎÅÞÎÏ ÂÕÄÅÔ ÐÏÌÅÚÎÏ, ÈÏÔÑ Õ ÓÅÂÑ ÏÐÑÔØ ÖÅ ÎÅ ×ÉÖÕ ÓÍÙÓÌ × ÉÓÐÏÌØÚÏ×ÁÎÉÉ.
Re: like escape
ÐÏÉÓËÕ ÐÏÄ×ÅÒÇÓÑ ÐÏÉÓËÏ×ÉË ÐÏ ×ÓÅÍ æâ ÍÅÓÔÁÍ Á ÔÁËÖÅ ib60releasenotes.pdf Firebird_v2.0.0.ReleaseNotes.pdf Firebird_v1.5.3.ReleaseNotes.pdf LANGREF.PDF Á ÐÒÉ ÞÅÍ ÔÕÔ release notes ??? ÎÕ ÔÁÍ ÐÒÏÍÅÌØËÎÕÌ É LANGREF.PDF ESCAPE ÄÌÑ LIKE ÏÐÉÓÁÎ × embedsql.pdf - ÓÔÒÁÎÉÃÁ 118. Ó ÐÒÉÍÅÒÁÍÉ. ×ÏÔ × ÎÅÍ ÎÅ ÐÏÄÕÍÁÌ ÉÓËÁÔØ =) ÔÅÍ ÂÏÌÅÅ Ó ÎÁÄÐÉÓØÀ ÎÁ ÓÁÊÔÅ Embedded SQL Guide - ÔÏÌØËÏ ÅÓÌÉ ×Ù ÉÓÐÏÌØÚÕÅÔÅ GPRE. × ÏÂÝÅÍ ÓÔÒÁÎÎÏ ÜÔÏ ×ÓÅ =) ÎÏ ÓÐÁÓÉÂÏ ÚÁ ÏÔ×ÅÔ.
Re: like escape
Hello, Attid! Attid wrote: вот в нем не подумал искать =) тем более с надписью на сайте Embedded SQL Guide - только если вы используете GPRE. в общем странно это все =) но спасибо за ответ. пример хиловатый, но в любом случае соответствует стандарту. насчет Embedded SQL Guide - раньше эта каша называлась Programmers Guide. И там были примеры использования разных операторов, вперемешку SQL, DSQL, Embedded SQL. С этой книги Скляр сделал свой перевод. Но - т.к. в этом ProgGuide был embedded sql, который многих путал, я сделал соответствующую приписку. По уму надо было бы Embedded SQL Guide почикать, и примеры SQL/DSQL перенести в langref.pdf. собственно, я считаю что нужно немедленно начать клонировать langref.pdf в качестве доки по FB, пусть даже 100% копируя в начале. Синтаксис докрутить, описание переписать своими словами. Добавить примеры из embedsql.pdf и releasenotes. указать все странности и несовместимости со стандартом. -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: like escape
Dmitry Lendel wrote: собственно, я считаю что нужно немедленно начать клонировать langref.pdf в качестве доки по FB, пусть даже 100% копируя в начале. Синтаксис докрутить, описание переписать своими словами. Добавить примеры из embedsql.pdf и releasenotes. указать все странности и несовместимости со стандартом. Займешься? уже несколько месяцев как занялись (firebird-doc group). Роман
Re: like escape
ÓÏÂÓÔ×ÅÎÎÏ, Ñ ÓÞÉÔÁÀ ÞÔÏ ÎÕÖÎÏ ÎÅÍÅÄÌÅÎÎÏ ÎÁÞÁÔØ ËÌÏÎÉÒÏ×ÁÔØ langref.pdf × ËÁÞÅÓÔ×Å ÄÏËÉ ÐÏ FB, ÐÕÓÔØ ÄÁÖÅ 100% ËÏÐÉÒÕÑ × ÎÁÞÁÌÅ. óÉÎÔÁËÓÉÓ ÄÏËÒÕÔÉÔØ, ÏÐÉÓÁÎÉÅ ÐÅÒÅÐÉÓÁÔØ Ó×ÏÉÍÉ ÓÌÏ×ÁÍÉ. äÏÂÁ×ÉÔØ ÐÒÉÍÅÒÙ ÉÚ embedsql.pdf É releasenotes. ÕËÁÚÁÔØ ×ÓÅ ÓÔÒÁÎÎÏÓÔÉ É ÎÅÓÏ×ÍÅÓÔÉÍÏÓÔÉ ÓÏ ÓÔÁÎÄÁÒÔÏÍ. úÁÊÍÅÛØÓÑ? äÍÉÔÒÉÊ
Баг с уникальными индексами?
Всем привет, сто лет у вас не был :)
Делаю проект на Firebird 2.03, нашёл нечто похожее на баг. Если это
что-то новое, м.б. добавите в баг-лист?
Итаг. Задача: нужно резервировать столики в ночном клубе на
определённую дату. Если столик на эту дату уже занят - ругать
пользователя последними словами. Особенность - если столик на эту дату
ещё не занят, но как раз в данный момент резервируется другим
оператором - ругать пользователя другими словами. Короче нужно
показывать статус столиков на дату - свободен, занят,
резервируется и позволять резервировать только те, у которых статус
свободен.
Проблема: Dirty Read у нас нет и прочитать состояние столика до
коммита нельзя.
Решение: основываясь на том, что индексы работают вне контекста
транзакции, делаю проверку записи на уникальность ещё до её коммита.
Делаем таблицу (все операции проводил в IBExpert):
create table BoothReservation (
ID integer not null,
pDate date,
rBooth integer);
alter table BoothReservation
add constraint PK_BoothReservation
primary key (ID);
генератор и триггер для ID само собой разумеющиеся.
Накладываем ограничение уникальность на пару полей pDate, rBooth:
create unique index UNQ_BoothReservation
on BoothReservation (pDate, rBooth);
Запись о резервировании пишется в BoothReservation. По смыслу, если
записи для уникальной пары (pDate, rBooth) в BoothReservation нет -
столик свободен, если есть - занят. И если записи нет, но
проверочная вставка уникальной пары не проходит - столик
резервируется.
Речь идёт именно о проверке, когда юзеру нужно отобразить календарь
столиков с состояниями. Не то что бы мне нравилась проверка через
insert, но ничего умнее я не придумал.
Проверяем. Открываем 2 транзакции. В транзакции No.1 добавляем 2 записи:
insert into BoothReservation (pDate, rBooth) values ('9-JAN-2008', 5);
insert into BoothReservation (pDate, rBooth) values ('9-JAN-2008', 2);
commit;
В транзакции No.2 добавляем 1 запись:
insert into BoothReservation (pDate, rBooth) values ('9-JAN-2008', 2);
Ошибка:
Invalid insert or update value(s): object columns are
constrained - no 2 table rows can have duplicate column values.
attempt to store duplicate value (visible to active transactions) in
unique index UNQ_BOOTHRESERVATION.
Всё правильно. Откатываем транзакцию No.2.
Проверяем без коммита. В транзакции No.1:
insert into BoothReservation (pDate, rBooth) values ('9-JAN-2008', 1);
В транзакции No.2:
insert into BoothReservation (pDate, rBooth) values ('9-JAN-2008', 1);
Ошибка:
Unsuccessful execution caused by system error that does not preclude
successful execution of subsequent statements.
lock conflict on no wait transaction.
attempt to store duplicate value (visible to active transactions) in
unique index UNQ_BOOTHRESERVATION.
Тоже всё правильно. НЕ откатываем транзакцию No.2. В транзакции No.1
удаляем свежедобавленную, но не закоммиченую запись:
delete from BoothReservation where ID = 4;
НЕ коммитим транзакцию No.1. В транзакции No.2 пытаемся повторить вставку
той же записи:
insert into BoothReservation (pDate, rBooth) values ('9-JAN-2008', 1);
Ошибка:
Unsuccessful execution caused by system error that does not preclude
successful execution of subsequent statements.
lock conflict on no wait transaction.
attempt to store duplicate value (visible to active transactions) in
unique index UNQ_BOOTHRESERVATION.
А вот это уже неправильно. Запись удалена, но транзакция No.2 почему-то
до сих пор не вкурсе. По логике раз уж уникальный индекс
перестраивается при вставке до коммита, значит при удалении тоже
должен (если вообще в перестраивании индекса дело).
Пробуем дальше. Откатываем транзакцию No.2 и открываем её заново (я
понимаю, что это будет уже No.3, но для удобства обхожусь тем же
номером :) ). Опять пытаемся повторить вставку той же записи:
insert into BoothReservation (pDate, rBooth) values ('9-JAN-2008', 1);
Та же ошибка. То есть дело точно не в устаревшей транзакции No.2.
Коммитим транзакцию No.1 (там висело незакоммиченое добавление и
удаление, если помните ещё :) ). В транзакции No.2 пытаемся повторить
вставку той же записи:
insert into BoothReservation (pDate, rBooth) values ('9-JAN-2008', 1);
Успешно.
Однако такой расклад меня не устраивает - в приложении я не могу
коммитить транзакцию No.1 раньше времени. Грубо говоря пока пользователь
не нажал в диалоге кнопку Ok или Cancel - транзакция не завершена. И
пользователь может выбирать в диалоге любые столик/дату, и в момент
выбора производится удаление предыдущего выбора из BoothReservation и
вставка нового. И всё это должно быть видно другим транзакциям без
коммита.
Ладно, исходя из предположения, что индексы при удалении не сразу
перестраиваются делаем финт ушами - перед удалением записи в
транзакции No.1 проводим апдейт:
update BoothReservation set pDate = (CURRENT_DATE - 365*100 - ID)
where ID = 4;
delete from BoothReservation where ID = 4;
Т.е. тупо апдейтим поле, входящее в уникальный индекс каким-нибудь
левым значением - в данном случае делаем
Re: like escape
Hello, Dmitry! Dmitry Lendel wrote: собственно, я считаю что нужно немедленно начать клонировать langref.pdf в качестве доки по FB, пусть даже 100% копируя в начале. Синтаксис докрутить, описание переписать своими словами. Добавить примеры из embedsql.pdf и releasenotes. указать все странности и несовместимости со стандартом. Займешься? нет. исходная дока на английском должна быть. -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: Баг с уникальными индексами?
Игорь Бигдан ...
Всем привет, сто лет у вас не был :)
Делаю проект на Firebird 2.03, нашёл нечто похожее на баг. Если это
что-то новое, м.б. добавите в баг-лист?
Сначала разберёмся
Итаг. Задача: нужно резервировать столики в ночном клубе на
определённую дату. Если столик на эту дату уже занят - ругать
пользователя последними словами. Особенность - если столик на эту дату
ещё не занят, но как раз в данный момент резервируется другим
оператором - ругать пользователя другими словами. Короче нужно
показывать статус столиков на дату - свободен, занят,
резервируется и позволять резервировать только те, у которых статус
свободен.
Проблема: Dirty Read у нас нет и прочитать состояние столика до
коммита нельзя.
Решение: основываясь на том, что индексы работают вне контекста
транзакции, делаю проверку записи на уникальность ещё до её коммита.
Делаем таблицу (все операции проводил в IBExpert):
create table BoothReservation (
ID integer not null,
pDate date,
rBooth integer);
alter table BoothReservation
add constraint PK_BoothReservation
primary key (ID);
генератор и триггер для ID само собой разумеющиеся.
Накладываем ограничение уникальность на пару полей pDate, rBooth:
create unique index UNQ_BoothReservation
on BoothReservation (pDate, rBooth);
Запись о резервировании пишется в BoothReservation. По смыслу, если
записи для уникальной пары (pDate, rBooth) в BoothReservation нет -
столик свободен, если есть - занят. И если записи нет, но
проверочная вставка уникальной пары не проходит - столик
резервируется.
Речь идёт именно о проверке, когда юзеру нужно отобразить календарь
столиков с состояниями. Не то что бы мне нравилась проверка через
insert, но ничего умнее я не придумал.
Это единственный правильный способ захвата ресурса в конкурентной среде.
Других не придумано
Проверяем. Открываем 2 транзакции. В транзакции No.1 добавляем 2 записи:
insert into BoothReservation (pDate, rBooth) values ('9-JAN-2008', 5);
insert into BoothReservation (pDate, rBooth) values ('9-JAN-2008', 2);
commit;
В транзакции No.2 добавляем 1 запись:
insert into BoothReservation (pDate, rBooth) values ('9-JAN-2008', 2);
Ошибка:
Invalid insert or update value(s): object columns are
constrained - no 2 table rows can have duplicate column values.
attempt to store duplicate value (visible to active transactions) in
unique index UNQ_BOOTHRESERVATION.
Всё правильно. Откатываем транзакцию No.2.
Проверяем без коммита. В транзакции No.1:
insert into BoothReservation (pDate, rBooth) values ('9-JAN-2008', 1);
В транзакции No.2:
insert into BoothReservation (pDate, rBooth) values ('9-JAN-2008', 1);
Ошибка:
Unsuccessful execution caused by system error that does not preclude
successful execution of subsequent statements.
lock conflict on no wait transaction.
attempt to store duplicate value (visible to active transactions) in
unique index UNQ_BOOTHRESERVATION.
Тоже всё правильно. НЕ откатываем транзакцию No.2. В транзакции No.1
удаляем свежедобавленную, но не закоммиченую запись:
delete from BoothReservation where ID = 4;
НЕ коммитим транзакцию No.1. В транзакции No.2 пытаемся повторить вставку
той же записи:
insert into BoothReservation (pDate, rBooth) values ('9-JAN-2008', 1);
Ошибка:
Unsuccessful execution caused by system error that does not preclude
successful execution of subsequent statements.
lock conflict on no wait transaction.
attempt to store duplicate value (visible to active transactions) in
unique index UNQ_BOOTHRESERVATION.
А вот это уже неправильно. Запись удалена, но транзакция No.2 почему-то
до сих пор не вкурсе. По логике раз уж уникальный индекс
перестраивается при вставке до коммита, значит при удалении тоже
должен (если вообще в перестраивании индекса дело).
Это правильно. Запись не удалена, т.к. тр-ция не закоммичена. Перестраивание
индекса тут совершенно не при чём. Ты мог делать удаление под сейвпойнтом,
например, и откатить этот сейвпойнт - в результате как раз и будет нарушение
уникальности.
Пробуем дальше. Откатываем транзакцию No.2 и открываем её заново (я
понимаю, что это будет уже No.3, но для удобства обхожусь тем же
номером :) ). Опять пытаемся повторить вставку той же записи:
insert into BoothReservation (pDate, rBooth) values ('9-JAN-2008', 1);
Та же ошибка. То есть дело точно не в устаревшей транзакции No.2.
Конечно. У тебя есть версия записи с тем же ключём, созданная всё
ещё активной тр-цией No.1
Коммитим транзакцию No.1 (там висело незакоммиченое добавление и
удаление, если помните ещё :) ). В транзакции No.2 пытаемся повторить
вставку той же записи:
insert into BoothReservation (pDate, rBooth) values ('9-JAN-2008', 1);
Успешно.
Ещё бы :)
Однако такой расклад меня не устраивает - в приложении я не могу
коммитить транзакцию No.1 раньше времени. Грубо говоря пока пользователь
не нажал в диалоге кнопку Ok или Cancel - транзакция не завершена. И
Ща тебя тут научат уму-разуму
пользователь может выбирать в диалоге любые столик/дату, и в
Re: like escape
Hello, Roman! Roman Rokytskyy wrote: Займешься? уже несколько месяцев как занялись (firebird-doc group). еле нашел. на офсайте по-моему нет ссылки http://www.destructor.de/firebird/refdoc/ как подключиться - тут: http://www.destructor.de/firebird/refdoc/1345.htm p.s. замУтно, через базу... но хоть так. -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: like escape
ÓÏÂÓÔ×ÅÎÎÏ, Ñ ÓÞÉÔÁÀ ÞÔÏ ÎÕÖÎÏ ÎÅÍÅÄÌÅÎÎÏ ÎÁÞÁÔØ ËÌÏÎÉÒÏ×ÁÔØ langref.pdf × ËÁÞÅÓÔ×Å ÄÏËÉ ÐÏ FB, ÐÕÓÔØ ÄÁÖÅ 100% ËÏÐÉÒÕÑ × ÎÁÞÁÌÅ. óÉÎÔÁËÓÉÓ ÄÏËÒÕÔÉÔØ, ÏÐÉÓÁÎÉÅ ÐÅÒÅÐÉÓÁÔØ Ó×ÏÉÍÉ ÓÌÏ×ÁÍÉ. äÏÂÁ×ÉÔØ ÐÒÉÍÅÒÙ ÉÚ embedsql.pdf É releasenotes. ÕËÁÚÁÔØ ×ÓÅ ÓÔÒÁÎÎÏÓÔÉ É ÎÅÓÏ×ÍÅÓÔÉÍÏÓÔÉ ÓÏ ÓÔÁÎÄÁÒÔÏÍ. úÁÊÍÅÛØÓÑ? ÎÅÔ. ÉÓÈÏÄÎÁÑ ÄÏËÁ ÎÁ ÁÎÇÌÉÊÓËÏÍ ÄÏÌÖÎÁ ÂÙÔØ. Á Ñ ×ÓÅ ÅÝÅ ÇÎÕ Ó×ÏÀ ÌÉÎÉÀ =) http://firebird.name/doku.php?id=like
Re: Баг с уникальными индексами?
Vlad Khorsun ... Ладно, исходя из предположения, что индексы при удалении не сразу перестраиваются делаем финт ушами - перед удалением записи в транзакции No.1 проводим апдейт: update BoothReservation set pDate = (CURRENT_DATE - 365*100 - ID) where ID = 4; delete from BoothReservation where ID = 4; Т.е. тупо апдейтим поле, входящее в уникальный индекс каким-нибудь левым значением - в данном случае делаем минус 100 лет, минус ID (чтобы разные записи не пересекались). Работает. Теперь вставка удалённой записи в транзакции No.2 проходит без коммита транзакции No.1. Что и требовалось получить. Не должно это работать. Проверю. Работает. А с сейвпойнтом не работает. Так что шансов нарушить уникальность вроде бы нет. Вот краткое объяснение на пальцах того, что там происходит : Вариант insert + update в одной тр-ции : внутри движка по окончанию update'а идёт очистка сейвпойнта самого update'а и его данные переносятся на предыдущий сейвпойнт. Это сейвпойнт insert'а, который эту запись уже видел. Посему ключ, вставленный insert'ом удаляется немедленно (иначе мы его уже никогда не найдём). Вариант insert + savepoint + update в одной тр-ции : внутри движка по окончанию update'а идёт очистка сейвпойнта самого update'а и его данные переносятся на предыдущий сейвпойнт. Это юзерский сейвпойнт, который эту запись не видел. Посему ключ, вставленный insert'ом остаётся на месте и будет удалён позже, при коммите юзерского сейвпойнта. Влад
Re: Баг с уникальными индексами?
Игорь Бигдан ... Аргумент про savepoint понял, логично. Но фокус с апдейтом работает уже второй день. И где же баг, если не в FB? :) В чём баг-то ? Уникальность не нарушается. Всё остальное - домыслы. -- Хорсун Влад
Re: Баг с уникальными индексами?
Аргумент про savepoint понял, логично. Но фокус с апдейтом работает уже второй день. И где же баг, если не в FB? :)
Re: like escape
Attid wrote: а я все еще гну свою линию =) http://firebird.name/doku.php?id=like Ты бы лучше хоть разок хоть одну книжку по SQL вообще почитал. Like в доке подробно не разжеван именно потому, что на 100% соответсвует стандарту, который считается общеизвестным для мало-мальски общеобразованных людей. -- Regards. Ded.
Re: Баг с уникальными индексами?
Всё логично, спасибо. Я как-то не привык мыслить сейвпоинтами для каждой операции, вот и не увидел сучность бытия. Бум учицца. Раз это не баг, значит можно оставить решение без переделок.
libjaybird21.so
Хелло! А почему в cvs-репозитарии нет правил сборки libjaybird21.so? Для Windows есть проект на VS, а для linux-платформы нет. Хотелось бы посмотреть на версионный скрипт, если возможно. Максим
Re: libjaybird21.so
А почему в cvs-репозитарии нет правил сборки libjaybird21.so? Для Windows есть проект на VS, а для linux-платформы нет. Хотелось бы посмотреть на версионный скрипт, если возможно. Есть, только он Ant-ом собирается для всех платформ - build_native.xml называется. А проект для VS - издержки производства. Роман
Re: libjaybird21.so
ок. Спасибо за помощь! Максим
Re: fb 2.1 ods
Kovalenko Dmitry [EMAIL PROTECTED] сообщил/сообщила в новостях следующее: news:[EMAIL PROTECTED] Не умеет, так не умеет. Закрываем это флейм. Ну почему флейм? Нормальная тема :) Я вот, к примеру, задумался - а почему мой репликатор может работать с пакетами старой структуры. А создавать может только пакеты с новой :) Да что бы не провоцировать продолжение порождения гуана :)) Вот так всегда: сначала порождаем гуано, а потом боремся с его порождением... :)
Re: непонятка
Hello, Nikolay! You wrote on Thu, 10 Jan 2008 01:12:22 +0200: N В проекте есть мастер таблица users с именами пользователей N и паролями.Есть несколько подчиненных таблиц, связанных с N users по FK Недавно позвонил клиент с другого города и N пожаловался что в users исчезла одна учетная запись. TL On. Удалили? -- Удач Alexander A. Venikov, Tobolsk, Russia
Re: Баг с уникальными индексами?
А может стоит использовать Select For Update With Lock в тот момент когда идет процесс резервирования? With b/r. Gleb.
Re: like escape
ôÙ ÂÙ ÌÕÞÛÅ ÈÏÔØ ÒÁÚÏË ÈÏÔØ ÏÄÎÕ ËÎÉÖËÕ ÐÏ SQL ×ÏÏÂÝÅ ÐÏÞÉÔÁÌ. Like × ÄÏËÅ ÐÏÄÒÏÂÎÏ ÎÅ ÒÁÚÖÅ×ÁÎ ÉÍÅÎÎÏ ÐÏÔÏÍÕ, ÞÔÏ ÎÁ 100% ÓÏÏÔ×ÅÔÓ×ÕÅÔ ÓÔÁÎÄÁÒÔÕ, ËÏÔÏÒÙÊ ÓÞÉÔÁÅÔÓÑ ÏÂÝÅÉÚ×ÅÓÔÎÙÍ ÄÌÑ ÍÁÌÏ-ÍÁÌØÓËÉ ÏÂÝÅÏÂÒÁÚÏ×ÁÎÎÙÈ ÌÀÄÅÊ. ÄÁ ÞÉÔÁÌ Ñ ËÎÉÖËÕ É ÎÅ ÏÄÎÕ, É ÓÔÁÎÄÁÒÔ ÎÅÔ ÎÅÔ ÞÉÔÁÀ, ÐÒÏÓÔÏ ÍÁÌÏ ÌÉ ÂÕÄÕÔ ËÁËÉÅ ÏÓÏÂÅÎÏÓÔÉ.ÎÅ ÕÖÅÌÉ ÔÙ ÄÕÍÁÅÛØ Ñ × ÐÅÒ×ÙÅ ÐÏÌØÚÏ×ÁÌÓÑ LIKE ? ÐÏÌØÚÏ×ÁÌÓÑ É ÏÞÅÎØ ÄÁ×ÎÏ É ÎÅ ÔÏÌØËÏ × ÐÔÉÞËÅ, ÐÒÏÓÔÏ ÐÏÄ ÐÔÉÞËÕ Ñ ÓÔÁÒÁÀÓØ ÐÏ ÔÏÊ ÄÏËÅ ÞÔÏ ÅÓÔØ ÔÁË ËÁË ÎÁ ÉÚÕÞÅÎÉÉÅ ÉÓÈÏÄÎÉËÏ× ÕÍÁ ÎÅ È×ÁÔÉÔ =) ÔÁË ÞÔÏ ×ÏÔ ÔÁË =)
