Re: Немного флейма. Транзакции

[Dmitri Kuzmenko]

Hello, Serge!

Serge Buzadzhy wrote:


БДЕ по моему дофетчивало втихую.


когда как.
www.ibase.ru/devinfo/bde.htm

Наша песня хороша - начинай сначала :) Обсуждали ужо. Хочешь - обсудм 
еще раз. Недофетченный запрос, чего с ним делать при закрытии 
транзакции? Дофетчивать втихаря перед закрытием? Нехорошо. Оставлять 
недофетченным тоже плохо. Оба варианта плохи еще тем что девелопер 
вообще может не заметить, что что-то делается без его ведома. Проблема 
вообще может всплыть, когда девелопер прогу юзеру отдал.  Посему датасет 
 и закрываем, уж этого-то не заметить нельзя, так что девелопер вынужден 
решать сию проблему вовремя... а не тогда когда она вдруг всплывет.


спасибо, это я тоже помню, но из первых рук получилось максимально полно.

--
Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34

Re: Немного флейма. Транзакции

[Serge Buzadzhy]

Alexey Popov пишет:



Serge Buzadzhy wrote:

транзакции? Дофетчивать втихаря перед закрытием? Нехорошо. Оставлять 
недофетченным тоже плохо. Оба варианта плохи еще тем что девелопер 
вообще может не заметить, что что-то делается без его ведома. Проблема 
вообще может всплыть, когда девелопер прогу юзеру отдал.  Посему 
датасет  и закрываем, уж этого-то не заметить нельзя, так что 
девелопер вынужден решать сию проблему вовремя... а не тогда когда она 
вдруг всплывет.


Надо просто бросать исключение при попытке последующего фетча закрытого 
датасета.




И вообще я не понимаю чем исключение, которое будет появляться 
достаточно случайным образом
лучше чем стабильная реакция. Стабильную реакцию можно учесть и обойти, 
тем более что стандартные пути обхода

предлагаются.

Re: Немного флейма. Транзакции

[Vlad Khorsun]

"Serge Buzadzhy" ...


Vlad Khorsun пишет:


"Dmitri Kuzmenko" ...


тут ведь еще есть вот какой момент. Любовь к "параллельным" транзакциям
пошла из-за того, что BDE


БДЕ по моему дофетчивало втихую.


   Угу. Но БДЕ писалось во времена, когда клиент-сервер только начинал входить
в массы и толком было не понятно как с ним работать. Т.е. теоритически все всё 
знали
и понимали, а вот практических навыков (по крайней мере в Б) не было.


>>а потом и FreeIBComponents, и IBX/FIBPlus

убивают кэш в датасетах,


>>т.е. "закрывают запросы".
Ну... запрос закрыть это один вопрос. Второй вопрос это кэш в датасетах. Запрос закрыть необходимо. Он просто перестает быть 
валидным при закрытии транзакции в рамках которой был открыт. Что собственно и понятно.


   А при чём тут мои локальные, с таким трудом отфетченные, данные ?


   Знать бы ещё - нафига они это делают...


Наша песня хороша - начинай сначала :) Обсуждали ужо.


   Значит я пропустил тот раз ;)


Хочешь - обсудм еще раз.


   Как скажешь ;) Скажу сразу - это камень не в твой огород, а скорее в огород
Грегори


Недофетченный запрос, чего с ним делать при закрытии транзакции?


   А что - надо что-то делать ?


Дофетчивать втихаря перед закрытием? Нехорошо. Оставлять недофетченным тоже 
плохо.


   Чем ? Тем что бедненький кодер испугается ошибки, которую выдаст
злобный сервер при попытке фетча из закрытого курсора ? Ай, как его жалко


Оба варианта плохи еще тем что девелопер вообще может не заметить, что что-то 
делается без его ведома.


   А вот не надо ничего делать без его ведома. Не надо. Это так просто :)

Проблема вообще может всплыть, когда девелопер прогу юзеру отдал.  Посему датасет и закрываем, уж этого-то не заметить нельзя, так 
что девелопер вынужден решать сию проблему вовремя... а не тогда когда она вдруг всплывет.


   Конечно - мы же лучше знаем, что девелоперу нужно на самом деле...

   Конкретно эту проблему считаю высосанной их пальца и навязанной множеству
кодеров, которые просто слепо верят в инструмент и не задумываются причинах.

ЗЫ. Кстати в FIBPlus ( а может и в ИБХ) если датасет в режиме CachedUpdates  то при закрытии транзакции, датасет все-таки не 
закрывается, а дофетчивается.


   Меня это всё не волнует лет этак 8-9 - с тех пор как я пользую CDS и не имею
проблем с нижележащими уровнями вообще :)

--
Хорсун Влад 

Re: ����

[Dmitry Lendel]

îÅÔ. äÒÏ×Á ÒÏÄÎÙÅ.
ðÒÉËÏÌ ×ÏÔ × ÞÅÍ.

îÁ ÓÅÒ×ÅÒÅ Ä×Å ÓÅÔÅ×ÙÅ ËÁÒÔÙ. ïÄÎÁ ÄÌÑ ÌÏËÁÌËÉ, ×ÔÏÒÁÑ ÄÌÑ ÉÎÅÔÁ.
÷ ÐÅÒ×ÏÍ ÓÌÕÞÁÅ ÐÒÏÐÁÄÁÅÔ ÉÎÔÒÅÎÅÔ, Á Firebird ÒÁÂÏÔÁÅÔ.
÷Ï ×ÔÏÒÏÍ Ó ÔÏÞÎÏÓÔØÀ ÎÁÏÂÏÒÏÔ. éÎÅÔ ÒÁÂÏÔÁÅÔ, Á Ó×ÑÚØ Ó Firebird ÐÒÏÐÁÄÁÅÔ.
åÓÔØ ÐÏÄÏÚÏÅÎÉÅ, ÞÔÏ ÅÓÌÉ ÐÏÍÅÎÑÔØ ÓÅÔÅ×ÙÅ ËÁÒÔÙ ÍÅÓÔÁÍÉ, ÔÏ ÂÕÄÅÔ ÔÏÖÅ, ÞÔÏ
É × ÐÅÒ×ÏÍ ÓÌÕÞÁÅ.

ïó ÌÅÇÁÌØÎÁÑ É ÐÒÏÐÁÔÞÅÎÎÁÑ. îÁ ×ÙÈÏÄÎÙÅ ÐÏÊÄÕ ÓÍÏÔÒÅÔØ.
äÍÉÔÒÉÊ

