AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX Blogs
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 17.04.2007, 18:01   #1  
Blog bot is offline
Blog bot
Участник
 
25,459 / 846 (79) +++++++
Регистрация: 28.10.2006
aEremenko: Update_RecordSet
Источник: http://blogs.msdn.com/aeremenk/archi...7/2161619.aspx
==============

Update_RecordSet относится к многострочным функциям, позволяющим производить обновление либо вставку нескольких записей за одну операцию.
Такие операции существенно уменьшают число запросов к базе данных и позволяют улучшить производительность операций.
Судя по сообщениям коллег, работающих в центре разработки, в 5.0 (а может и раньше, если успеют) планируется использование объединений (inner и outer) в update_RecordSet.
Например, возьмем код:
X++:
      while select * from custCollectionLetterTrans 
              where custCollectionLetterTrans.CollectionLetterNum == this.CollectionLetterNum 
                 && custCollectionLetterTrans.AccountNum          == this.AccountNum 
                 && custCollectionLetterTrans.CollectionLetterIssued 
        { 
             custTrans = CustTrans::find(custCollectionLetterTrans.CustTransId, true); 
              custTrans.CollectionLetterCode = custCollectionLetterTrans.CollectionLetterCode; 
              custTrans.update(); 
         }
Его реализация в "обновленном" update_RecordSet будет выглядеть так:
X++:
       update_recordset custTrans 
            setting CollectionLetterCode = custCollectionLetterTrans.CollectionLetterCode 
            join custCollectionLetterTrans 
              where custCollectionLetterTrans.CollectionLetterNum == this.CollectionLetterNum 
                 && custCollectionLetterTrans.AccountNum          == this.AccountNum 
                 && custCollectionLetterTrans.CollectionLetterIssued 
                 && custTrans.RecId == custCollectionLetterTrans.CustTransId;
Супер!


Источник: http://blogs.msdn.com/aeremenk/archi...7/2161619.aspx
__________________
Расскажите о новых и интересных блогах по Microsoft Dynamics, напишите личное сообщение администратору.
За это сообщение автора поблагодарили: Recoilme (5).
Старый 17.04.2007, 21:01   #2  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от Blog bot Посмотреть сообщение
Такие операции существенно уменьшают число запросов к базе данных и позволяют улучшить производительность операций.
Такие операции МОГУТ уменьшить число запросов и МОГУТ улучшить производительность, если:
1. в обрабатываемой таблице нет переопределенных методов insert, update, delete соответственно
2. обрабатываемая таблица не включена в RLS
3. обрабатываемая таблица не содержит deleteAction (для удаления)

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

Подробнее см хелп, ключевая фраза "What prevents fast SQL operations?"

Кроме того, подобные операции может быть и повышают производительность, но гарантировано уменьшают наглядность и юзабилити.
Обычно при длительной обработке данных показывают прогресс-бар, который показывает сколько процентов осталось.
Групповые операции ничего не показывают. Если групповая операция выполняется несколько минут, то вы не знаете: повисла она, заблокирована или таки выполняется.

И кроме того, групповые операции блокируют ВСЕ обрабатываемые записи за один раз. А обработка каждой записи, при правильном написании, блокирует только обрабатываемую запись. См. aEremenko: Ресурс заблокирован, ждите...

Ну, и напоследок, групповые операции не позволяют работать с критериями из query. Что напрочь лишает их полезность, если пользователь может задавать критерии со спец-символами http://axapta.mazzy.ru/lib/search/

В общем, групповые операции дело хорошее.
Но у них тоже есть минусы.

Цитата:
Сообщение от Blog bot Посмотреть сообщение
Например, возьмем код:
X++:
      while select * from custCollectionLetterTrans 
              where custCollectionLetterTrans.CollectionLetterNum == this.CollectionLetterNum 
                 && custCollectionLetterTrans.AccountNum          == this.AccountNum 
                 && custCollectionLetterTrans.CollectionLetterIssued 
        { 
             custTrans = CustTrans::find(custCollectionLetterTrans.CustTransId, true); 
              custTrans.CollectionLetterCode = custCollectionLetterTrans.CollectionLetterCode; 
              custTrans.update(); 
         }
Это отвратительный код, за который надо штрафовать программиста и снижать его зарплату. Надеюсь, что этот код упрощен только для демонстрационных целей

Более правильный код:

