Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Embedded SQL & MFC HOWTO
|
|||
|---|---|---|---|
|
#18+
РАЗРАБОТКА МНОГОПОТОЧНЫХ КЛИЕНТСКИХ ПРИЛОЖЕНИЙ ДЛЯ IBM DB2 V8.1 C ИСПОЛЬЗОВАНИЕМ MS Visual C++ V6.0 Очень часто программисты которые впервые сталкиваются с DB2 стараются пременить опыт, который они имели при работе с другими базами (Oracle,Sybase,MS SQL). Я же полагаю что переносить такой опыт нежелательно, ибо что для одного сервера баз данных работает хорошо, то для другого может быть совсем не так. Здесь, в этой статье я покажу, как легко и просто можно создавать высокоэффективные программы на Visual С++ для DB2. Скажу сразу, что приложение реализовано с помощью Embedded SQL. Почему не ODBC,CLI? По многим причинам: 1) Производительность. Что делают программисты в других базах данных для повышения производительности? Они делают хранимые процедуры. Почему приработе хранимых процедур скорость выше? Потому, что они уже откомпилированы и план запросы уже готов. Осталось только передать нужные параметры. А что такое Embedded SQL? В сущности это то же самое. Разработка программы состоит из написания исходиника *.sqx, обработки его препроцессором (компилятором SQL) и получения 2-х файлов - *.bnd и *.cxx. Файлы с расширением *.bnd содержат SQL в откомпилированном, понятном DB2 виде. А файл *.cxx - содержит всего лишь вызов этого SQL. Причем файл *.bnd должен быть связан с базой данных припомощи команды bind. В процессе связывания строится план запроса. Как нужно работать с базой данных, чтобы не было никаких задержек? Понятно, что запросы должны быть как можно короче и выполняться как можно быстрее. Как вы думаете, сколько хранимых процедур нужно реализовать, чтобы получить нормальный контекстный поиск? Для создания нужной интерактивности и производительности потребуется не один десяток процедур. Причем это не процедуры, которые реализуют какую-то сложную бизнес-логику. Они реализуют всего-лишь пользовательский интерфейс. Отсюда вытекает следующий тезис: 2) Простота и скорость разработки. Отсутствие ошибок. Гораздо проще иметь все под рукой. В одном файле и SQL, который будет выполняться, и собственно код приложения. Более того, в процессе компиляции будут проверены типы данных, корректность SQL, и если вы написали что-то не так - программа просто не откомпилится. Более того - нет необходимости согласовывать код SQL на сервере и код приложения. Кроме того у embedded sql имеется поддержка версионности. Поэтому всегда будут работать как старые, так и новые приложения. 3) Удобство. В чем оно заключается? Во-первых больше возможностей по отладке приложений. После каждого оператора SQL вы можете вывести сообщение, и решить как поступать - выполнить COMMIT или ROLLBACK или продолжить дальше выполнение программы. Попробуйте сделать такое в хранимой процедуре? Кроме того вам достуно выполнение любых операторов SQL. 4) Переносимость. Это самый больной вопрос. Все программисты кричат о переносимости. И, как правило говорят что все что можно запихнуть на сервер базы данных - надо запихнуть. В результате на сервере в конце концов появляются хранимые процедуры длинной в несколько листов и которые выполняются не 1-2 секунды, а по нескольку минут, или даже нескольку дисятков минут. Причем в этот момент невозможно точно отследить что делает такая процедура. Может она зависла? Я полагаю что все обращения к базе данных должны отрабатываться мгновенно, за исключением разве что отчетов в которых количество строк перекачиваемых на рабочуюю станцию достаточно велико (несколько тысяч). В этом случае простительна некоторая задержка. Перенос основной массы кода не сервер базы данных врядли значительно сократит трудозатраты переноса с платформы на платформу, но вот увеличит неоправданную нагрузку на сервер базы данных - это точно. В любом случае перенос с С++ на Java или с Windows на Linux потребует некоторых затрат. 4) Безопасность. В случае использования embedded sql радикально улучшается положение с защищенностью. a) Защищенность от ошибки программиста б) У позьзователей работающих с приложениями реализованными на embedded sql отсутствует реальный доступ к объектам в базе данных. У них имеется только право выполнять ваше приложение. в) Разработка приложений и их инсталяция может быть разделена между несколькими людьми. Одни имеют право компиляции, другие - связывания, третьи - выполнения. г) В приложении содержится только код вызываемого SQL, таким образом полностью отсутствует возможность увидеть реальную структуру данных или узнать ее на основе информации идущей по сети. 5) Полная поддержка C++ и как следствие ООП. Поддержка всех фичей C++ (указатели, ссылки, шаблоны, классы) делает С++ самым выгодным инструментом для разработки приложений. А теперь о некоторых неудобствах: Насколько я понял, embedded sql пока что не позволяет обрабатывать recordsets которые возвращаются из сохраненных процедур. Но без этого можно запросто обойтись. Например записать recordset во временную таблицу. Многие испытывают дискомфорт из-за за того, что требуется двойная предкомпиляция при обработке макросов. Например такой код придется обрабатывать препроцессором дважды: Код: plaintext 1. 2. 3. 4. 5. 6. 7. препроцессор DB2 не понимает выражения #define. Поэтому первым этапом нужно выполнить оброботку препроцессором C++, затем препроцессором DB2, а затем только откомпилировать результат. Все осложняется тем, что компилятор от MS Visual С++ v.6.0 не понимает расширения .sqx. в результате команда: prep test.sqx bindfile isolation ur preprocessor "cl /P" не может быть выполненна корректно,в той части, где при помощи cl /P должет был бы быть получен файл test.i , в котором все макросы #define и дерективы #include уже выполнены. Поэтому мой вам совет: по возможности не испотзуйте макросы в секциях EXEC SQL. Можно конечно пойти таким путем: cl /Р test.cpp #препроцессор C++ copy test.i test.sqx # db2 prep test.sqx bindfile isolation ur #препроцессор DB2 cl test.cxx db2api.lib #собственно компиляция но в даже в этом случае дерективы #line создадут такую кашу в исходнике, что потом в случае ошибки будет очень трудно что-либо понять. следующим неудобством является то, что заставить IDE от MS Visual Studio относиться к файлам с расширением .sqx как к файлам .cpp довольно таки трудно. Более того, каждый файл .sqx должен быть обработан препроцессором, т.е. должно быть выполнено custom build. К счатьстью эту проблему можно обойти. Я, например не испрользую в своих проектах .sqx файлы, а все файлы исходников компилю следующим нехитрым .bat файлом: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. Рассмотрим подробнее что тут написано. первые четыре строки после комментрариев удаляют мусор который мог бы остаться после предыдущих компиляций. Затем создается файл с расширением sqx, и файл с расширением .db2, который содержит скрипт обработки исходника препроцессором db2 и связывания sql с базой данных SAMPLE. Причем пакет будет создан от лица пользователя DB2ADMIN использующего пароль PASSSWWWDD. Комнда @d:\sqllib\bin\db2clpex db2 -z %1.log -vf %1.db2 запускает скрипт на выполнение, а результат выполнения скрипта будет содержаться в файле .log. Далее , если в процессе выполнения скрипта был получен файл с расширением .bnd, то процесс связывания прошел успешо, в противном случае возвращаем ошибку, предварительно распечатов .log Еще одна маленькая хитрость заключена в командочке sqx2cpp. Дело в том, что после компиляции .sqx в дерективах #line файла .cxx будет содержаться ссылка на файл .sqx. Но первоисточником у нас-то является .cpp. Поэтому файл sqx2cpp просто напросто патчит исходник заменяя .sqx на .cpp. В результате, если в процессе компиляции случится ошибка, то двойным кликом по ошибке в окне вывода вы будете перенесены именно в то место исходного файла которое нужно. Это текст sqx2cpp, вам нужно его просто откомприлить: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102. 103. 104. 105. 106. 107. 108. 109. 110. 111. 112. Ну вот, а теперь давайте разработкой простейшей многопоточной программки, которая только и будет делать, что вставлять записи в таблицу test сразу в несколько потоков. Причем по ходу дела потоки можно будет создавать, приостанавливать и запускать снова. Надеюсь что у вас установлена DB2 версии 8.1. Создайте при помощи AppWizard новое приложение, я назвал его XX5. При создании укажите что представление будет основано на классе CFormView, и будет линковаться с использованием динамических библиотек (Shared DLL). После создания приложения зайдите Project->Project Settings->Category->Precompiled Headers и откажитесь от использования предварительной компиляции заголовков. Оно и понятно, заголовки должны быть сначала обработаны препроцессором db2. Убедитесь что у вас правильно прописаны пути к каталогам с файлами INCLUDE, LIB. На всякий случай проверте что в Tools->Options->Directories->Include Files имеются каталоги D:\SQLLIB\INCLUDE и D:\SQLLIB\TEMPLATES\INCLUDE (у меня DB2 проинсталирована на D:\SQLLIB, у вас может быть по-другому) а также Tools->Options->Directories-Library Files D:\SQLLIB\LIB на закладке Project->Project Settings->Link в поле Object/Library modules впишите имя библиотеки: db2api.lib Теперь нужно сделать чтобы все файлы входящие в наш проект обрабатывались препроцессором DB2. Для этого нужно зайти в установки проекта (меню Project->Settings (Alt-F7)) для каждого файла *.cpp на закладке General устнановить галочку в чекбоксе Always use custom build step, после чего появится закладка Custom Build, и там в поле Commands нужно ввести команду: prep <имя файла без расширения> а в поле Outputs необходимо ввести путь и имя объектного файла. В нашем случае это каталог Debug\<имяфайла>.obj. Теперь можно попытаться откомпилить файл. Займемся конкретным делом, а именно добавим для нашего приложения возможность регистрации в базе данных. Создадим ресурс диалога IDD_LOGIN, у которого будут три окна Edit для ввода имени базы данных, имени пользователя и пароля (IDC_DATABASE,IDC_LOGIN,IDC_PASSWORD). В класс приложения CXX5App добавим переменные для регистрации, и собственно процедуру регистрации - connect() Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. И сообтестственно файл реализации Код: plaintext 1. 2. 3. 4. 5. 6. 7. Но в связи с тем, что препроцессором должны быть обработаны и *.h файлы нужно правильно включить их в файл реализации. Я делаю это таким образом: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. Почему я так делаю? Строки вида EXEC SQL INCLUDE 'stdafx.h'; - собственно выражение, которое будет обработано препроцессором DB2. А вторая строчка #include "stdafx.h" нужна исключительно для IDE, чтобы визуальная среда "видела" содержание и структуру заголовочного файла, т.к. выражения вида EXEC SQL INCLUDE не распознаются IDE. А так как внутренности заголовочных файлов защищены директивами #ifdef #define #endif компиляция всегда бедет проходить без ошибок. Аналогичным образом, пусть мы получили структуру таблицы из нашей базы данных при помощи команды db2dclgn.exe (кстати - очень удобная штучка, рекомендую к использованию) резельтатом выполнения которой является заголовочный файл, содержащий структуру требуемой таблицы в формате C++ Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. В другом заголовочном файле мы можем сделать следующее: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. Да, и еще одна деталь. Как правило во всех файлах использующих embedded sql необходимо использование структуры sqlca, поэтому я можифицирую файл stdafx.h добавив в него всего две строчки: Код: plaintext 1. 2. Что будет делать наше многопоточное приложение? Пусть добавляет в таблицу test записи. структура таблицы test будет очень простой, причем для генирации значений исполизуем SEQUENCE. Вот скрипт, который создаст необходимые объекты в базе данных: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. Отредактикуем представление IDD_XX5_FORM, добавим поле Edit (IDC_CNT), и четыре кнопки - Start Thread,Suspend,Resume,Terminate (IDC_START, IDC_SUSPEND_THREAD,IDC_RESUME,IDC_TERMINATE) Причем кнопки Suspend,Resume,Terminate по умалчанию сделаем disabled. Каждое запущенное окно будет соответствовать одному потоку. В процессе выполнения поток будет обновлять текст элемета управления IDC_CNT, показывающего количство записей, добавленнх текущим потоком. Собственно поток реализуется на базе класса CWinThread: class CTT: public CWinThread {...}, и полный его текст приведен в конце статьи А пока назначим действия на кнопки: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. Класс, реализующий поток: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102. 103. 104. 105. 106. 107. 108. 109. 110. 111. 112. 113. 114. 115. 116. 117. 118. 119. 120. 121. 122. 123. 124. 125. 126. 127. 128. 129. 130. 131. 132. 133. 134. 135. 136. 137. 138. 139. 140. 141. 142. 143. 144. Вообще я не являюсь большим специалистом по написанию многопоточных соединений, и показанный здесь пример уж очень простой. К сожалению в тех задачах, которые решаю я, многопоточность не нужна. Однако главная идея, как это все использовать понятна. Более того, реализуется эта техника очень просто. Если кто захочет получить приведенный здесь в качестве примера проект в исходниках, обращайтесь ко мне по адресу g a r d e n m a n @ y a n d e x . r u ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.05.2004, 09:41 |
|
||
|
Embedded SQL & MFC HOWTO
|
|||
|---|---|---|---|
|
#18+
по просьбе Gardenman присоединил файлик ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.04.2005, 17:53 |
|
||
|
Embedded SQL & MFC HOWTO
|
|||
|---|---|---|---|
|
#18+
еще одна попытка, после превью файл не присоединяется ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.04.2005, 17:53 |
|
||
|
Embedded SQL & MFC HOWTO
|
|||
|---|---|---|---|
|
#18+
Вот буквально пару дней назад хотел поднять топик про EmbedSQL, про то , кто и в каких случаях его использует, и в каких случаях нужно применять его, а не ООП библиотеки. Прочитав этот топик, становится абсолютно непонятно, зачем так страдать, когда можно написать: TDatabase... TQuery... TResultSet... Тем не менее, я думаю, что отдельный топик по EmbedSQL стоит завести. Вот только в какой ветке ворума? Может в "Сравнение СУБД"?. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.04.2005, 10:16 |
|
||
|
Embedded SQL & MFC HOWTO
|
|||
|---|---|---|---|
|
#18+
Чтож, в сравнениях можно поднять. Можно глянуть у кого код проще получается. Хотя это уже поднималось. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.04.2005, 10:55 |
|
||
|
Embedded SQL & MFC HOWTO
|
|||
|---|---|---|---|
|
#18+
2gardenman: Договорились. Кто будет создавать? Я вопросом EmbedSQL не владею на практике. Вам, я думаю сормулировать тему получится лучше. Ну и ссылка на этот топик, что бы была. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.04.2005, 11:16 |
|
||
|
Embedded SQL & MFC HOWTO
|
|||
|---|---|---|---|
|
#18+
gardenman можно добавить только ссылку на db2mag, где поясняеться как и почему появились пакеты, и почему еще используються. Ну и ежели MQ добавить для стягивания "длинных" репортов посредством, например, publish/subscribe, да еще и QP навесить, то получим архитектуру приближенную к идеалу :) PS Понятия "контекста" в ESQL появилось недавно, а до этого приходилось писать multithreaded на CLI, но позже я все мигрировал на ESQL. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.04.2005, 19:20 |
|
||
|
Embedded SQL & MFC HOWTO
|
|||
|---|---|---|---|
|
#18+
2 ggv Тут прикол еще вот в чем. Понятие контекста по ходу дела менялось. Даже в 8 версии. Когда я писал этот пример - при порождении контекста создавалась новая сессия. И следовательно, транзакция в этом новом контексте контексте была независимой. (Делая list applications я видел несколько сооединений) А теперь понятие контекста (как я полагаю) существенно изменилось. Я экспериментировал с этим недавно. У меня получилось так, что транзакция на все контексты - одна. Т.е. в транзакции можно распараллелить несколько операций: Типа Порождаем нить 1, породжаем контекс для нити 1, выполняем SQL Порождаем нить 2, породжаем контекс для нити 2, выполняем SQL ... Порождаем нить N, породжаем контекс для нити N, выполняем SQL Ждем завершения всех нитей - проверяем что все выполнилось ОК делаем один COMMIT или ROLLBACK сразу для всех нитей. Т.е. получили многопоточную транзакцию. С использованием CLI у нас каждый поток - у нас несколько независимых соединений, а следовательно и несколько независимых транзакций. Хотя порождать в этом случае отдельные потоки не нужно. А просто смешивая CLI и ESQL можно просто переключаться между соединениями и таким образом "эмулировать" автономные транзакции. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.04.2005, 20:49 |
|
||
|
Embedded SQL & MFC HOWTO
|
|||
|---|---|---|---|
|
#18+
Для MSSQL предупреждение : Код: plaintext 1. А как у DB2 c этим будет обстоять ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.04.2005, 21:23 |
|
||
|
Embedded SQL & MFC HOWTO
|
|||
|---|---|---|---|
|
#18+
2 Lepsik Мда... серьезные у MS намерения... Я думаю что IBM вряд-ли когда-либо поступит так же. Больно уж серьезно это все встроено в ядро. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.04.2005, 10:03 |
|
||
|
Embedded SQL & MFC HOWTO
|
|||
|---|---|---|---|
|
#18+
gardenman - вот этого я не видел, щас буду пробовать. Когда я с многопоточным приложением возился, контекст был полноценным независимым коннектом. Тогда 8.2 еще небыло. Я сильно разочаруюсь в IBM, если убъют ESQL..... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.04.2005, 10:57 |
|
||
|
Embedded SQL & MFC HOWTO
|
|||
|---|---|---|---|
|
#18+
2 ggv Щас я тебе примерчики выложу, на которых я экспериментировал.. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.04.2005, 11:01 |
|
||
|
Embedded SQL & MFC HOWTO
|
|||
|---|---|---|---|
|
#18+
Вот, смотри приложенный архив, может я в чем-то ошибся, но не думаю... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.04.2005, 11:10 |
|
||
|
Embedded SQL & MFC HOWTO
|
|||
|---|---|---|---|
|
#18+
gardenman - не обещаю что прям щас, но постараюсь в течении дня-двух разобраться. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.04.2005, 11:29 |
|
||
|
Embedded SQL & MFC HOWTO
|
|||
|---|---|---|---|
|
#18+
о как, это в добавок ко всему еще и С++ :) Я уж как-нибудь по старинке, на С-ях :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.04.2005, 11:33 |
|
||
|
Embedded SQL & MFC HOWTO
|
|||
|---|---|---|---|
|
#18+
Мне интересно как будет многопоточное приложение работать с временной таблицей. Т.е. возможно ли для каждой нити создать свою GTT - оказалось - нет. Типа получилось что коннект один. Ну и - вобщем получилась параллельная (многопоточная) транзакция ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.04.2005, 11:38 |
|
||
|
Embedded SQL & MFC HOWTO
|
|||
|---|---|---|---|
|
#18+
gardenman - ну на сегодня я многого не достиг (не очень много времени, какие-то непонятки с DB2 DWE for linux, также с WebSphere App Serv & DB2 Alphablox и всё под linux) но вот сейчас глянул доку раздел http://publib.boulder.ibm.com/infocenter/db2help/topic/com.ibm.db2.udb.doc/ad/c0006107.htm особенно подраздел recomendations http://publib.boulder.ibm.com/infocenter/db2help/topic/com.ibm.db2.udb.doc/ad/c0006108.htm ну и также http://publib.boulder.ibm.com/infocenter/db2help/topic/com.ibm.db2.udb.doc/admin/r0001917.htm мне показалось, что в концепции контекста ничего не изменилось.... Ежели я только внимательно читал. сегодня постараюсь скомпилить и проверить ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.04.2005, 08:35 |
|
||
|
Embedded SQL & MFC HOWTO
|
|||
|---|---|---|---|
|
#18+
почитал, однако как объяснить то, что я получаю? Может я где-то ошибся в коде? Конечно код, который я привел - сделан слегка тяп-ляп, но я не думаю что я там слишком сисльно напортачил. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.04.2005, 10:44 |
|
||
|
Embedded SQL & MFC HOWTO
|
|||
|---|---|---|---|
|
#18+
http://publib.boulder.ibm.com/infocenter/db2help/index.jsp?topic=/com.ibm.db2.udb.doc/admin/r0005841.htm gardenman, продолжать, или это оно и есть? У меня, правда, уже материал на статью получился, что-то типа "HOWTO DB2 Multithread Programmin with ESQL and Context." Можно и закончить ее, у можно и забить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.04.2005, 14:47 |
|
||
|
Embedded SQL & MFC HOWTO
|
|||
|---|---|---|---|
|
#18+
gardenman -- oops, у тебя это используеться. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.04.2005, 14:51 |
|
||
|
Embedded SQL & MFC HOWTO
|
|||
|---|---|---|---|
|
#18+
Написать статью - это хорошо... правда не знаю будет ли она востребована... А то вот я смотрю кроме меня нихто DB2 не любит ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.04.2005, 18:19 |
|
||
|
Embedded SQL & MFC HOWTO
|
|||
|---|---|---|---|
|
#18+
gardenman - а я?????? на выходных вот закончу с context (если ничем не загрузят дома), а затем можно в виде howto оформить. Правда, восстребованость будет минимальная - J2EE наш рулевой на обозримую перспективу. Так что надо почитать будет про SQLJ :) Может, сравнение какое оформиться. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.04.2005, 11:39 |
|
||
|
Embedded SQL & MFC HOWTO
|
|||
|---|---|---|---|
|
#18+
gardenman - ну всё работает как и документировано. Если я правильно понимаю, чего я натворил, и суть вопроса. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.04.2005, 12:06 |
|
||
|
Embedded SQL & MFC HOWTO
|
|||
|---|---|---|---|
|
#18+
Стоп! Все же скажи такую конкретную вещь (предлагаю 2 варианта) 1) Каждый контекст работает в своей транзакции (и, как следствие, откат в любой нити - независим от других нитей, т.е. все контексты - независимы) 2) Все контексты работают в одной транзакции, и => откат в одной нити откатывает все изменения в других нитях. Если тебе не трудно, выложи исходники, я глянуть хочу... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.04.2005, 12:24 |
|
||
|
Embedded SQL & MFC HOWTO
|
|||
|---|---|---|---|
|
#18+
ну поскольку я так и не выяснил, на каких таких правах я могу публиковать код, и поскольку мне тут же посоветовали провести "событие" для бизнес партнеров, проще сказали будет послать код персонально на мыло. Что я и сделаю. Щас вот только еще одну фигню проверю (самому интересно) и пошлю. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.04.2005, 12:45 |
|
||
|
|

start [/forum/topic.php?fid=43&msg=33010067&tid=1605001]: |
0ms |
get settings: |
9ms |
get forum list: |
15ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
48ms |
get topic data: |
6ms |
get forum data: |
2ms |
get page messages: |
86ms |
get tp. blocked users: |
1ms |
| others: | 250ms |
| total: | 423ms |

| 0 / 0 |