Re: Точки вместо букв при cast(blob as varchar())

[Олег Короткий]

On 14 сент, 09:34, Олег Короткий <[EMAIL PROTECTED]> wrote:
> Доброго времени суток!
> Собственно, сабж. Версия 2.1.0.16200. База создана с кодировкой
> win1251, подключался и с ней, и с NONE, разницы нет. Пытаюсь сделать
> select cast(list(some_field) as varchar(100)) from some_table,
> корректно отображаются лишь пробелы, буквы же - в виде точек. Такая
> вот заморочка

Re: Немного флейма. Транзакции

[Alexander A. Venikov]

Hello, Alexey!
You wrote  on Wed, 19 Sep 2007 12:40:13 +0400:

>> 1. В чем именно удобство стартовать много транзакций в одном соединении?
AP> Удобно при работе с многими формами. В каждой форме своя
AP> транзакция и они совершенно изолированы друг от друга.
AP> В противном случае надо как то извращаться что бы работа
AP> в разных формах/модулях не противоречила друг другу.
Ты немного не понял. С этой точки зрения ничто не мешает использовать в каждой 
форме отдельное подключение. Почему это плохо - уже ответили.

--
Удач
Alexander A. Venikov, Tobolsk, Russia 

Re: Re[2]: OFF: ������ � �����

[Dmitry Lendel]

> ðÒÏÇÒÁÍÍÉÓÔÙ ÐØÀÔ ÐÉ×Ï, Á ÎÅ ËÕÒÑÔ :-)
áÇÁ, Á ÐÏÔÏÍ ÚÁ ÒÕÌØ É ÄÏÍÏÊ... :-)))
äÍÉÔÒÉÊ

Re: Немного флейма. Транзакции

[Alexey Popov]

Serge Buzadzhy wrote:

И вообще я не понимаю чем исключение, которое будет появляться 
достаточно случайным образом
лучше чем стабильная реакция. Стабильную реакцию можно учесть и обойти, 
тем более что стандартные пути обхода

предлагаются.


Почему случайным? Где стабильная реакция? Сейчас запрос просто закрывается,
что само по себе тихо, незаметно и может привести с странным глюкам.
При выбросе исключения автоматически выскочит мессадж бокс с точной 
причиной. Юзер сразу отпинает девелопера без всяких стуков в подвале.




--
--- Home Page http://ok.novgorod.net/ap ---

Re: Точки вместо букв при cast(blob as varchar())

[Олег Короткий]

Эээ, пардон, за очепятку
Отвечаю сам на свой вопрос, вдруг кому пригодится
Правильно делать так:select cast(cast(substring(list(some_field) from
1 for 100) as blob sub_type text) as varchar(100)) from some_table

Re: ������� ������. ���������

[Nikolay Ponomarenko]

Hello, Ded!
You wrote  on Thu, 20 Sep 2007 00:00:20 +0400:

 D> Идём читать букварь про одну транзакцию на коннект в многопоточных
 D> приложениях, о начальник транспортного цеха ;)

Я об этом и говорю.

 >> Остается только случаи необходимости именно _транзакционности_ некоторых
 7>> псевдо-параллельных действий, так?

 D> Нет (или может и да, что ты имел в виду под псевдо, я не въехал),
 D> остаются вопросы:
  [...]
 D> Это просто первое что пришло в голову из того, что мы имеем. Это как
 D> щастье - понимаем, что оно было, только когда его уже нет :)

Ха, удобство, да и вообще возможность, спасибо версионности, использования 
длинных
транзакций в клиентских формах конечно неоспоримо. Но по хорошему ведь, 
использование
транзакций для таких вещей есть хак и удешевление разработки - и полноценные, 
скажем так
кешированные, редакторы документов и т.п., с короткими транзакциями - лучше и 
правильнее
с точки зрения консерватории? Вот и Дима с Владом о чем-то похожем, в соседней 
ветке.

Но это конечно заявление спорное, и предыдущий мой пост больше относился к 
серверным
вещам - глядя на свои предыдущие разработки - несколько транзакций хоть и 
привычно и
удобно, хотя бы и заданием разных уровней, но на практике вполне безболезненно 
сводятся к
одной транзакции в коннекте. Вернее только так и работают, учитывая 
многопоточность.

Хотя, конечно, когда я в впервые столкнулся с однотранзакционным подходом в 
ФБ-шной
библиотеке Ruby - целостная, доселе, картина мира дала трещину :))

 D> ЗЫ Материться в приличном обществе без веской на то причины не следует
 D> даже в нецитируемой подписи.

Приношу свои извинения участникам, не обратил внимания, увлеченный темой
беседы :)

--
-=Чисто прибранная квартира - признак неисправного компьютера.=-
With best regards,  Nikolay Ponomarenko

Re: Среда

[Alex Cherednichenko]

Привет, Alexander!
Вы пишешь к Kovalenko Dmitry 20 сентября 2007:

 BA>> http://news.gismeteo.ru/?newsitem=63325883006
 KD>> Алексей, блин . бугагага.
 AAV> Интересно, как он указал в иске место жительства оветчика? :)

Без
Определённого
Места
Жительства...

-- 
With best regards, Alex Cherednichenko.

Re: Немного флейма. Транзакции

[Alex Cherednichenko]

Привет, Vlad!
Вы пишешь  20 сентября 2007:

[Sorry, skipped] 
 VK> А вот не надо ничего делать без его ведома. Не надо. Это так просто :)

Аааа!!
Ты знал!!!
Ты знал :)))

-- 
With best regards, Alex Cherednichenko.

Re: Немного флейма. Транзакции

[Ded]

Vlad Khorsun wrote:


   Меня это всё не волнует лет этак 8-9 - с тех пор как я пользую CDS и 
не имею

проблем с нижележащими уровнями вообще :)


   CDS я тоже лублу, вот только оно хорошо когда примерно знаешь 
сколько ему там фетчить. А то ведь может и не войти в крынку-то. А 
парцайками тягать муторно. Правда меня это тоже отродясь не волновало, 
ибо с малолетства разделял пишущие и читающие транзакции. Лично мне 
текущее поведение внучков Грегори представляется более логичным и 
простым в использовании чорным ящиком, нежели борьба с недофетченными 
курсорами, невалидными дбкеями и, пожалуй, для человека неискушённого, 
отсутствием конфликтов модификации там, где они должны быть. Может, 
конечно, дело привычки...


--
Regards. Ded.

Re: Немного флейма. Транзакции

