|
DB2: Коннект к удаленному серверу из хранимой процедуры на C (Си)
|
|||
---|---|---|---|
#18+
Доброго дня всем! Вот возник такой вопрос. Надо построить ХП, которая, в свою очередь, должна бы приконнектиться к другому серверу, вызвать на нем хранимую процедуру, получить ее ресальтсет, что-то с ним сделать (на данном этапе пока не важно что, хотя хотелось бы уметь делать это что-то средствами SQL) и отдать на основе этого свой ресальт сет... Процедура должна быть написана на Си. Конкретно вопросы следующие: 1. Правильно ли я понимаю, что надо в документации рыть в направлении некоего CLI ? Будет ли он (CLI) работать потом на OS/390 (как можно создать код, который будет компилится на Windows и на OS/390)? 2. Можно ли делать подобное без создания federated объектов? 3. Правильно ли я понимаю, что для передачи полученный данных в SQL (что бы сделать что-то с ним средствами SQL) нужно создавать временную таблицу и курсором передавать в нее полученный ресальсет? 4. А можно ли средствами SQL выполнить некую произвольную SQL последовательность команд на другом (произвольном) сервере? 5. Можно ли средствами SQL вызвать процедуру (желательно - на удаленном сервере) и результат ее выполнения получить в таблицу? ... |
|||
:
Нравится:
Не нравится:
|
|||
21.12.2004, 15:12 |
|
DB2: Коннект к удаленному серверу из хранимой процедуры на C (Си)
|
|||
---|---|---|---|
#18+
оно вам точно нужно? >Будет ли он (CLI) работать потом на OS/390 Будет. возможно, с небольшими изменениями. на CLI не получиться работать с 2 серверами в одной транзакции. >как можно создать код, который будет компилится на Windows и на OS/390)? Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22.
SQL-запросы нужно сразу подбирать такие, чтоб работали на 390 и на windows. как правило если запрос работает на 390, он работает и в windows. > Можно ли делать подобное без создания federated объектов connect type 2 ..... connect to server1; connect to server2; set connection to server1; blablabla1; set connection to server2; blablabla2; .... >Правильно ли я понимаю, что для передачи полученный данных в SQL (что бы сделать что-то с ним средствами SQL) нужно создавать временную таблицу и курсором передавать в нее полученный ресальсет? можно так. можно по другому. например, написать табличную функцию, а не процедуру. но на 390 для функции понадобится WLM. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.12.2004, 15:51 |
|
DB2: Коннект к удаленному серверу из хранимой процедуры на C (Си)
|
|||
---|---|---|---|
#18+
Не уверен что в хранимой процедуре можно давать коннект к другой БД ... |
|||
:
Нравится:
Не нравится:
|
|||
21.12.2004, 17:24 |
|
DB2: Коннект к удаленному серверу из хранимой процедуры на C (Си)
|
|||
---|---|---|---|
#18+
nkulikovНе уверен что в хранимой процедуре можно давать коннект к другой БД Вообще, когда нибудь будет реализован гетерогенный запрос в DB2 по типу ораклового пресловутого дблинка? ... |
|||
:
Нравится:
Не нравится:
|
|||
22.12.2004, 10:35 |
|
DB2: Коннект к удаленному серверу из хранимой процедуры на C (Си)
|
|||
---|---|---|---|
#18+
ГостиВообще, когда нибудь будет реализован гетерогенный запрос в DB2 по типу ораклового пресловутого дблинка? Вы можете использовать Federated System в DB2 для достижения этой цели! ... |
|||
:
Нравится:
Не нравится:
|
|||
22.12.2004, 12:19 |
|
DB2: Коннект к удаленному серверу из хранимой процедуры на C (Си)
|
|||
---|---|---|---|
#18+
spclient.sqc (каталог samples) 8 версия DB2 UDB, то же самое было в 7 Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21.
Пишите standalone приложение. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.12.2004, 14:27 |
|
DB2: Коннект к удаленному серверу из хранимой процедуры на C (Си)
|
|||
---|---|---|---|
#18+
Код: 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.
Код: 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.
все остальное можно нарыть в документации и не заморачиваться сильно... ... |
|||
:
Нравится:
Не нравится:
|
|||
22.12.2004, 15:05 |
|
DB2: Коннект к удаленному серверу из хранимой процедуры на C (Си)
|
|||
---|---|---|---|
#18+
Извиняюсь за предыдущее сообщение, посмотрел примеры по CLI, там можно открывать result set процедуры. Немного сложнее, чем Embedded SQL, но можно использовать. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.12.2004, 15:39 |
|
DB2: Коннект к удаленному серверу из хранимой процедуры на C (Си)
|
|||
---|---|---|---|
#18+
NewYearоно вам точно нужно? Вообще да. Может я просто туманно выразился. У меня есть доступ к запуску хранимки на удаленном сервере под управлением OS/390 и нужно написать хранимую процедуру (она потом будет размещена на другом сервере, "локальном", OS/390), которая будет смотреть, есть ли нужные и непросроченные данные в локальной таблице (типа кэш) и, если нет, вызывать хранимую процедуру с другого сервера, получать от нее ресальт сет, записывать полученные данные в кэш и возвращать их клиенту. Удаленная процедура сейчас написана так, что свой ресальт сет возвращает to client. NewYear >Будет ли он (CLI) работать потом на OS/390 Будет. возможно, с небольшими изменениями. на CLI не получиться работать с 2 серверами в одной транзакции. Ну, мне вроде бы и не нужно в одной. У меня вообще что-то не получается с транзакциями. Подозреваю, что это из-за autocommit. Не могу никак понять - это свойство инстанса или свойство коннекшена и, если коннекшена, то как в хранимой процедуре на Си его (автокоммит) запретить. NewYear >как можно создать код, который будет компилится на Windows и на OS/390)? Код: plaintext 1. 2.
Спасибо. NewYear > Можно ли делать подобное без создания federated объектов connect type 2 ..... connect to server1; connect to server2; set connection to server1; blablabla1; set connection to server2; blablabla2; .... Эти стайтменты не получается использовать в ХП. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.12.2004, 11:46 |
|
DB2: Коннект к удаленному серверу из хранимой процедуры на C (Си)
|
|||
---|---|---|---|
#18+
gardenman[src] -- создаем базу данных (типа удаленную) (скип) все остальное можно нарыть в документации и не заморачиваться сильно... Я насколько понял - это создается federated объект? Будут ли таким же образом вызываться процедуры? Впрочем, сейчас буду пробовать. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.12.2004, 11:56 |
|
DB2: Коннект к удаленному серверу из хранимой процедуры на C (Си)
|
|||
---|---|---|---|
#18+
вообще-то похоже на репликацию. убрать aвтокоммт: rc = SQLSetConnectAttr(hConn, SQL_ATTR_AUTOCOMMIT, (SQLPOINTER)SQL_AUTOCOMMIT_OFF, SQL_NTS); не знаю, будет ли это работать в XP/ и все-таки зачем XP? не проще обычную программку написать, запустить job-ом, пусть себе выравнивает данные. или настроить репликацию. сразу все вопросы снимаются. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.12.2004, 12:18 |
|
DB2: Коннект к удаленному серверу из хранимой процедуры на C (Си)
|
|||
---|---|---|---|
#18+
NewYearвообще-то похоже на репликацию. Нет, это совсем не репликация. Т.е. не предполагается переносить в кэш все данные из таблиц-источников. NewYear и все-таки зачем XP? Такова корпоративная идеология разработки. NewYear не проще обычную программку написать, запустить job-ом, пусть себе выравнивает данные. или настроить репликацию. сразу все вопросы снимаются. Проще, но подобный вопрос или не может быть решен или не хочет быть решен. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.12.2004, 12:24 |
|
DB2: Коннект к удаленному серверу из хранимой процедуры на C (Си)
|
|||
---|---|---|---|
#18+
Увы, но на кли не получилось ничего. Послее более вдумчивого изучения документации нашлись вещи типа такой (про функцию SQLConnect) : "Stored procedures written using DB2 CLI must make a null SQLConnect() call." При этом, получая правильные хендлы окружения и коннекта (потому что я смог по ним получить список баз доступных для коннекта) на попытку коннекта возвращается -1 без доп инфы. Попытки использовать SQLDriverConnect тоже не принесли успеха и поэтому я не стал пробовать и Browse. Сейчас, наверно, буду пробовать ODBC. Вопрос с тем, что моя ХП будет запускаться под DB2 for Win уже решили. Однако пользователю удаленного сервера (которого мне дали) разрешен доступ _только_ на запуск этой процедуры (во всяком случае - официально). Если не получится с ODBC прямо не знаю... в голове нечинают выстраиваться дурацкие схемы с использованием MS SQL как посредника. Неужели нет возможности получить данные от процедуры удаленного сервера??? ... |
|||
:
Нравится:
Не нравится:
|
|||
28.12.2004, 11:09 |
|
DB2: Коннект к удаленному серверу из хранимой процедуры на C (Си)
|
|||
---|---|---|---|
#18+
я вообще-то не пробовал... а если написать на С++ табличную функцию?... тоже не прокатит? Табличные ф-ции очень легко пишутся на С++ ... |
|||
:
Нравится:
Не нравится:
|
|||
28.12.2004, 13:57 |
|
DB2: Коннект к удаленному серверу из хранимой процедуры на C (Си)
|
|||
---|---|---|---|
#18+
gardenmanя вообще-то не пробовал... а если написать на С++ табличную функцию?... тоже не прокатит? Табличные ф-ции очень легко пишутся на С++ Если я правильно понимаю, то в табличной функции нужно данные откуда-то брать. Значит - дожен быть доступ на выполнение табличной функции (или на селект таблицы) на сервере-источнике. Но функции с такими данными там нет и на селекты доступ закрыт - это не наш сервер. Соответственно - размещать там свою функцию мы тоже не можем. Или в табличных функциях я могу указывать коннект к другим базам? ... |
|||
:
Нравится:
Не нравится:
|
|||
29.12.2004, 10:08 |
|
DB2: Коннект к удаленному серверу из хранимой процедуры на C (Си)
|
|||
---|---|---|---|
#18+
ниче не понимаю... у вас есть только коннект к удаленной базе... ну есть хотябы на какие-то таблицы право на select? Я так полагаю, что вас тяготит необходимость постоянного коннекта к удаленной базе? ОК!. делаем просто. 1)Пишете простое приложение допустим на С, которое коннектится к удаленной базе что-то выдает в стандартный вывод. (пишите на чем хотите - хоть на ODBC...) 2)Пишем табличную функцию на локальной базе, которая запускает приложение из пп1 и его вывод представляет в виде таблички. Думаете это сложно? :)) ... |
|||
:
Нравится:
Не нравится:
|
|||
29.12.2004, 10:17 |
|
DB2: Коннект к удаленному серверу из хранимой процедуры на C (Си)
|
|||
---|---|---|---|
#18+
2gardenman : Да, проверкой Вашего варианта у нас занимался другой инженер, он сказал, что с селектом из таблицы выходит, а вот call не выполняется. Похоже, что из-за этого: SQL Reference: Pass-Through Facility Processing Considerations and Restrictions There are a number of considerations and restrictions that apply to pass-through. Some of them are of a general nature; others concern Oracle data sources only. Using Pass-Through with All Data Sources The following information applies to all data sources: (skip) Pass-through does not support stored procedure calls . (skip) ... |
|||
:
Нравится:
Не нравится:
|
|||
29.12.2004, 10:22 |
|
DB2: Коннект к удаленному серверу из хранимой процедуры на C (Си)
|
|||
---|---|---|---|
#18+
gardenmanниче не понимаю... у вас есть только коннект к удаленной базе... ну есть хотябы на какие-то таблицы право на select? У нас есть право запустить там процедуру. На select прав нет. (Впрочем - не только у нас) gardenman Я так полагаю, что вас тяготит необходимость постоянного коннекта к удаленной базе? Да нет. Меня тяготит, что я не могу в хранимую процедуру на Си получить результат выполнения хранимой процедуры на удаленном сервере (из другой базы) gardenman ОК!. делаем просто. 1)Пишете простое приложение допустим на С, которое коннектится к удаленной базе что-то выдает в стандартный вывод. (пишите на чем хотите - хоть на ODBC...) 2)Пишем табличную функцию на локальной базе, которая запускает приложение из пп1 и его вывод представляет в виде таблички. Думаете это сложно? :)) Я еще о таком не думал. На первый взгляд - многовато преобразований и модулей, которые выполняют одно действие. Возможно так и придется сделать. Насколько сложно - я пока не знаю, но если у Вас есть время привести простой пример такой схемы, то я был бы благодарен. Однако если времени нет, то буду сам разбираться! :) ... |
|||
:
Нравится:
Не нравится:
|
|||
29.12.2004, 10:42 |
|
DB2: Коннект к удаленному серверу из хранимой процедуры на C (Си)
|
|||
---|---|---|---|
#18+
Завершил опыты с ODBC - как ни странно, но полуается, что я не могу реализовывать коннект к базе из dll. Возможно, дело в том, что конкретно из-под db2 не получается делать коннект. :( ... |
|||
:
Нравится:
Не нравится:
|
|||
30.12.2004, 14:10 |
|
DB2: Коннект к удаленному серверу из хранимой процедуры на C (Си)
|
|||
---|---|---|---|
#18+
2gardenmen & All: А Вы все же могли мне подсказать - как из Си запустить внешнюю программу и забрать ее stdout? (запустить, вероятно, через WinExec или CReateProcess?) ... |
|||
:
Нравится:
Не нравится:
|
|||
11.01.2005, 18:57 |
|
DB2: Коннект к удаленному серверу из хранимой процедуры на C (Си)
|
|||
---|---|---|---|
#18+
Во-во. Столько усилий вместо того, чтобы сделать что-нибудь банальное: создать на другом сервере view и прицепить к своему (federated database), или воспользоваться репликацией или даже средствами warehouse. По моему очень нескромному мнению, использовать SP - это [вырезано самоцензурой]. Короче, [вырезано самоцензурой]. Эти "политики", определяющие "корпоративную политику", [вырезано самоцензурой], потому что [вырезано самоцензурой]. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.01.2005, 01:47 |
|
DB2: Коннект к удаленному серверу из хранимой процедуры на C (Си)
|
|||
---|---|---|---|
#18+
Ну.. конечно же приятно было бы иметь возможность и процедуры удаленно запускать. SQL Server, Sybase это позволяют делать. Да и рекордсет брать - тоже. На счет процесса скажу что нужно рыть в MSDN в сторону CreateProcess и CreatePipe. (в винде с каналами работать потяжелее чем в линуксах). Вообще-то ИБМ неплохо было бы влупить стандартную какую-нить табличную функцию чтоб можно было запускать таким образом процесс на сервере и получать его стандартный выход. Хотя честно говоря дело рискованное))) такая дыра...)) А в принципе можно так, если с каналами не получится: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11.
или передавать имя файла процессу. потом взять файл и сделать с ним что угодно - например передать через табличную функцию или запихнуть во временную табличку. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.01.2005, 09:10 |
|
DB2: Коннект к удаленному серверу из хранимой процедуры на C (Си)
|
|||
---|---|---|---|
#18+
Victor MetelitsaВо-во. Столько усилий вместо того, чтобы сделать что-нибудь банальное: создать на другом сервере view и прицепить к своему (federated database), или воспользоваться репликацией или даже средствами warehouse. Ну я уже объяснил, что тут дело не столько в корпоративной политике, сколько в том, что сервер, с которого забирается информация, не наш. Там есть процедура и нам разрешено ее запускать. С SQL сервер подобных проблем не возникало. Victor Metelitsa По моему очень нескромному мнению, использовать SP - это [вырезано самоцензурой]. Я вот кстати не первый раз слышу негатив про SP и хочется узнать - на чем он основан? По моему опыту на MS SQL (кстати и на DB2 Тоже - мы тут дали доступ к базе разработчикам на EJB под WebSphera - так они нас просто заеджебали потом. Потому что элементарно при неправильных результатах непонятно - у них ошибка или это такие данные неправильные) очень удобно со стороны базы делать SP и делегировать права на их запуск некоему webuser. После этого всегда можно _быстро_ отловить, например, ошибку - достаточно запустить процедуру из любого другого клиента. Да логических ошибок на клиенте и не возникает - просто потому, что за логику формирования ресальтсета отвечает одно подразделение ( а обычно вообще - один человек). И при отдаче данных сторонним организациям тоже - мы давали доступ к вьюхам. После того как несколько раз нам нагрузкой "положили" сервер (ну просто ребята решили всю таблицу каждые 15 минут перегружать) мы им выдали процедуру и теперь они ее чаще, чем через 30 минут не могут запускать. Не говоря уже о том, что планы статических запросов для процедуры создаются и проходят через оптимизатор один раз, что в некоторых задачах помогает ускорить выполнение задачи раза в два например. А вот про минусы не слышал... за исключением того факта, с которым сам столкнулся - производители серверов не хотят считать, что процедура возвращает табличные данные (в связи с чем приходится несколько извращаться), а некоторые производители даже, похоже, считают, что процедура не может быть источником данных для заполнения таблиц. А если у меня на удаленном конце вообще нечто не табличное и не реляционное, но с возможностью вызова процедуры, которая табличный датасет возвращает? ... |
|||
:
Нравится:
Не нравится:
|
|||
12.01.2005, 09:55 |
|
DB2: Коннект к удаленному серверу из хранимой процедуры на C (Си)
|
|||
---|---|---|---|
#18+
Metelitsa Во-во. Столько усилий вместо того, чтобы сделать что-нибудь банальное: создать на другом сервере view и прицепить к своему (federated database), или воспользоваться репликацией или даже средствами warehouse. По моему очень нескромному мнению, использовать SP - это [вырезано самоцензурой]. Короче, [вырезано самоцензурой]. Эти "политики", определяющие "корпоративную политику", [вырезано самоцензурой], потому что [вырезано самоцензурой]. хм... а если sp - источник данных на удаленном сервере не просто select * from table? Да еще кроме гранта на вызов больше ничего нет? Не хочу разводить в offtopic демагогию о пользе/непользе sp, однако до сих пор товарищи (с кем я общался), заявлявшие подобное (то, что вырезано самоцензурой) про sp, просто не умели их готовить :) ... |
|||
:
Нравится:
Не нравится:
|
|||
12.01.2005, 09:58 |
|
DB2: Коннект к удаленному серверу из хранимой процедуры на C (Си)
|
|||
---|---|---|---|
#18+
gardenman А в принципе можно так, если с каналами не получится: (скип) потом взять файл и сделать с ним что угодно - например передать через табличную функцию или запихнуть во временную табличку. Нет, с файлом совсем не вариант, тогда уж проще в таблицу закачивать... если только проще - я еще не пробовал, получиться ли в программе сделать два коннекта к разным базам одновременно. Наверняка и тут ограничили! :( ... |
|||
:
Нравится:
Не нравится:
|
|||
12.01.2005, 10:01 |
|
|
start [/forum/topic.php?fid=43&startmsg=32837166&tid=1606011]: |
0ms |
get settings: |
10ms |
get forum list: |
16ms |
check forum access: |
5ms |
check topic access: |
5ms |
track hit: |
41ms |
get topic data: |
14ms |
get forum data: |
3ms |
get page messages: |
70ms |
get tp. blocked users: |
2ms |
others: | 278ms |
total: | 444ms |
0 / 0 |