Вызов хранимой процедуры SQL2005 Express

[Mirra88]

Есть хранимая процедура (pPolsq) на SQL 2005 Express с одним, в процедуре же и инициализируемом, параметром (Inicials):
 

Код:

USE [tatApril11]
 Declare @Inicials nvarchar(35)
 Set @Inicials='ИВАНОВ В И'
 SELECT Distinct mibAPAC.FAM, mibAPAC.Mes  Where mibAPAC.FAM=@Inicials;
return 

В SQL Server Management Studio Express процедура выполняется без проблем, когда же я пытаюсь в Builder6 из компонента  ADOQuery вызвать её сформировав строку запроса вот так:

Код:

select * from pPolsq()

то выходит ошибка: "Недопустимое имя объекта "pPolsq"". Никакие переименования процедуры не помогают. А вот если вместо имени процедуры поставить имя любой таблицы той же SQL-базы, то всё выполняеься прекрасно. Мне кажется, что всё дело в синтаксисе вызова процедуры, но найти правильный не могу. Подскажите, пожалуйста, кто знает.
 

[Dale]

В SQL Server Management Studio Express процедура выполняется без проблем, когда же я пытаюсь в Builder6 из компонента  ADOQuery вызвать её сформировав строку запроса вот так:

Код:

select * from pPolsq()

то выходит ошибка: "Недопустимое имя объекта "pPolsq"". Никакие переименования процедуры не помогают. А вот если вместо имени процедуры поставить имя любой таблицы той же SQL-базы, то всё выполняеься прекрасно.

А в самой SQL Server Management Studio Express запрос

Код:

select * from pPolsq()

срабатывает?

[Mirra88]

Нет. И сама среда SQL Server Management Studio Express выдаёт точно такую же ошибку. Но ведь в SQL Server Management я запускаю процедуру просто введя её имя и нажав "Выполнить". В Builder так не получиться, у него другой синтаксис. Видимо синтаксис Builder не работает в в SQL Server Management, и наоборот..

[Dale]

Нет. И сама среда SQL Server Management Studio Express выдаёт точно такую же ошибку.

И правильно выдает. Потому что из результата хранимой выборки нельзя выбирать данные через select. Такая конструкция не будет работать ни в одной среде, включая и Builder, разумеется.

Почитайте внимательнее раздел справки, посвященный оператору TSQL SELECT.

[Mirra88]

Этот синтаксис (select * from pPolsq()) я плавно перенесла из InterBase. Т. е. была работающая программа, где таким образом вызывалась хранимая процедура сервера InterBase. Но что срабатывало на InterBase, не сработало на SQL2005. Тогда можно-ли табличку-результат выполнения хранимой процедуры SQL2005, вообще вызвать с помощью компонента ADOQuery? Наверное можно, раз с InterBase это получается.. Только каким-то другим образом..

[Dale]

Я уже плоховато помню работу с ADO, лет этак 10 назад перешел на ADO.NET.

Насколько смутно припоминаю, там нужно было использовать объект Recordset, который является результатом выполнения хранимой процедуры. А из него уже извлекать данные методами навигации. Хотя это с использованием чистых ADO, а что поверх них навертел Борланд, я даже не представляю.

[Dimka]

Mirra88, стоит различать такие вещи, как функция, возвращающая табличное значение, и хранимая процедура. Хранимые процедуры никогда не вызывались таким образом, всегда только через EXECUTE. Если хранимая процедура возвращает табличный результат, его (если надо) через особую форму INSERT можно вставить во временную таблицу (для обработки в другой процедуре). Ты же используешь синтаксис для вызова функции.

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

Код: (Text)

exec pPolsq

разумеется, текущая база данных должна быть указана правильно.

[Mirra88]

Ура, спасибо всем, кто мне помог, вывести результат хранимой процедуры получилось. А вышла я из положения так, вначале на SQL-сервере создала процедуру (pLocTabl) вот такого содержания:

Код:

USE [tatApril11]
 Declare @Inicials nvarchar(35)
 Set @Inicials='ИВАНОВ В И'
 SELECT Distinct mibAPAC.FAM, mibAPAC.Mes 
 INTO #LocTable  
 Where mibAPAC.FAM=@Inicials;
return

(т. е. использовала временную таблицу LocTable)
А потом вот таким образом вызвала её в Builder:
 

Код:

ADOQuery1->Close();
 ADOQuery1->SQL->Text = "exec pLocTabl";
 ADOQuery1->Open();

Выполняется, конечно, подольше, чем на самом сервере, но, кажется будет всё же быстрее, чем если бы запрос формировать из самого Builder, без хранимой процедуры (а я всё это делаю именно из-за скорости, очень медленно работает база). Осталось только научиться входить в процедуру вводя параметр из Builder и поэкспериментировать с временными табличными переменными (вдруг-да будет ещё быстрее, чем со временными таблицами).
Но один момент всё-таки очень сильно меня тревожит. Хорошо, сейчас я села на локальную машину и всё что мне надо вывела. Но в реальности с базой работает множество пользователей, да ещё и фамилия у каждого будет вводиться своя (тут у меня для всех 'ИВАНОВ В И').   Как сделать так, чтобы каждый получал свою временную таблицу, со своими параметрами-фамилиями? Автоматически же так не получиться? А ещё, если каждый из пользователей будет создавать с каждым запросом свою временную таблицу, то не замедлит-ли, не нагрузит-ли это SQL-cервер, в результате чего я "от чего уйду, к тому и приду", не получив выигрыша в скорости? Оптимален-ли вариант с временными таблицами?

[Dale]

Оптимален-ли вариант с временными таблицами?

Однозначно - НЕТ. Это лишь попытка кое-как выкрутиться, лишь бы не разбираться с корректным решением.

Гораздо рациональнее вместо временных таблиц воспользоваться табличными функциями, которые реализованы в T-SQL 2005. Если хотите более универсальное решение (поскольку табличные функции имеются не на всех СУБД и не во всех версиях), то либо научитесь считывать результат выполнения хранимой процедуры (через Recordset), либо создайте параметризованный запрос (через Command).

[x77]

Этот синтаксис (select * from pPolsq()) я плавно перенесла из InterBase.

вы бы привели текст самой хранимой процедуры. потому что "плавно" хранимку из ИБ в сиквел перенести невозможно, синтаксис не позволит. а исходя из задач, решаемых вашей хранимкой, вам подскажут оптимальные решения. разговор станет более предметным

[Mirra88]

Да конечно, саму хранимку плавно перенести нельзя, я плавно перенесла только ТЕКСТ ВЫЗОВА хранимки, а именно свойство SQL компонета ADOQuery (select * from pPolsq()). А мне и не нужна была та хранимка InterBase, я просто на её примере хотела научиться запускать любые хранимки. Но даже и это не получилось. Может быть потому, что InterBase создаёт временные таблицы сама, не знаю.. А текст нужной мне (создаваемой..) хранимой процедуры я привела:

Код:

USE [tatApril11]
 Declare @Inicials nvarchar(35)
 Set @Inicials='ИВАНОВ В И'
 SELECT Distinct mibAPAC.FAM, mibAPAC.Mes 
 INTO #LocTable  
 Where mibAPAC.FAM=@Inicials;
return

Но это не окончательная хранимка. Мне надо, чтобы параметр - "ФИО"  вводился бы пользователем через форму Builder6, передавался в хранимку SQL2005, а результат-выборка данных из нескольких таблиц о введённом "ФИО" выводился бы снова в Builder6-форму этого пользователя многопользовательского приложения. И чтоб всё это максимально быстро работало! СКОРОСТЬ - ЭТО САМОЕ ГЛАВНОЕ. Вот над этим над всем я сейчас и работаю.

[x77]

СКОРОСТЬ - ЭТО САМОЕ ГЛАВНОЕ

меняйте логику. самым быстрым будет параметрический поиск по ключевому полю. следовательно:

1. перед поиском надо дать пользователю окошко с возможностью выбора ФИО
2. запомнить ID этого ФИО
3. заюзать однонаправленный датасет для выборки по параметрическому запросу
4. показать результаты пользователю в лист-вью или стринг-гриде или любом другом non db-aware контроле (ибо db-контролы однонаправленный датасет заюзать не дадут.

[Mirra88]

Я не сильна в программистком слэнге, поэтому половина не поняла. Что значит "ЗАЮЗАТЬ"? Что значит "non db-aware контрол", "db-контрол"?

[x77]

применительно к Билдеру, db-aware контролы - это контролы, начинающиеся с префикса DB: DBEdit, DbGrid и т.д. все эти контролы (элементы управления) в борландовских продуктах используют внутренние буфера. даже если вы работаете через ADO, для обеспечения совместимости с этими элементами управления, ADOQuery все равно наследуется от TDataSet. а вся эта буферизация на порядок тормозит скорость отображения данных, а в некоторых случаях - и скорость выборки. поэтому делать быстро - это значит отказаться от борландовских костылей в виде их элементов управления и их источников для доступа к данным.

следовательно, самым быстрым будет вызов через ADOCommand (наследник от TComponent, а не от TDataSet). но результирующую выборку нельзя будет засунуть в DbGrid, поэтому придется использовать обычные компоненты - StringGrid, ListView.

[Mirra88]

Спасибо.

[Dimka]

Mirra88, "заюзать" от английского to use (использовать). В данной коннотации одновременно означает как совершенный вид глагола (результат экспериментального применения), так и несовершенный вид (способ решения аналогичных задач в будущем на основании результатов успешного экспериментирования). Это выражает специфику разработки ПО - сложно найти решение, легко его повторно использовать. Но то, что лего использует один программист, для другого требует некоторых усилий по освоению и опробации, поэтому глагол "использовать", хотя и синонимичен, не вполне соответствует смыслу "заюзать".

"DB-контрол" от английского "database control" - элемент управления, обеспечивающий работу с базой данных. В терминах RAD-систем control - элемент визуального проектирования, помещаемый на форму с целью придать форме дополнительные свойства, реализуемые данным элементом, а также объект манипулирования этими свойствами. DB-controls обычно предоставляют API для доступа к элементам базы данных, обеспечивают прозрачную для программиста работу с гетерогенными и удалённым источниками данных, нередко осуществляют кэширование данных в приложении (держат в памяти результаты запросов), служат источниками данных в binding на визуальные элементы управлеиня, ответственные за отображение данных пользователю, либо же совмещают в себе операции над данными и отображение их пользователю.

[Mirra88]

Спасибо

[x77]

<..> служат источниками данных в binding<..>

Dimka, осталось рассказать, что такое binding, попутно обрисовав логику model-view-controller

Добавлено через 12 минут и 3 секунды:
Mirra88, не пугайтесь, для начала это все знать не надо достаточно написать запрос, возвращающий нужные данные по ID пользователя, и добиться того, чтобы он отработал в TAdoCommand. потом прикрутить экспорт данных из ADOCommand куда-нибудь, для начала - хоть в Memo. потом сделать запрос параметрическим и нарисовать форму, для получения параметра (т.е. выбор ID по фамилии).

дальше можно оптимизировать дальше, например, запрос обернуть в функцию, и т.д.

Добавлено через 15 минут и 8 секунд:
и еще три копейки вдогонку. обычного такого рода оптимизации на скорость требуются в весьма и весьма конкретных случаях. штатно все это прекрасно работает через обычные ДБ-гриды и обычные датасеты. если при этом база тормозит, в большинстве случаев это означает, что оптимизировать надо логику работы с базой, а не средства доступа к данным из этой базы.

если вы просто экспериментируете, то в чем заключается цель эксперимента? что потом надо делать с этими данными (менять, удалять, добавлять, просматривать, печатать, экспортировать)?

[Mirra88]

В чём заключается цель эксперимента? На данный момент я сопровождаю реальную программку (что с ней будет дальше - сказать сложно), которая содержит сразу две базы - Кларион (файлы tpc-формата) и SQL-сервер базы. Частично две базы дублируют друг-друга (вначале была только Кларион-база, год назад в силу ряда причин разработчики решили перевести её в SQL-формат, в итоге сейчас мы имеем две базы). Само приложение управляющее обоими базами написано в среде Кларион. В этом приложении ряд дублирующих друг-друга кнопок - одна запускает работу с Кларион-базой, другая - с SQL. SQL часть работает очень медленно (кларионовская - быстро), и если нет возможности выполнить работу в кларион-дубле, то "стонут" все пользователи. Причём скорость падает с ростом объёма базы (на копии, в качестве эксперимента, я удалила треть данных SQL-базы и база стала открываться не за 45, а за 5 секунд). Я не могу понять почему так! Сами разработчики не могут понять. На Кларионе я, конечно, программировать уже не смогу (слишком мало литературы и слишком низка востребованность этого языка), но, поскольку моя цель всё-таки программировать и, я надеюсь, что может даже смогу найти на этой стезе в дальнейшем работу, то эту РЕАЛЬНУЮ ситуацию я пытаюсь интерполировать на Builder, чтоб понять с какой скоростью будет работать та же самая база у меня на Builder и от чего вообще зависит эта скорость. Доподлинно знаю, что хранимые процедуры разработчики той реальной "двойной" базы не используют. Но когда я попыталась открыть самую большую таблицу просто средствами ADOBuilder, то она и у меня открывалась медленно. Поэтому я решила поэкспериментировать с процедурами. Ещё и с TAdoCommand поэкспериментирую, возможно, ещё с чем-то. Если мои эксперименты окажутся удачными, тоесть мне удастся работать с этой базой на Builder быстро, то я не знаю, что я буду делать с результатами этого эксперимента. Возможно с разработчиками поговорю. А возможно, что организация в которой я работаю от этого приложения откажется (и от меня заодно, потому что моя работа заключается в основном в его сопровождении) и тогда я уже не смогу ни с кем поговорить. Но в любом случае эти "эксперименты" дают мне знания, которые, как известно, лишними не бывают!

[x77]

Но когда я попыталась открыть самую большую таблицу просто средствами ADOBuilder, то она и у меня открывалась медленно.

а как вы пытаетесь ее открыть?

1. какой компонент доступа: ADOTable, ADOQuery, ADOCommand, ADODataset?
2. сколько полей и записей в этой таблице?
3. есть ли в этой таблице blob-поля?


Добавлено через 3 минуты и 31 секунду:

я удалила треть данных SQL-базы и база стала открываться не за 45, а за 5 секунд)