[Serge Buzadzhy]

Alexey Popov пишет:


Serge Buzadzhy wrote:

И вообще я не понимаю чем исключение, которое будет появляться 
достаточно случайным образом
лучше чем стабильная реакция. Стабильную реакцию можно учесть и 
обойти, тем более что стандартные пути обхода

предлагаются.


Почему случайным? 
Потому что возникновение предполагаемого эксепшна зависит от случайных 
факторов.


1. Много или мало записей в запросе (это для одного и того же запроса 
меняется во времени)

2. Успел юзер отфетчить  записи или нет до того как кто-то вызвал коммит.

Т.е.  тестируя одну и ту же форму в чуть-чуть разных условиях ты будешь 
или получать или не получать этот эксепшн.



Где стабильная реакция? Сейчас запрос просто закрывается,

Стабильно закрывается.

что само по себе тихо, незаметно и может привести с странным глюкам.

Тихо? То-то  это обнаруживается сразу же всеми кто первый раз пробует.
насчет "незаметно" ... очень трудно не заметить что грид перестал 
показывать данные сразу же после коммита.  Причем стабильно - есть 
коммит - данные исчезли.

Re: Среда

[Ded]

Boulitchev Aleksey wrote:



http://news.gismeteo.ru/?newsitem=63325883006


   Вообще-то у меня к этому старцу тоже есть претензии. В постановке 
сделаны ряд фундаментальных ошибок, что, как всегда повлекло массу 
проктологических решений в реализации. Результат ну очень далёк от 
совершенства. По-хорошему ему надо было снести к е-ням эту систему 
миллионов 300 лет назад и сделать новую с нуля, учтя и ошибки и 
полученный опыт. Всё лень матушка. Но это сделать в общем никогда не поздно.


--
Regards. Ded.

Re: Немного флейма. Транзакции

[Vlad Khorsun]

"Ded" ...


Vlad Khorsun wrote:


   Меня это всё не волнует лет этак 8-9 - с тех пор как я пользую CDS и не имею
проблем с нижележащими уровнями вообще :)


   CDS я тоже лублу, вот только оно хорошо когда примерно знаешь сколько ему там фетчить. А то ведь может и не войти в крынку-то. 
А


   Может у мну (с) крынка резиновая, но никогда на это не напарывался.
Может я не тяну сотни тысяч на клиента (отчёты делаются другими ср-вами) ?
Единицы и, возможно, десятки тысяч пролетают без заметных проблем (редко,
но иногда бывает и такое). Это при том, что есть и более быстрые in-memory
таблицы, чем CDS. Да и менее глючные тоже, надеюсь, есть :)

парцайками тягать муторно. Правда меня это тоже отродясь не волновало, ибо с малолетства разделял пишущие и читающие транзакции. 
Лично мне


   У меня это тоже две разные тр-ции. Но только для того, чтобы дать им 
(возможно)
разный набор параметров, а не для обхода проблемы закрытия датасетов.

текущее поведение внучков Грегори представляется более логичным и простым в использовании чорным ящиком, нежели борьба с 
недофетченными курсорами, невалидными дбкеями и, пожалуй, для человека неискушённого, отсутствием конфликтов модификации там, где 
они должны быть. Может, конечно, дело привычки...


   Поведение _может_ быть настраиваемым, но не _должно_ быть железобетонно-
непробиваемым в стиле : "ты туда не ходи, ты сюда ходи... и только сюда"

   Я, с точки зрения пользователя компонент, не вижу ничего логичного и 
простого в
закрытии всех датасетов по окончании тр-ции. Наооброт - это приводит в 
недоумение
и заставляет _бороться_ с компонентами\сервером вместо решения моих собственных
прикладных задач.

--
Хорсун Влад 

Re: Немного флейма. Транзакции

[Serge Buzadzhy]

Vlad Khorsun пишет:




>>а потом и FreeIBComponents, и IBX/FIBPlus

убивают кэш в датасетах,


>>т.е. "закрывают запросы".
Ну... запрос закрыть это один вопрос. Второй вопрос это кэш в 
датасетах. Запрос закрыть необходимо. Он просто перестает быть 
валидным при закрытии транзакции в рамках которой был открыт. Что 
собственно и понятно.


   А при чём тут мои локальные, с таким трудом отфетченные, данные ?


Дык включаем CachedUpdates  и можем вообще коннект обрубить не то что 
транзакцию закрыть. :) С трудом отфетченные данные остаются на месте.

Хочешь - обсудм еще раз.


   Как скажешь ;) Скажу сразу - это камень не в твой огород, а скорее в 
огород

Грегори


Мой огород давно не боится камней. :)



Недофетченный запрос, чего с ним делать при закрытии транзакции?


   А что - надо что-то делать ?

Дофетчивать втихаря перед закрытием? Нехорошо. Оставлять недофетченным 
тоже плохо.


   Чем ? Тем что бедненький кодер испугается ошибки, которую выдаст
злобный сервер при попытке фетча из закрытого курсора ? Ай, как его 
жалко

Мне больше жалко не его, а себя обычно. :)



Оба варианта плохи еще тем что девелопер вообще может не заметить, что 
что-то делается без его ведома.


   А вот не надо ничего делать без его ведома. Не надо. Это так просто :)
Это идеал. Недостижимый. Но по крайней мере если что-то делаешь без его 
ведома, нужно чтоб он сразу же видел что произошло и собственно понял 
причину по которой это произошло. Закрыть кэш - это как раз из этой 
серии. Сразу же и всегда видно, причина выясняется немедленно.




Проблема вообще может всплыть, когда девелопер прогу юзеру отдал.  
Посему датасет и закрываем, уж этого-то не заметить нельзя, так что 
девелопер вынужден решать сию проблему вовремя... а не тогда когда она 
вдруг всплывет.


   Конечно - мы же лучше знаем, что девелоперу нужно на самом деле...


Девелоперу нужно чтоб он мог реализовать свои собственные извращения и 
ему хватало для этого средств.




   Конкретно эту проблему считаю высосанной их пальца 
Я тоже. По причине того что проблема сразу видна и легко решается одним 
из трех способов.



и навязанной  множеству
кодеров, которые просто слепо верят в инструмент и не задумываются 
причинах.


ЗЫ. Кстати в FIBPlus ( а может и в ИБХ) если датасет в режиме 
CachedUpdates  то при закрытии транзакции, датасет все-таки не 
закрывается, а дофетчивается.


   Меня это всё не волнует лет этак 8-9 - с тех пор как я пользую CDS и 