X++:
SysProgressOperation progress;
;
      select count(recid) from custCollectionLetterTrans 
              where custCollectionLetterTrans.CollectionLetterNum == this.CollectionLetterNum 
                 && custCollectionLetterTrans.AccountNum          == this.AccountNum 
                 && custCollectionLetterTrans.CollectionLetterIssued;
      progress = SysProgressOperation::newGeneral('','',custCollectionLetterTrans.recid);


      while select * from custCollectionLetterTrans 
              where custCollectionLetterTrans.CollectionLetterNum == this.CollectionLetterNum 
                 && custCollectionLetterTrans.AccountNum          == this.AccountNum 
                 && custCollectionLetterTrans.CollectionLetterIssued 
        { 
              ttsbegin;
             custTrans = CustTrans::find(custCollectionLetterTrans.CustTransId, true); 
              custTrans.CollectionLetterCode = custCollectionLetterTrans.CollectionLetterCode; 
              custTrans.update(); 
              ttscommit;

              progress.inccount();
         }
Еще более правильным было бы создание запроса для таблицы и код:
X++:
SysProgressOperation progress;
Query q;
QueryBuildDataSource = qbds;
QueryRun qr;
;
q = new Query(queryStr(mySupercustCollectionLetterTransQuery));
qbds = q.datasourcetable(tablenum(custCollectionLetterTrans));
SysQuery::findOrCreateRange(qbds,fieldnum(custCollectionLetterTrans,CollectionLetterNum ).value(this.CollectionLetterNum);
SysQuery::findOrCreateRange(qbds,fieldnum(custCollectionLetterTrans,AccountNum).value(this.AccountNum );
SysQuery::findOrCreateRange(qbds,fieldnum(custCollectionLetterTrans,CollectionLetterIssued).value(SysQuery::notEmptyString());

qr = new QueryRun(q);
progress = SysProgressOperation::newGeneral('','',SysQuery::CountTotal(qr));


while( qr.next() )
{ 
    custCollectionLetterTrans = qr.getTable(tablenum(custCollectionLetterTrans));

    ttsbegin;
    custTrans = CustTrans::find(custCollectionLetterTrans.CustTransId, true); 
    custTrans.CollectionLetterCode = custCollectionLetterTrans.CollectionLetterCode; 
    custTrans.update(); 
    ttscommit;

    progress.inccount();
}
Этот код позволяет:
1. отделить запрос и процесс его оптимизации от программирования.
2. позволяет работать с пользовательскими критериями
3. полностью совместим со всей функциональностью форм и отчетов
4. полностью совместим с пакетной обработкой
5. информирует пользователя о ходе выполнения.

Поэтому... Если уж начали двигаться в сторону групповых операций... Если это возможно.... Нужен не update_recordset, а дополнительный режим групповой обработки для Query.
__________________
полезное на axForum, github, vk, coub.
За это сообщение автора поблагодарили: Recoilme (-2), kashperuk (3), oip (9).
Старый 18.04.2007, 14:06   #3  
Morpheus is offline
Morpheus
Участник
Аватар для Morpheus
Соотечественники
 
602 / 164 (7) ++++++
Регистрация: 30.03.2005
Адрес: Київ-København-Düsseldorf
Цитата:
Сообщение от Blog bot Посмотреть сообщение
Источник: [url]Update_RecordSet относится к многострочным функциям, позволяющим производить обновление либо вставку нескольких записей за одну операцию.
Реляционный подход "родной" для реляционной СУБД и будет работать максимально эффективно.

В Axapta, класс Common, родитель для классов таблиц предоставляет мощный механизм OBJECT-RELATIONAL MAPPING (ORM), что является ключевой особенностью объектого подхода в моделировании и разработке приложений.

Реляционные подходы в объектной системе только испортят наглядность.
Старый 18.04.2007, 14:49   #4  
Garic is offline
Garic
NavAx
Аватар для Garic
NavAx Club
 
393 / 63 (3) ++++
Регистрация: 23.07.2002
Адрес: Москва
Цитата:
Сообщение от mazzy Посмотреть сообщение
Это отвратительный код, за который надо штрафовать программиста и снижать его зарплату. Надеюсь, что этот код упрощен только для демонстрационных целей

Более правильный код:

.....

Этот код позволяет:
1. отделить запрос и процесс его оптимизации от программирования.
2. позволяет работать с пользовательскими критериями
3. полностью совместим со всей функциональностью форм и отчетов
4. полностью совместим с пакетной обработкой
5. информирует пользователя о ходе выполнения.
Ну зачем же так однозначно
1.) Ваш код замедляет работу из-за множества мелких транзакций.
2.) Визуализация тоже стоит времени - на длительных операциях замечал разницу, если не ошибаюсь, в 30%.
__________________
С уважением, Игорь Ласийчук.

Последний раз редактировалось Garic; 18.04.2007 в 14:52.
За это сообщение автора поблагодарили: Recoilme (5).
Старый 18.04.2007, 15:35   #5  
AlGol is offline
AlGol
Участник
 
277 / 93 (4) ++++
Регистрация: 24.12.2001
Адрес: Тверь.
В работе операций update_recordset есть некоторые ньюансы которые дают сложноотлавливаемые баги.

На одной из версий Аксапты (уже и не помню какой) применение двух последовательных update_recordset давало некорректный результат. Осталось предположение, что отправив запрос на обновление на sqlсервер система продолжила выполнение последующего кода, не дожидаясь полного выполнения запроса. Как результат, следующий update_recordset, использующий результаты предыдущего давал некорректные результаты.

Поборолось обрамлением каждого update_recordset в отдельных ttsbegin/ttscommit. Но осадочек остался...
Старый 18.04.2007, 16:05   #6  
Recoilme is offline
Recoilme
злыдень
Аватар для Recoilme
Злыдни
 
895 / 192 (8) ++++++
Регистрация: 18.06.2003
У каждого подхода есть свои плюсы минусы. Можно 30 минут показывать пользователю "градусник", а можно за пару минут выполнить туже операцию, но без градусника.

И каждый метод может дать "неожиданные" результаты, особенно если не понимать как они работают.

Я лишь присоединюсь к первоначальному посту А.Еременко:

Супер!
__________________
Ибо зло есть лучшая сила человека. "Человек должен становиться все лучше и злее" -- так учу я. /Ф. Ницше/
Старый 18.04.2007, 21:23   #7  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от Garic Посмотреть сообщение
Ну зачем же так однозначно
1.) Ваш код замедляет работу из-за множества мелких транзакций.
Я ждал такого замечания. Не ожидал от вас.

