Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
||
ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
[3.139.239.67] |
|
Сообщ.
#1
,
|
|
|
Всем здравствуйте!
Самопальная программа (RAD Studio 2010, C/C++, ADO-компоненты) через ODBC-источник соединена с БД. select count(*) from metadata -> 515880 - OK! select id, guid, title, alt_title from metadata order by id -> OK (и 515880 записей в результате). select * from metadata order by id -> маловразумительное сообщение Объект был открыт! При запросе на сервере из MS SQL server Management Studio - всё ОК... Чё делать-то? --- Похоже, надо было в разделе Билдера постить... Модераторы, перенесите пожалуйста тему. --- Или есть какие-то нюансы при создании ODBC-источника данных? Там настолько косячный диалог (особенно после Oracle)! --- Подключился через MS OLE DB Provider for SQL Server - то же самое... |
Сообщ.
#2
,
|
|
|
Цитата #SI# @ select * from metadata order by id -> маловразумительное сообщение Объект был открыт! Если соединение ADO закрыть , открыть и запустить запрос что получис в результате? А также свойство курсора хотелось бы знать. |
Сообщ.
#3
,
|
|
|
Цитата Bas @ То же самое. Кстати, пару раз вместо Объект был открыт вышло Недостаточно памяти.Если соединение ADO закрыть , открыть и запустить запрос что получис в результате? Цитата Bas @ Виктор!!! Ты - гений!!! Поменял CursorLocation у коннекта и квери на clUseServer - и заработало!!!А также свойство курсора хотелось бы знать. Добавлено |
Сообщ.
#4
,
|
|
|
Столкнулся с аналогичной проблемой, но с MS SQL. Гуглинг нынче вывел не только сюда, но и на пару других сайтов. Итого:
Здесь вот пишут, что помогло поменять CursorLocation у коннекта и квери на clUseServer В http://www.sql.ru/forum/353795-2/ado-i-obekt-byl-otkryt подключение было к Oracle, помогло пересаживание с ADO на DOA и выключение QueryAllRecords в False И в http://www.delphikingdom.com/asp/answer.asp?IDAnswer=75203 наконец-то пишут, что проблема с исчерпанием файла подкачки на клиенте, что покрывает и первые два случая, и всё объясняет. |
Сообщ.
#5
,
|
|
|
За запросы вида "select * from ..." надо увольнять с волчьим билетом
|
Сообщ.
#6
,
|
|
|
Цитата Gonarh @ За запросы вида "select * from ..." надо увольнять с волчьим билетом Осталось добавить "потому, что ...". Ага? |
Сообщ.
#7
,
|
|
|
Роман давно бы эту некрофилку прикрыл...
ЗЫ - вопрос я задал 2 года назад. И тогда же Виктор мне ответил. |
Сообщ.
#8
,
|
|
|
Цитата Gonarh @ За запросы вида "select * from ..." надо увольнять с волчьим билетом Вы максималист ..., однако. |
Сообщ.
#9
,
|
|
|
Как за что? При апгрейте одной системы падает другая.
Например, приложение P1 использует коде SELECT * FROM Table1 JOIN Table2 ОN .... В Table1 есть поле Field1. Другой девелопер изменяет приложеnие P2 и добавляет поле Filed1 в Table2. SELECT t2.Filed1 FROM Table2 t2 код работает нормально.Приложение 2 проходит тестирование (Никто, конечно, не тестирует Приложение 1). После деплоймента P2 в живую систему Р1 падает, потому как в рекордсете 2 поля с одинаковым именем. |
Сообщ.
#10
,
|
|
|
|
Сообщ.
#11
,
|
|
|
Gonarh, серверные функции из сишных(паскальных етс...) приложений никогда не вызывал?
select * from table(lmm.new_atd.get_fo_list) А вот сама функция function get_fo_list return SF_DSF_TAB as begin select cast ( multiset ( select obj.adm_code_ss, gnn.geoname, null, null from gn.geoobject obj inner join gn.geoname gnn on gnn.reg_n = obj.reg_n and gnn.norm = 1 where obj.code_kind_geoobject = 229 and obj.actual = 1 order by obj.adm_code_ss ) as SF_DSF_TAB ) into lst from dual; return lst; end get_fo_list; |