не имею

проблем с нижележащими уровнями вообще :)


Я про себя скажу просто. Что бы я не делал в этой ситуации - меня все 
равно будут бить.  :) Или за то что закрываю кэш, или за то что вдруг 
эксепшны выскакивают, или что дофетчиваю или что не дофетчиваю. 
Собственно разницы никакой, бить все равно будут, не одни так другие. :)
Поэтому все остается как есть. По крайней мере выходы из ситуации 
отработаны и как отгавкиваться я 

Re: Немного флейма. Транзакции

[Vlad Khorsun]

Я про себя скажу просто. Что бы я не делал в этой ситуации - меня все равно 
будут бить.  :)


   Я знал, что ты знал :)

Или за то что закрываю кэш, или за то что вдруг эксепшны выскакивают, или что дофетчиваю или что не дофетчиваю. Собственно разницы 
никакой, бить все равно будут, не одни так другие. :)


   Согласен...

Поэтому все остается как есть. По крайней мере выходы из ситуации отработаны и как отгавкиваться я тоже знаю, да и "проблема" 
давно уже никому не мешает. :)


   ...потому и не предлагаю ничего менять или устраивать революции :)
Просто тема навеяла :)

   И я так и не узнал - нафига Грег сбрил, тьфу, закрыл датасеты ;)

--
Хорсун Влад 

Re: Немного флейма. Транзакции

[Ded]

Vlad Khorsun wrote:


   Может у мну (с) крынка резиновая, но никогда на это не напарывался.
Может я не тяну сотни тысяч на клиента (отчёты делаются другими ср-вами) ?
Единицы и, возможно, десятки тысяч пролетают без заметных проблем (редко,
но иногда бывает и такое).


   Десятки тысяч не проблема. У меня в филиальской briefcase справочной 
подсистеме десятками и тягается. С тех пор, как наладил репликацию 
изменией в базовых справочниках и сборку визуализации на месте из 
засасываемых оперативных числовых данных и названий в локальной базе, 
вполне шустренько так летает. А вот спервоначалу, когда отправлял туда 
резалтсет джойна из центра, в какой-нить Тюмени на модеме минут 40 могло 
грузиться. То есть, к работе с кеширующими фулл фетч датасетами в общем 
случае надо технологически подходить не как к клиент-серверу. А это не 
всегда хорошо. Про работу с миллионными архивами, которые в 
клиент-сервере до конца вообще практически никогда не дофетчиваются, я 
уж молчу. И никаких специальных приседаний с IBX/FIBPlus для этого не 
надо, технология на это и заточена. Наоборот, надо приседать, когда 
нужны отступления от этой технологии. Мы с тобой приседаем при помощи 
CDS, а Серж строит настраиваемые гибриды с локальными 
сортировками-фильтрациями. Мне кажется, что правильней иметь и молоток и 
гвоздодёр отдельно и хвататься за то, что нужно в конкретный момент.



парцайками тягать муторно. Правда меня это тоже отродясь не волновало, 
ибо с малолетства разделял пишущие и читающие транзакции. Лично мне



   У меня это тоже две разные тр-ции. Но только для того, чтобы дать им 
(возможно)

разный набор параметров, а не для обхода проблемы закрытия датасетов.


   У меня этой проблемы вообще никогда не было. Основное чтение в 
единой транзакции по умолчанию r_c read, открывающейся на запуске 
приложения и закрывающейся на выгрузке, запись в коротких по месту 
снапшотах, с прдварительным рефрешем в них именно модифицируемых данных, 
если нужно. И фсё.


текущее поведение внучков Грегори представляется более логичным и 
простым в использовании чорным ящиком, нежели борьба с недофетченными 
курсорами, невалидными дбкеями и, пожалуй, для человека неискушённого, 
отсутствием конфликтов модификации там, где они должны быть. Может, 
конечно, дело привычки...



   Поведение _может_ быть настраиваемым, но не _должно_ быть железобетонно-
непробиваемым в стиле : "ты туда не ходи, ты сюда ходи... и только сюда"


   См. выше про молоток и гвоздодёр :)

   Я, с точки зрения пользователя компонент, не вижу ничего логичного и 
простого в
закрытии всех датасетов по окончании тр-ции. Наооброт - это приводит в 
недоумение
и заставляет _бороться_ с компонентами\сервером вместо решения моих 
собственных

прикладных задач.


  Не вижу в упор борьбы, если разделять транзакции. И Серж в плюсах это 
сделал, и Алекс для нас в IBX, причём ещё более радикально, можем на 
каждый ...SQL отдельную закатать. А раньше мы просто не пользовались 
технологией Edit-Post, а выполняли модификации автономными запросами. Да 
и сейчас преимущественно так.


--
Regards. Ded.

Re: Среда

[Boulitchev Aleksey]

проктологических решений в реализации. Результат ну очень далёк от 
совершенства. По-хорошему ему надо было снести к е-ням эту систему 
миллионов 300 лет назад и сделать новую с нуля, учтя и ошибки и полученный 
опыт. Всё лень матушка. Но это сделать в общем никогда не поздно.


сейчас точно не первая версия, и даже не вторая

--
Булычев Алексей
http://www.stella-npf.ru

Off: FB + ASP.NET

[Константин]

Hi, многоуважаемый All!

Недавно, насмотревшись "красот" ASP.NET ...
Решил дай поколупаюсь, попробую ...
И тут такое началось ... :(

  1) .NET оказывается изначально должно хостится на IIS :( ...
  2) ладно люди подсказали есть mono ...
  3) Mono на Debian стал, но не стал на Windows :( ...

   Особенно меня расстроил 3 пункт, т.к. для проб - существующий
   хостинг не годится (админ пока против).
   Надо бы в локале сначала ..., ан нет - не получается ...

PS: и самое противное ... неужели кроме ADO.NET ничего не для
коннекта IB/FB базам ? ...

PPS: Вот я думаю а мож ну его нафиг ? Обойдусь PHP, по старинке ...
 Хотя в ASP.NET такие вкустности есть ... в плане интерфейса ;)

С уважением,
Константин Григорьевич.
===

Re: FB + ASP.NET

[Alex Cherednichenko]

Привет, Константин!
Вы пишешь  20 сентября 2007:

[Sorry, skipped] 
 К>  Хотя в ASP.NET такие вкустности есть ... в плане интерфейса ;)

Да брось ты... ;)
Google с применемием AJAX такое ваяет, что и подумать страшно...
И что характерно, без всякого ASP.NET и IIS