а если база вырастет в 10 раз? такое поведение программы говорит о кривой логике работы с БД. за минуту SQL-сервер может отдать десятки (если не сотни) тысяч записей, ни один человек не в состоянии работать одновременно с таким массивом информации. такие запросы просто не нужны (и вредны). давайте попробуем продумать логику доступа к вашим данным, только сначала опишите их. это справочные таблицы или операционные, что в них хранится, кто эти данные заполняет, кто читает, как часто и т.д.

[Mirra88]

Данные медицинские. Поэтому таблицы там очень большие (посещения и рецепты пациентов за много лет и т. д. и т. п. подобного характера). Естественно, что так как люди активно посещают медицинские учреждения ежедневно, то таблицы интенсивно используются и пополняются ежедневно множеством операторов. Даже на самом SQL-сервере одна из таблиц содержащая более 700000 записей открывалась несколько минут. Понятно, что и на Builder c использованием компонента ADOTable1 она тоже открылась не быстро. Там ведь в этих табличках, кроме очень большого количества записей, ещё и полей около сотни.

[x77]

Mirra88, скажите мне, как художник - художнику. зачем пользователю в отдельно взятый момент времени 700 тысяч записей со 100 полями? что он будет с ними делать? если одну запись со 100 полями он в состоянии осмыслить за одну минуту, то на осмысление 700 000 записей у него уйдет примерно полтора года.

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

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

