|
-23197 при вставке из процедуры в таблицу в другой базе
|
|||
---|---|---|---|
#18+
Платформа 2008R2x64, 11.50FC9. Надо сделать связку двух проектов. Каждый использует свою базу, обе базы на одном сервере. Первая база DB_LOCALE=ru_ru.1251, вторая ru_ru.utf8 Суть в том, что при обработке данных процедурой в первой базе в некоторых случаях надо создавать записи во второй базе. Внутри процедуры есть код Код: sql 1. 2. 3.
Если условие выполняется, при попытке вставки получается -23197 Если вставка не происходит - все работает. Процедура вызывается из СИшного приложения с CLIENT_LOCALE=ru_ru.1251 через odbc как execute procedure procname(params); Как победить эту ситуацию? Кстати, если мне не изменяет память, раньше подобные insert-ы использовались и проблем не возникало, но давно это было и я уже не помню деталей, хотя точно помню что с тех пор не один апгрейд информикса был поставлен и может в этой версии что-то поменяли в этой части... ... |
|||
:
Нравится:
Не нравится:
|
|||
20.12.2012, 00:46 |
|
-23197 при вставке из процедуры в таблицу в другой базе
|
|||
---|---|---|---|
#18+
Неужели никто не использует insert into anotherDB:sometable() ? ... |
|||
:
Нравится:
Не нравится:
|
|||
20.12.2012, 14:03 |
|
-23197 при вставке из процедуры в таблицу в другой базе
|
|||
---|---|---|---|
#18+
falcon111Неужели никто не использует insert into anotherDB:sometable() ? Ну почему же не использует. Ошибка -23197 вам явно указывает на не соответствие DB_LOCALE. Для первой, к которой подключаетесь, базы вы используете DB_LOCALE=ru_ru.1251, CLIENT_LOCALE=ru_ru.1251 При вызове insert into anotherDB:sometable() происходит неявный коннект ко второй базе у которой DB_LOCALE=ru_ru.utf8. Если программа написана на ESQL/C , то я бы сделал два явных коннекта и где надо переключался бы SET CONNECTION. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.12.2012, 15:04 |
|
-23197 при вставке из процедуры в таблицу в другой базе
|
|||
---|---|---|---|
#18+
Ikirfalcon111Неужели никто не использует insert into anotherDB:sometable() ? Ну почему же не использует. Ошибка -23197 вам явно указывает на не соответствие DB_LOCALE. Для первой, к которой подключаетесь, базы вы используете DB_LOCALE=ru_ru.1251, CLIENT_LOCALE=ru_ru.1251 При вызове insert into anotherDB:sometable() происходит неявный коннект ко второй базе у которой DB_LOCALE=ru_ru.utf8. Если программа написана на ESQL/C , то я бы сделал два явных коннекта и где надо переключался бы SET CONNECTION. Вы не совсем поняли, я же не в С-программе занимаюсь обработкой данных, а в процедуре. И коннект ко второй базе происходит внутри SPL-процедуры, а не из СИшного приложения, поэтому второй коннект тут не поможет. А при обращении из SPL от одной базы к другой в пределах одного сервера, как мне кажется, сервер сам должен заниматься перекодированием, ru_ru.1251 и ru_ru.utf8 совместимы и проблем вызывать не должны. Да и вставка там идет - одни интежеры, которые, по-хорошему, и перекодировать-то не надо. Вообще все это напоминает мне косяк версий в районе 11.50xC3, где с этой же ошибкой не работал автоапдейт статистики (точнее сам шедулер), тоже там что-то такое было при работе между разными базами, но с тех пор должны были все это починить... ... |
|||
:
Нравится:
Не нравится:
|
|||
20.12.2012, 15:18 |
|
-23197 при вставке из процедуры в таблицу в другой базе
|
|||
---|---|---|---|
#18+
falcon111, Вставка тут ни причем. Такую же ошибку вы получите выполнив SELECT count(*) FROM anotherDB:sometable ... |
|||
:
Нравится:
Не нравится:
|
|||
20.12.2012, 15:44 |
|
-23197 при вставке из процедуры в таблицу в другой базе
|
|||
---|---|---|---|
#18+
Ikirfalcon111, Вставка тут ни причем. Такую же ошибку вы получите выполнив SELECT count(*) FROM anotherDB:sometable Т.е. это не косяк автоперекодировки а фича? И объехать ее без костылей никак? ... |
|||
:
Нравится:
Не нравится:
|
|||
20.12.2012, 15:47 |
|
-23197 при вставке из процедуры в таблицу в другой базе
|
|||
---|---|---|---|
#18+
falcon111Ikirfalcon111, Вставка тут ни причем. Такую же ошибку вы получите выполнив SELECT count(*) FROM anotherDB:sometable Т.е. это не косяк автоперекодировки а фича? И объехать ее без костылей никак? Я бы попробовал убрать CLIENT_LOCALE. И DB_LOCALE на стороне сервера тоже. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.12.2012, 21:39 |
|
-23197 при вставке из процедуры в таблицу в другой базе
|
|||
---|---|---|---|
#18+
Выбегаллоfalcon111пропущено... Т.е. это не косяк автоперекодировки а фича? И объехать ее без костылей никак? Я бы попробовал убрать CLIENT_LOCALE. И DB_LOCALE на стороне сервера тоже. Не поможет. Вариант с разными локалями работать не будет. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.12.2012, 00:22 |
|
-23197 при вставке из процедуры в таблицу в другой базе
|
|||
---|---|---|---|
#18+
Leonid BelovВыбегаллопропущено... Я бы попробовал убрать CLIENT_LOCALE. И DB_LOCALE на стороне сервера тоже. Не поможет. Вариант с разными локалями работать не будет. Мне смутно помнится, я с этим боролся когда база для HPLoader-а была в одной кодировке, а основная база - в utf8... Надо будет поковыряться. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.12.2012, 00:04 |
|
-23197 при вставке из процедуры в таблицу в другой базе
|
|||
---|---|---|---|
#18+
Выбегалло, Мне кажется, что вариант с разными локалями работоспособен, только если работа ведется внешним клиентом, а не изнутри сервера (как это происходит в случае хранимой процедуры). Клиент может установить два соединения - каждое со своей базой и соответственно со своими настройками кодировок, - и гонять данные через себя. Я что-то подобное делал - правда, только на Java, где локаль указывается в URL каждого подключения. С ESQL-C не экспериментировал. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.12.2012, 09:27 |
|
-23197 при вставке из процедуры в таблицу в другой базе
|
|||
---|---|---|---|
#18+
Leonid Belov, не не кажется. Чтобы работать с двумя базами из одного соединения надо чтобы локали базы были одинаковы. Вариант с внешним приложением и двумя JDBC коннекциями самый рабочий. Ну есть еще грабли когда с одной стороны UTF, а с другой 866, но это решается фильтрацией. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.12.2012, 11:48 |
|
-23197 при вставке из процедуры в таблицу в другой базе
|
|||
---|---|---|---|
#18+
cprНу есть еще грабли когда с одной стороны UTF, а с другой 866, но это решается фильтрацией. Про фильтрацию поясните пожалуйста. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.12.2012, 18:47 |
|
-23197 при вставке из процедуры в таблицу в другой базе
|
|||
---|---|---|---|
#18+
bk0010cprНу есть еще грабли когда с одной стороны UTF, а с другой 866, но это решается фильтрацией. Про фильтрацию поясните пожалуйста. Некоторые UTF-8 символы при попытке вставки строки char в БД с локалью 866 приводили к зависанию jdbc соединения, ошибка при этом не возникала. Пришлось писать на java фильтры , которые удаляли из строки UTF-8 то, что не может быть преобразовано в 866. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.12.2012, 17:15 |
|
|
start [/forum/topic.php?fid=44&msg=38086979&tid=1607088]: |
0ms |
get settings: |
27ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
87ms |
get topic data: |
11ms |
get forum data: |
2ms |
get page messages: |
359ms |
get tp. blocked users: |
2ms |
others: | 284ms |
total: | 793ms |
0 / 0 |