-- 
With best regards, Alex Cherednichenko.

Re[2]: FB + ASP.NET

[Константин]

AC> [Sorry, skipped]
AC>  К>  Хотя в ASP.NET такие вкустности есть ... в плане интерфейса ;)

AC> Да брось ты... ;)
AC> Google с применемием AJAX такое ваяет, что и подумать страшно...
AC> И что характерно, без всякого ASP.NET и IIS

И что самое главное каким штатом сотрудников ... ;)

А если серьёзно я уж задолбался простейшие вещи каждый раз
изобретать :( Хочется как-то автоматизировать ...
Delphi for PHP - какой-то сыроватый ...

С уважением,
Константин Григорьевич.
===

Re: Off: FB + ASP.NET

[sasha]

  3) Mono на Debian стал, но не стал на Windows :( ...


Как не стал? У меня стоит моно 1.2.5 и все демки под XSP работают...

Проблема в другом. Я не знаю как в плане АСП, а вот с винформс у моно 
катастрофа - багов слишком много.

Re[2]: Off: FB + ASP.NET

[Константин]

>>   3) Mono на Debian стал, но не стал на Windows :( ...

s> Как не стал? У меня стоит моно 1.2.5 и все демки под XSP работают...

   Не ну процесс инсталяции прошёл на удивление гладко,
   но к Apache я его так и не прикрутил ...

s> Проблема в другом. Я не знаю как в плане АСП,
s> а вот с винформс у моно катастрофа - багов слишком много.

   Я о WinForm - тоже наслышан (гугля рулит) - но ведь .NET
   не ограничивается WinForms ;)

С уважением,
Константин Григорьевич.
===

Re: Off: FB + ASP.NET

[Max Rezanov]

Hello Константин,

Thursday, September 20, 2007, 2:24:09 PM, you wrote:

К>   1) .NET оказывается изначально должно хостится на IIS :( ...
ASP.NET и не должен а может :)
К>   2) ладно люди подсказали есть mono ...
люди они такие
К>Особенно меня расстроил 3 пункт, т.к. для проб - существующий
К>хостинг не годится (админ пока против).
К>Надо бы в локале сначала ..., ан нет - не получается ...

К> PS: и самое противное ... неужели кроме ADO.NET ничего не для
К> коннекта IB/FB базам ? ...
ADO.NET - штатное средство доступа в .net
К> PPS: Вот я думаю а мож ну его нафиг ? Обойдусь PHP, по старинке ...
К>  Хотя в ASP.NET такие вкустности есть ... в плане интерфейса ;)
По поводу 1.
в инете можно накопать исходники вот этого

This Cassini version requires .NET Framework v2.0.

This sample illustrates using the v2.0 ASP.NET hosting APIs (System.Web.Hosting)
to create a simple managed Web Server with System.Net APIs.

New in Cassini v2.0:
* It uses new v2.0 ASP.NET hosting APIs (System.Web.Hosting.ApplicationManager)
* It performs socket listening from the default app domain (instead of
  worker app domain as in v1.0)
* It only binds to Loopback IP address, thus making localhost only restriction
  more robust
* It is very close (but not identical) to ASP.NET development web server that
  ships with Visual Studio 2005.






  Тема Дня: Последний писк ноды.
  До не скорой встречи в аду,
 Maxmailto:[EMAIL PROTECTED]

Re: Немного флейма. Транзакции

[Vlad Khorsun]

"Ded" ...


Vlad Khorsun wrote:


   Может у мну (с) крынка резиновая, но никогда на это не напарывался.
Может я не тяну сотни тысяч на клиента (отчёты делаются другими ср-вами) ?
Единицы и, возможно, десятки тысяч пролетают без заметных проблем (редко,
но иногда бывает и такое).


   Десятки тысяч не проблема. У меня в филиальской briefcase справочной подсистеме десятками и тягается. С тех пор, как наладил 
репликацию изменией в базовых справочниках и сборку визуализации на месте из засасываемых оперативных числовых данных и названий в 
локальной базе, вполне шустренько так летает. А вот спервоначалу, когда отправлял туда резалтсет джойна из центра, в какой-нить 
Тюмени на модеме минут 40 могло грузиться. То есть, к работе с кеширующими фулл фетч датасетами в общем случае надо технологически 
подходить не как к клиент-серверу. А это не всегда хорошо. Про работу с миллионными архивами, которые в клиент-сервере до конца 
вообще практически никогда не дофетчиваются, я уж молчу.


   Я всегда работаю только через процедуры и всегда только с отфетченным
набором данных. Никогда не было необходимости работать с недофетченными
данными. Да, забыл упомянуть, - это всё двузвёнка, т.е. никаких брифкейсов\
промкжуточных уровней у меня нет. Так штааа - смотрю на всё со своей колокольни
(как, впрочем, и все остальные :)

И никаких специальных приседаний с IBX/FIBPlus для этого не надо, технология на это и заточена. Наоборот, надо приседать, когда 
нужны отступления от этой технологии. Мы с тобой приседаем при помощи CDS, а Серж строит настраиваемые гибриды с локальными 
сортировками-фильтрациями. Мне кажется, что правильней иметь и молоток и гвоздодёр отдельно и хвататься за то, что нужно в 
конкретный момент.


   Конечно. Но, согласись, я _сам_ должен выбирать чем гвозди заколачивать,
а чем - выдирать.


   У меня это тоже две разные тр-ции. Но только для того, чтобы дать им 
(возможно)
разный набор параметров, а не для обхода проблемы закрытия датасетов.


   У меня этой проблемы вообще никогда не было.


   А я не про тебя это написал :)

   В обчем - все позиции всех всем давно известны, копья давно сломаны,
говорить тут не о чем :)

--
Хорсун Влад 

Re[2]: Off: FB + ASP.NET

[Константин]

MR> По поводу 1.
MR> в инете можно накопать исходники вот этого

MR> This Cassini version requires .NET Framework v2.0.

Хм ... т.е. Насколько я понял это отдельный сервер,
на который перенаправляет Apache или IIS ?

PS: Видимо не всю гуглю ещё пеерыл ;)
Спс. попробую ...

С уважением,
Константин Григорьевич.
===

Re: Среда

[Andrei Yeryomin]

Boulitchev Aleksey пишет:


проктологических решений в реализации. Результат ну очень далёк от 
совершенства. По-хорошему ему надо было снести к е-ням эту систему 
миллионов 300 лет назад и сделать новую с нуля, учтя и ошибки и 
полученный опыт. Всё лень матушка. Но это сделать в общем никогда не 
поздно.