Приведенный мной код замедляет работу ТОЛЬКО одного пользователя.
НО приведенный мной код ускоряет работу НЕСКОЛЬКИХ одновременно работающих пользователей. Из-за снижения вероятности блокировок.

За подробностями обращайтесь к совету Еременко.

Цитата:
Сообщение от Garic Посмотреть сообщение
2.) Визуализация тоже стоит времени - на длительных операциях замечал разницу, если не ошибаюсь, в 30%.
30% на визуализацию? ужас.
Пользуйтесь стандартным классом SysOperationProgress.
Разберитесь как и когда он обновляется и при каких условиях.

Обсуждение этого класса наверное оффтопик в этой ветке.
__________________
полезное на axForum, github, vk, coub.
Старый 18.04.2007, 21:25   #8  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от Recoilme Посмотреть сообщение
Можно 30 минут показывать пользователю "градусник", а можно за пару минут выполнить туже операцию, но без градусника.
Можно пример?
__________________
полезное на axForum, github, vk, coub.
Старый 19.04.2007, 06:22   #9  
slava is offline
slava
сибиряк
Самостоятельные клиенты AX
 
468 / 23 (1) +++
Регистрация: 28.12.2001
Адрес: Москва
Цитата:
Сообщение от mazzy Посмотреть сообщение
Пользуйтесь стандартным классом SysOperationProgress.
Особенно чудные результаты дает этот класс при работе с несколькими компаниями.
__________________
С уважением, Вячеслав.
Старый 19.04.2007, 08:05   #10  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от slava Посмотреть сообщение
Особенно чудные результаты дает этот класс при работе с несколькими компаниями.
Для обсуждения прогрессбара создал Какие проблемы у SysOperationProgress?
Здесь давайте вернемся к групповым операциям в Аксапте?
__________________
полезное на axForum, github, vk, coub.
Старый 19.04.2007, 09:01   #11  
Recoilme is offline
Recoilme
злыдень
Аватар для Recoilme
Злыдни
 
895 / 192 (8) ++++++
Регистрация: 18.06.2003
Цитата:
Сообщение от mazzy Посмотреть сообщение
Более правильный код:

X++:
SysProgressOperation progress;
;
      select count(recid) from custCollectionLetterTrans 
              where custCollectionLetterTrans.CollectionLetterNum == this.CollectionLetterNum 
                 && custCollectionLetterTrans.AccountNum          == this.AccountNum 
                 && custCollectionLetterTrans.CollectionLetterIssued;
      progress = SysProgressOperation::newGeneral('','',custCollectionLetterTrans.recid);


      while select * from custCollectionLetterTrans 
              where custCollectionLetterTrans.CollectionLetterNum == this.CollectionLetterNum 
                 && custCollectionLetterTrans.AccountNum          == this.AccountNum 
                 && custCollectionLetterTrans.CollectionLetterIssued 
        { 
              ttsbegin;
             custTrans = CustTrans::find(custCollectionLetterTrans.CustTransId, true); 
              custTrans.CollectionLetterCode = custCollectionLetterTrans.CollectionLetterCode; 
              custTrans.update(); 
              ttscommit;

              progress.inccount();
         }
Еще более правильным было бы создание запроса для таблицы и код:
...
Это НЕ правильный код.

Представьте простую ситуацию, Вы разносите накладную из 100 строк. каждая строка обрабатывается в отдельной транзакции. На строке 87 возникает исключительная ситуация , товара недостаточно на складе, а предыдущие 86 строк уже списали товар....

Помедитируйте на тему зачем вообще нужны транзакции, как они работают и что такое целостность данных

Буквально пару дней назад думал убью долго и подробно объяснял 3 одинэсникам почему, например, импорт документа из аксапты надо облачать в транзакзию, а не обрабатывать построчно как они привыкли.

То ли это 1с разрушает моск, то ли просто так совпало
__________________
Ибо зло есть лучшая сила человека. "Человек должен становиться все лучше и злее" -- так учу я. /Ф. Ницше/
Старый 19.04.2007, 09:48   #12  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от Recoilme Посмотреть сообщение
Это НЕ правильный код.

Представьте простую ситуацию,
Recoilme, вы понимаете разницу между "ЭТОТ код" и "ПРЕДСТАВЬТЕ простую ситуацию".

Цитата:
Сообщение от Recoilme Посмотреть сообщение
Вы разносите накладную из 100 строк. каждая строка обрабатывается в отдельной транзакции. На строке 87 возникает исключительная ситуация , товара недостаточно на складе, а предыдущие 86 строк уже списали товар....
В такой ситуации, естестенно должна быть общая транзакция.

Цитата:
Сообщение от Recoilme Посмотреть сообщение
Буквально пару дней назад думал убью долго и подробно объяснял 3 одинэсникам почему, например, импорт документа из аксапты надо облачать в транзакзию, а не обрабатывать построчно как они привыкли.
Recoilme, вы тормозите.
Импорт документа в одной транзакции
Но, скорее всего, не должно быть облачающей транзакции для импорта всех документов.
Речь об этом, а не о строчках. Строчки естественно должны импортироваться в "облачающей" транзакции.


Цитата:
Сообщение от Recoilme Посмотреть сообщение
То ли это 1с разрушает моск, то ли просто так совпало
Как то да... Берегите себя.
__________________
полезное на axForum, github, vk, coub.
Старый 19.04.2007, 09:58   #13  
Garic is offline
Garic
NavAx
Аватар для Garic
NavAx Club
 
393 / 63 (3) ++++
Регистрация: 23.07.2002
Адрес: Москва
Цитата:
Сообщение от mazzy Посмотреть сообщение
Я ждал такого замечания. Не ожидал от вас.

Приведенный мной код замедляет работу ТОЛЬКО одного пользователя.
НО приведенный мной код ускоряет работу НЕСКОЛЬКИХ одновременно работающих пользователей. Из-за снижения вероятности блокировок.
В большинстве случаев нужна одна транзакция - для целостности данных.
Если ожидается что транзакция будет слишком большой что чревато блокировками да и просто тормозит работу, надо стараться разбить её, в многих случаях это возможно.
Можно делать ttscommit/ttsbegin например после каждых 500 строк. Но за маленькие транзакции я бью по рукам

Чтобы не быть голословным - провёл тест (по 5 тестов на каждый вариант) на табличке inventTrans (14 тыс. записей). Добавил в неё текстовое поле 10 - в него пишу timenow.

В случае одной транзакции - 34,8 сек. (100%)
В случае маленьких транзакций с прогрессбаром - 68,3 сек (196%)
В случае маленьких транзакций без прогрессбара - 65,2 сек (187%)

Версия Axapta - 4.0 SP1

Цитата:
Сообщение от mazzy Посмотреть сообщение
30% на визуализацию? ужас.
Пользуйтесь стандартным классом SysOperationProgress.
Разберитесь как и когда он обновляется и при каких условиях.