но даже на существующей БД с 700 000 полей сделать такой интерфейс, на котором все будет летать - вполне реально. не вытаскивать все записи, а выдавать форму поиска, максимум по 10-20 полям, и выводить только записи, удовлетворяющие условиям из 10-20 полей. после выбора нужной записи - вытаскивать все поля (100 или сколько там) но уже только по конкретной записи. блоб-поля вытаскивать отдельно по мере обращения к ним. если выборка 100 полей одной записи тоже тормозит - значит, разделить поля на логические группы и работать с ними на отдельных вкладках, запрашивая из БД по мере необходимости.

ну и т.д.

[Mirra88]

Так я же и не пытаюсь больше открывать целую таблицу.. Я теперь пытаюсь сформировать запросы из разных таблиц на конкретного пациента. К примеру пришли Вы к врачу и врач вводит Вашу фамилию, а там сразу и числа всех Ваших предыдущих посещений с диагнозами и именами врачей. Всё это выбирается из разных таблиц, но в нашей базе это тоже происходит медленно.. Я хочу попробовать, чтобы быстро.

[x77]

а можно пример запроса, выбирающего данные из разных таблиц, который медленно работает?

Добавлено через 1 минуту и 37 секунд:
судя по USE [tatApril11], данные по посещениям за месяц хранятся в разных таблицах? т.е. на каждый новый месяц заводится новая таблица?

[Mirra88]

Я не могу привести пример запроса, потому что запросы скомпилированы в exe-файл разработчиков. Я не вижу текстов запросов, разработчики текстов своих программ нам не раздают. А что касается названия базы, так это моё название. Я не могу экспериментировать на работающей базе, поэтому в апреле сделала себе копию. А вообще в этой базе вместе хранятся данные за много лет, в одних и тех же таблицах, не заводится новая таблица с новым месяцем.

[x77]

ура, уже хорошо. значит, есть минимум две таблицы: "Пациенты" и "Посещения", со связью один-ко-многим, правильно я понимаю? и куча вспомогательных таблиц?

[Mirra88]

Да, наверное. В связях я как-то не разбиралась, потому что таблиц много, а в каждой очень много полей с непонятными названиями и назначением. Поэтому я разобралась в сути нескольких полей и таблиц, вот с ними и экспериментирую

[x77]

mibAPAC - это справочник пациентов? FAM - это поле с ФИО? если да - сколько занимает выполнение запроса

Код:

select FAM
from mibAPAC

?

[Mirra88]

Около 20 секунд (на SQL-сервере) с выводом введённой мною фамилии около 700000 раз

Добавлено через 4 минуты и 59 секунд:
Но ведь на скорость в программе играет роль не только скорость самой выборки, пользователю открывается clarion-форма, он чего-то там меняет, закрывает форму. На это открытие-закрытие почему-то тоже уходит много времени (в зависимости от размера SQL-базы)

[x77]

с одной и той же? т.е. вы другой запрос выполняете? или в таблице реально во всех записях одинаковая фамилия лежит?

не может SQL 20 секунд вытаскивать одно поле из одной таблицы. даже если в ней за пол-миллиона записей.

Добавлено через 2 минуты и 11 секунд:

Но ведь на скорость в программе играет роль не только скорость самой выборки, пользователю открывается clarion-форма, он чего-то там меняет, закрывает форму. На это открытие-закрытие почему-то тоже уходит много времени (в зависимости от размера SQL-базы)

там возможны варианты. множественные обновления подчиненных таблиц, тяжелые триггера, и др. давайте пока с отображением данных (т.е. с выборкой ) разберемся.

Добавлено через 4 минуты и 45 секунд:
з.ы. я пропаду скоро, до завтрашнего дня, поэтому промежуточный итог.

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

Код:

select count (123) 
from MyTable

,

убедиться, что он отрабатывает, как и положено SQL Express, за пару десятков миллисекунд, и если да - то дальше оптимизировать запросы под уже непосредственно работу с данными через билдер.

если такой запрос выполняется более нескольких секунд - разбираться с базой.

запросы проверять не в самом билдере, а в профайлере или в менеджмент-студии.