сейчас точно не первая версия, и даже не вторая


Интересно, а почему тогда используется подсистема HB v. 0.9?

--
С уважением,
 Андрей Еремин.

Re: Немного флейма. Транзакции

[Ded]

Vlad Khorsun wrote:


   В обчем - все позиции всех всем давно известны, копья давно сломаны,
говорить тут не о чем :)


   Ну воооттт... А по314деть? :-(

--
Regards. Ded/

Re: FB + ASP.NET

[Dmitry Voroshin]

PPS: Вот я думаю а мож ну его нафиг ? Обойдусь PHP, по старинке ...
 Хотя в ASP.NET такие вкустности есть ... в плане интерфейса ;)

А так-же в плане тормозов и размеров страниц. Уж больно оно любит POST ить
на каждый чих...

Re: Немного флейма. Транзакции

[Kovalenko Dmitry]

> >В обчем - все позиции всех всем давно известны, копья давно сломаны,
> > говорить тут не о чем :)
>
> Ну воооттт... А по314деть? :-(

по314деть?

Бл#, я не понимаю, как можно быть модератором такого авторитетного
ресурса как RSDN и так тупить!!!

Сказать что я расстроен, это бл# вообще ничего не сказать.

Коваленко Дмитрий.

Re[2]: FB + ASP.NET

[Константин]

DV> А так-же в плане тормозов и размеров страниц. Уж больно оно любит POST ить
DV> на каждый чих...

Ну, для "корпоративных" решений, я думаю тафик пофигу,
тем более инет всё дешевеет и дешевеет а скоростя растут ...

Тут как с windows 10 лет назад все кричали
да ну его нафиг эту тормозую оболочку ... ;)

С уважением,
Константин Григорьевич.
===

OFF ���� ��� ���� �����

[Dmitry Lendel]

ðÒÉ×ÅÔ
õ×ÉÄÅÌ ÎÁ ibase ÐÒÏ óõâä òÅÄ âÁÚÁ äÁÎÎÙÈ
üÔÏ ÎÏ×ÙÊ ËÌÏÎ? ñÄÒÏ ÏÔ Firebird, Á ÞÅÍ ÏÔÌÉÞÁÅÔÓÑ É ÚÁÞÅÍ ÏÎÏ ÎÕÖÎÏ?
äÍÉÔÒÉÊ

Re: Re[2]: FB + ASP.NET

[Dmitry Lendel]

ôÕÔ ËÁË Ó windows 10 ÌÅÔ ÎÁÚÁÄ ×ÓÅ ËÒÉÞÁÌÉ
ÄÁ ÎÕ ÅÇÏ ÎÁÆÉÇ ÜÔÕ ÔÏÒÍÏÚÕÀ ÏÂÏÌÏÞËÕ ... ;)

ñ É ÔÅÐÅÒØ ËÒÉÞÕ. á ÔÏÌËÕ? :-))
äÍÉÔÒÉÊ

Re: Немного флейма. Транзакции

[Kovalenko Dmitry]

> Бл#, я не понимаю, как можно быть модератором такого авторитетного
> ресурса как RSDN и так тупить!!!

Бл#. Уверен, он делает класс ради одного объекта с одним методом с
единственным return-ом. Потому что процедурное программирование уже не
модно, а объектное - не асилил. И обращается к нему через глобальный
указатель.

А когда MS разродится вещами о которых ему там целых два дня
вталкивали, не сумеет увязать "вчера" и "сегодня". Про "завтра", я
вообще молчу.

Коваленко Дмитрий.

Re: Среда

[Boulitchev Aleksey]

сейчас точно не первая версия, и даже не вторая


Интересно, а почему тогда используется подсистема HB v. 0.9?


в ранних версиях подсистемы H не было

H - это всего лишь одна из несущих частот для передачи информации в генокоде

PS читайте Лема, "Библиотеку XXI века" и "Молох"

--
Булычев Алексей
http://www.stella-npf.ru

Re: Немного флейма. Транзакции

[Vlad Khorsun]

"Kovalenko Dmitry" ...

>В обчем - все позиции всех всем давно известны, копья давно сломаны,
> говорить тут не о чем :)

Ну воооттт... А по314деть? :-(


по314деть?

Бл#, я не понимаю, как можно быть модератором такого авторитетного
ресурса как RSDN и так тупить!!!


   В каком месте оно авторитетное ? Уж не в СУБД точно :)))

--
Хорсун Влад 

Re: Немного флейма. Транзакции

[Dmitri Kuzmenko]

Hello, Vlad!

Vlad Khorsun wrote:

   Угу. Но БДЕ писалось во времена, когда клиент-сервер только начинал 
входить
в массы и толком было не понятно как с ним работать. Т.е. теоритически 
все всё знали

и понимали, а вот практических навыков (по крайней мере в Б) не было.


я позволю себе восстановить историческую справедливость.
В те давние времена Б, Н и еще кто-то создали архитектуру
IDAPI. М для себя сделал ODBC. IDAPI был лучше, но закрыт.
А ODBC был глюкавый, но простой и открыт.
Так ODBC победил IDAPI.

А чего было наверчено в BDE, было более-менее оптимально
по тем временам именно как универсальное решение.

--
Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34

Re: Немного флейма. Транзакции

[Kovalenko Dmitry]

> В каком месте оно авторитетное ? Уж не в СУБД точно :)))

Ну ты знаешь, я к RSDN прикипел что называется...

Форум по плюсам, там - я вздрагиваю. В базах данных тоже думал что
вроде ничего. Но за последние два дня - ниже плинтуса.

---
Коваленко Дмитрий.

Re: Off: FB + ASP.NET

[Oleg Deribas]

Hello,

Константин said the following on 20.09.2007 14:04:


  3) Mono на Debian стал, но не стал на Windows :( ...


s> Как не стал? У меня стоит моно 1.2.5 и все демки под XSP работают...

   Не ну процесс инсталяции прошёл на удивление гладко,
   но к Apache я его так и не прикрутил ...


Чтобы прикрутить его к apache нужен mod_mono вот отсюда: 
http://anmar.eu.org/mono/mod_mono/


У меня работал нормально.

--
Oleg

Re: OFF СУБД Ред База ДанныÑ

[Ded]

Dmitry Lendel wrote:

Привет
Увидел на ibase про СУБД Ред База Данных
Это новый клон? Ядро от Firebird, а чем отличается и зачем оно нужно?


   Чтобы добывать денги.

--
Regards. Ded.

Re: OFF ���� ��� ���� �����

[Dmitry Lendel]

>
> þÔÏÂÙ ÄÏÂÙ×ÁÔØ ÄÅÎÇÉ.
äÌÑ ËÏÇÏ? é ËÁË? ïÎ ÒÁÚ×Å ÐÌÁÔÎÙÊ?
äÍÉÔÒÉÊ

Re[4]: FB + ASP.NET

[Константин]

DL> Тут как с windows 10 лет назад все кричали
DL> да ну его нафиг эту тормозую оболочку ... ;)