Обсуждение этого класса наверное оффтопик в этой ветке.
Как показал тест, действительно немного он тратит, зря я его так. Хотя может это в четвёрке стало быстрее. Мне запомнилась цифра в 30%, надо бы проверить на трёшке.
__________________
С уважением, Игорь Ласийчук.
Старый 19.04.2007, 10:12   #14  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от Garic Посмотреть сообщение
Можно делать ttscommit/ttsbegin например после каждых 500 строк.
Да, например.

Цитата:
Сообщение от Garic Посмотреть сообщение
Но за маленькие транзакции я бью по рукам
А вот это зря.

Цитата:
Сообщение от Garic Посмотреть сообщение
Чтобы не быть голословным - провёл тест (по 5 тестов на каждый вариант) на табличке inventTrans (14 тыс. записей). Добавил в неё текстовое поле 10 - в него пишу timenow.

В случае одной транзакции - 34,8 сек. (100%)
В случае маленьких транзакций с прогрессбаром - 68,3 сек (196%)
В случае маленьких транзакций без прогрессбара - 65,2 сек (187%)
Я еще раз повторяю, что вы не тот случай оптимизируете.
Вы оптимизируете работу ОДНОГО пользователя.
Попробуйте запустить хотя бы 10-20, а лучше 50-100 пользователей, которые работают с InventTrans, пишут и читают один и тот же набор данных.
Оцените производительность больших и маленьких транзакций для МНОГОПОЛЬЗОВАТЕЛЬСКОЙ системы.

Про прогресс бар пожалуйста сюда Какие проблемы у SysOperationProgress?
Здесь предлагаю сосредоточиться на больших и маленьких транзакциях, групповых и негрупповых обработках данных.
__________________
полезное на axForum, github, vk, coub.
Старый 19.04.2007, 10:15   #15  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от Garic Посмотреть сообщение
14 тыс. записей
Кстати, 14 тыс - это небольшое число. Все записи, скорее всего, помещаются в кэш сервера.
О влиянии кэша см. http://axapta.mazzy.ru/lib/axapta_itanium/

Но даже на таком маленьком числе записей разница в многопользовательском тесет будет заметна.

Пожалуйста, не надо из Аксапты делать однопользовательскую ЕРП.
Пожалуйста, тестируйте для многих пользователей.
__________________
полезное на axForum, github, vk, coub.
Старый 19.04.2007, 15:05   #16  
Garic is offline
Garic
NavAx
Аватар для Garic
NavAx Club
 
393 / 63 (3) ++++
Регистрация: 23.07.2002
Адрес: Москва
Был исходный код, вы назвали его ужасным и предложили свой, мне он не понравился.
Я не говорил что надо всё обрабатывать в одной транзакции.
Я говорил что не надо так однозначно отзываться о коде. В каких-то случаях будет правильным первый вариант, в каких-то ваш.
Но для длительных операций, не стоит делать такие маленькие транзакции как в вашем примере. Если уж делать, то объединять в одну транзакцию несколько итераций (например 500).

Ну а блокировки - в четвёрке вроде с ними легче стало.
__________________
С уважением, Игорь Ласийчук.
Старый 19.04.2007, 16:47   #17  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от Garic Посмотреть сообщение
Но для длительных операций, не стоит делать такие маленькие транзакции как в вашем примере.
Я продолжаю настаивать на том, что код первоначальный ужасный.
Я продолжаю настаивать на том, что для многопользовательской системы транзакции надо делать как можно меньше.

Пожалуйста, читайте совет Еременко aEremenko: Ресурс заблокирован, ждите...
Если не верите, то проведите многопользовательский тест. Пожалуйста.
Результаты тестирования в однопользовательском режиме не являются критериями правильности для транзакций (транзакции в однопользовательском режиме вообще не нужны).
__________________
полезное на axForum, github, vk, coub.
Теги
recordset, update_recordset, ax2009

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
aEremenko: Использование прямых запросов SQL Blog bot DAX Blogs 4 18.07.2007 10:09
aEremenko: Создание сервера отчетности Blog bot DAX Blogs 3 06.07.2007 14:47
aEremenko: Как сопоставить пользователя DAX и сессию в Oracle? Blog bot DAX Blogs 0 26.06.2007 21:00
aEremenko: Совместимость OS и AOS Blog bot DAX Blogs 0 11.05.2007 10:00
aEremenko: Ответы на вопросы индийского коллеги II Blog bot DAX Blogs 0 04.05.2007 23:03
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 01:44.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.