DL> Я и теперь кричу. А толку? :-))

Вот и я о том же ...
В своё время пришлось нагонять (я имею ввиду Windows),
так что наученный горьким опытом 
И так чуствую что отстаю ... Причём сильно ...

С уважением,
Константин Григорьевич.
===

Re: OFF СУБД Ред База ДанныÑ

[Ded]

Dmitry Lendel wrote:


   Чтобы добывать денги.


Для кого?


   Для себя.


И как?


   Насколько я понимаю, главным образом за счёт госбюджета и откатов.


Он разве платный?


   Хто? FB - нет. Ред - да.

--
Regards. Ded.

Re: Немного флейма. Транзакции

[Vlad Khorsun]

"Dmitri Kuzmenko" ...


Hello, Vlad!

Vlad Khorsun wrote:


   Угу. Но БДЕ писалось во времена, когда клиент-сервер только начинал входить
в массы и толком было не понятно как с ним работать. Т.е. теоритически все всё 
знали
и понимали, а вот практических навыков (по крайней мере в Б) не было.


я позволю себе восстановить историческую справедливость.


   Я в курсе этого, но


В те давние времена Б, Н и еще кто-то создали архитектуру
IDAPI. М для себя сделал ODBC. IDAPI был лучше, но закрыт.


   Не факт, что он был лучше для _клиент-сервера_


А ODBC был глюкавый, но простой и открыт.
Так ODBC победил IDAPI.


   М, между прочим, в то время был далеко не так силён и богат, а вот
Б была на подъёме. Но с плохим пищеварением


А чего было наверчено в BDE, было более-менее оптимально
по тем временам именно как универсальное решение.


   Оптимально для _клиент-сервера_ ? Ох, не уверен... Но ОДБЦ
тогдашний тоже был не фонтан...

--
Хорсун Влад 

Re: Немного флейма. Транзакции

[Ded]

Kovalenko Dmitry wrote:

RSDN 


   Ля, и когда вы всё успеваете, да ещё и работать...

--
Regards. Ded.

FB 2.0, FB 2.1, SUBSTRING, NULL

[Пиминов Роман]

Тестируем собственно с Коваленко IBProvider, некоторые извращения с функцией 
SUBSTRING:

SELECT SUBSTRING('Привет' FROM 1 FOR NULL) FROM RDB$DATABASE

Смотрим в FB 2.0, возвращает строчку из шести пробелов (наверное так быть не 
должно?).
Смотрим в FB 2.1, возвращает null (наверное так и должно быть?).

IB Expert кстати и там и там показывает null (как они это делают?). Тут уж 
закрались подозрения в собственной адекватности, но в IBConsole вышло то же, 
что и у нас.

Собственно вопрос: как должно быть? Если так, как в FB 2.1, то будет ли это 
пофиксено в 2.0.3 (смотрел последний билд, там все равно пробелы возвращаются)?

--
Пиминов Роман

Re: Немного флейма. Транзакции

[Alex Cherednichenko]

Привет, Dmitri!
Вы пишешь  20 сентября 2007:

[Sorry, skipped] 
 DK> В те давние времена Б, Н и еще кто-то создали архитектуру
 DK> IDAPI. М для себя сделал ODBC. IDAPI был лучше, но закрыт.
 DK> А ODBC был глюкавый, но простой и открыт.
 DK> Так ODBC победил IDAPI.

Вообще-то, спецификация ODBC базируется на CLI (Call Level Interface),
который был _изначально_ ориентирован на "SQL-based DBMS"
История мутная и с истинными прародителями не всё ясно.
http://en.wikipedia.org/wiki/Call_Level_Interface
И кто у кого кораллы закларил, тоже не совсем понятно...

-- 
With best regards, Alex Cherednichenko.

Re: Off: FB + ASP.NET

[sasha]

У меня работал нормально.


А как он вобще по глюкам? Мы хотим перевести под него один сайт, но 
очень боимся. Мы там ASP.NET 2.0 на полную используем (деревья, гридвью, 
мастерпейджи и т.п.)

Re: Немного флейма. Транзакции

[Kovalenko Dmitry]

> Форум по плюсам, там - я вздрагиваю. В базах данных тоже думал что
> вроде ничего. Но за последние два дня - ниже плинтуса.

Я вот смотрю на ответы Ивана. Там в каждом сообщении слова -
напрягаться, сложно, устал, тупо ...

Однако,тяжела работа у программиста MSSQL. Изматывает и отупляет :))

Коваленко Дмитрий.

Re[2]: Немного флейма. Транзакции

[Jerry]

Здравствуйте, Ded.

Вы писали 20 сентября 2007 г., 17:06:35:

D> Ля, и когда вы всё успеваете, да ещё и работать...
А ты не в курсе, что теперь в сутках уже не 24 часа? :-)

-- 
С уважением,
 Jerry  mailto:[EMAIL PROTECTED]

Re: Немного флейма. Транзакции

[Vlad Khorsun]

"Kovalenko Dmitry" ...

Форум по плюсам, там - я вздрагиваю. В базах данных тоже думал что
вроде ничего. Но за последние два дня - ниже плинтуса.


Я вот смотрю на ответы Ивана. Там в каждом сообщении слова -
напрягаться, сложно, устал, тупо ...


   Он не понимает, что

а) в IB\FB нет implicit тр-ций, т.е. тр-циями управляет _только_ клиент

   в MSSQL это не так и можно увидеть тысячи строк кода как клиентского, так
   и серверного (процедуры) без BEGIN TRAN. В процедурах, кстати, управление
   тр-циями разрешено и обычно там его и делают (если делают)

б) пример с фетчем и апдейтом односится тоже к клиенту, т.е. тр-ция 2 
(апдейтящая)
   не вычитаывет данные из БД, а получает их на клиенте - поэтому ей не нужно 
знать,
   что там меняла 1-я тр-ция (которая ничё не меняла, а только читала).

в) 1-я тр-ция видит изменения 2-ой, т.к. она read-committed, а не по другой 
причине

--
Хорсун Влад 

А вот и пятница (почти уже)

[Андрей Кручинин]

Откуда берутся детки:
http://www.webpark.ru/comments.php?id=13000

А вот это уже не совсем смешно
http://mcdonalds.nnm.ru/mcdonalds_my_postavili_svoe_klejmo_v_soznanie_kazhdogo

Re: Немного флейма. Транзакции

[Dmitri Kuzmenko]

Hello, Vlad!

Vlad Khorsun wrote:


IDAPI. М для себя сделал ODBC. IDAPI был лучше, но закрыт.


   Не факт, что он был лучше для _клиент-сервера_


не спорю.


   М, между прочим, в то время был далеко не так силён и богат, а вот
Б была на подъёме. Но с плохим пищеварением


да эта шайка-лейка вообще ведь развалилась. Кто там был
кроме Б и Н - сейчас уже не помню.

--
Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34

Re: Немного флейма. Транзакции

[Dmitri Kuzmenko]

Hello, Alex!

Alex Cherednichenko wrote:


Вообще-то, спецификация ODBC базируется на CLI (Call Level Interface),
который был _изначально_ ориентирован на "SQL-based DBMS"
История мутная и с истинными прародителями не всё ясно.
http://en.wikipedia.org/wiki/Call_Level_Interface
И кто у кого кораллы закларил, тоже не совсем понятно...


я может глючу, но мне кажется что ODBC иногда
сам пуляет на сервер запросы. И это не запросы
к метаданным. Т.е. якобы клиентский SQL
каким-то образом модифицируется. Это так и есть, или мне
почудилось?

--
Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34

Re: OFF СУБД Ред База ДанныÑ

[Dmitri Kuzmenko]

Hello, Андрей!

Андрей Кручинин wrote:


Я что-то не совсем догнал - с открытым кодом кто - СУБД или БД? И
народ пошел по пути Линукса или нет, т.е. он платный, но с открытым
кодом. Что-то совсем непонятно что и как.


СУБД. Вот есть Линтер. Российская СУБД. не будем обсуждать куда
она движется, это не по теме.
А теперь есть тоже РОССИЙСКАЯ СУБД, на базе FB. С гос-сертификацией.
По лицензии IDPL, любые модификации кода FB при их распространении
должны быть открыты. Это соблюдается.
Но в данном случае это не просто СУБД. Продается РЕШЕНИЕ вместе
с СУБД. Российской.

Понятно?

--
Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34

Off Лицензии на старые продукты борланда

[Tonal]

Встала проблема с лицензиями:

Есть несколько старых проектов.
Разрабатывались на старых продуктах от Borland-а
Delphi 7, Borland C++ 5.02, C++ Builder 6
Сейчас поддерживаются и помалу дорабатываются.

Если с Delphi 7 вродь проблем нет, то как быть с C++ Builder 6, и 
особливо с Borland C++ 5.02?


--
Александр Замараев

Re: OFF СУБД Ред База ДанныÑ

[Boulitchev Aleksey]

СУБД. Вот есть Линтер. Российская СУБД. не будем обсуждать куда
она движется, это не по теме.
А теперь есть тоже РОССИЙСКАЯ СУБД, на базе FB. С гос-сертификацией.
По лицензии IDPL, любые модификации кода FB при их распространении
должны быть открыты. Это соблюдается.
Но в данном случае это не просто СУБД. Продается РЕШЕНИЕ вместе
с СУБД. Российской.


таки вы ее сертифицировали. по какому классу?

--
Булычев Алексей
http://www.stella-npf.ru

Похоже на пятничное чтение

[Slava Ekimov]

Ну что, кто еще не читал
http://rsdn.ru/forum/message/2662364.aspx

Я НЕ призываю всех идти доказывать, что IB неправ, просто прикольно почитать 
человека, который до сих пор не смог уйти от мышления в стиле dbase (ну мне так 
показалось)

Re: Re[2]: FB + ASP.NET

[Sergey Nikolaenko]

"ëÏÎÓÔÁÎÔÉÎ" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]

á ÅÓÌÉ ÓÅÒØ£ÚÎÏ Ñ ÕÖ ÚÁÄÏÌÂÁÌÓÑ ÐÒÏÓÔÅÊÛÉÅ ×ÅÝÉ ËÁÖÄÙÊ ÒÁÚ
ÉÚÏÂÒÅÔÁÔØ :( èÏÞÅÔÓÑ ËÁË-ÔÏ Á×ÔÏÍÁÔÉÚÉÒÏ×ÁÔØ ...
Delphi for PHP - ËÁËÏÊ-ÔÏ ÓÙÒÏ×ÁÔÙÊ ...

www.morfik.com , 2 ÍÅÓÑÃÁ ÍÕÞÁÅÍ ÕÖÅ...  ×ÐÅÞÁÌÅÎÉÑ ÐÏÌÏÖÉÔÅÌØÎÙÅ
Regards, Sergey

Re: Похоже на пятничное чтение

[freemanzav]

Slava Ekimov:

> Я НЕ призываю всех идти доказывать, что IB неправ, просто прикольно почитать 
> человека, который до сих пор не смог уйти от мышления в стиле dbase (ну мне 
> так показалось)

Да ишо пулингом пужает - жуть.

Re: OFF ���� ��� ���� �����

[Dmitry Lendel]

> îÏ × ÄÁÎÎÏÍ ÓÌÕÞÁÅ ÜÔÏ ÎÅ ÐÒÏÓÔÏ óõâä. ðÒÏÄÁÅÔÓÑ òåûåîéå ×ÍÅÓÔÅ
> Ó óõâä. òÏÓÓÉÊÓËÏÊ.

ëÁËÏÅ ÒÅÛÅÎÉÅ?

äÍÉÔÒÉÊ

Re: OFF ���� ��� ���� �����

[Dmitry Lendel]

> >
> > ëÁËÏÅ ÒÅÛÅÎÉÅ?
>
> × ÂÁÚÏ×ÙÊ ÐÁËÅÔ ÉÚÎÁÞÁÌØÎÏ ×ÈÏÄÑÔ äá É îåô

á ïôíåîá, ÔÏÌØËÏ × ÒÁÓÛÉÒÅÎÎÏÍ ×ÁÒÉÁÎÔÅ?
äÍÉÔÒÉÊ

������ �� �����

[Gene Feudorov]

http://www.e1.ru/talk/forum/read.php?f=20&i=141375&t=141375