Вызов хранимой процедуры 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, за пару десятков миллисекунд, и если да - то дальше оптимизировать запросы под уже непосредственно работу с данными через билдер.

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

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

[Mirra88]

Да, я выполнила этот запрос "select ФИО from MyTable", спасибо, действительно, он меньше секунды выполняется, а до этого я просто имя поля забыла указать. На Менеджмент-студии я его и выполняла, профайлер я тоже какой-то скачивала, но он был не совсем полноценный, там куча функций была не доступна.

[x77]

Да, я выполнила этот запрос "select ФИО from MyTable", спасибо, действительно, он меньше секунды выполняется

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

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

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

[Dimka]

Тут ещё важно, что такой запрос возвращает 700 тыс. записей. А зачем? Пора переходить к WHERE.

[x77]

Dimka, перечитай весь топик

[Dimka]

x77, топик я читал. Дело не в этом.

Дело в том, что существует система, и перенос данных в SQL Server был сделан как-то криво, или криво были реализованы операции над этими данными. Но это не решается программистскими средствами. Это решается с помощью программистских средств. Программирование - это ответ на вопрос "как?" А ещё есть вопросы "что?" и "зачем?" Ответы на эти два вопроса лежат в предметной области - в сфере, где люди вводят и запрашивают какую-то информацию для решения своих пользовательских задач.

Плясать нужно от предметной области, от того, что называется "бизнес-логикой". Тогда любая строчка кода обретёт смысл, и станет понятно, где нужно, а где лишнее, где неоптимальности.

Но это совсем другая тема и такое отвлечение от собственно баз данных, что я даже и не знаю, как бы подвести к этому Mirra88. А не подведя, нет большого смысла в том, что выборка по одному полю быстрее, чем по многим. Да, быстрее, но может полей нужно больше; да, медленнее, но может меньше полей нельзя. Самое грустное во всём этом то, что не только мы, но даже и сама Mirra88 не знает ответов на эти вопросы.

Но, естественно, я полностью согласен с тем, что 700 тыс. записей по 100 полей - это не те объёмы, на которых SQL Server тормозит на простых запросах. Сотни миллионов записей - вот тут уже могут быть проблемы при отсутствии индексов и при невдумчивых попытках выполнять JOIN нескольких таблиц в запросах. В данном случае тормозить могут лишь жёсткий диск и/или процесс передачи данных по сетям, если пытаться многим пользователям на любой чих передавать десятки, если не сотни Мб данных. Сам SQL Server на небольших объёмах может тормозить только в случае неграмотной организации транзакций или на очень навороченных запросах, включающих EXISTS и т.п. вещи, когда не справляется оптимизатор.

[Dale]

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

Если программа обращается к MS SQL, то вы можете запустить утилиту SQL Server Profiler и перехватить все запросы к серверу, а заодно и увидеть основную статистику их выполнения.

Кстати, 700.000 записей - это совершенно несерьезный объем для MS SQL, такое количество данных не должно вызывать никаких особенных трудностей и задержек при правильной организации данных. У меня несколько таблиц имеют около 2.000.000.000 записей каждая, и это не вызывает больших проблем в работе (правда, на сервере инсталлирован MS SQL 2008, но он вряд ли в тысячу раз производительнее, чем 2005).

[Mirra88]

Я сильно сомневаюсь, что дело в жёстком диске или в загруженности сети. В своё время в момент пиковых загрузок работала нестабильно не только эта программка, использующая 2 базы, но и другие программки, установленные на сервере. Помогло увеличение памяти сервера до 4Г (в 2раза), теперь SQL-сервер в спокойном состоянии занимает 1.5Г оперативки и всё работает стабильно. Но тогда стабильность действительно зависела от загруженности сети. Скорость же открытия-закрытия той же формы посещений от этой загруженности не зависит совершенно, я пробовала и вечером, когда никто не работает, и после перезагрузки сервера и даже локально. Скорость такая же медленная, помогает только уменьшение самой базы, а вернее количества записей таблицы (сам-то размер базы на диске не меняется). Если удалить треть записей, вот тогда связанные с этими записями clarion-формы работают существенно быстрее. Причём, если бы дело было в жёстком диске (а сервер у нас отнюдь не самый старый ни морально, ни физически), то проблема, наверное была бы только наша, но на то же самое жалуются и другие больницы, пользующиеся данной программкой. Опять же скорость открытия формы посещения конкретного пациента сильно зависит ОТКУДА её открыть. Если не с общей формы посещений, а из формы списка пациентов, то она открывается-закрывается быстро. Но список пациентов имеет явно меньше записей, чем список всех посещений по больнице! Т. е. я опять же упираюсь в количество записей таблицы, чем оно больше, тем скорость работы медленнее, независимо от загруженности сети (работа в сети вообще организована в терминальном режиме). Я не знаю с чем связано вот такое замедление работы скорости с увеличением базы (тут, скорее формы ввода-вывода медленно открываются-закрываются, а с чем это связано - с запросами или с чем-то ещё я пока не понимаю), может быть причина состоит в необходимости дублировать всё в обе базы (но тогда непонятна зависимость скорости работы с формой того же посещения пациента от того, откуда её открывать), может быть в чём-то ещё, но если бы всё было просто и ясно, то разработчики бы так не сделали, не назло же сами себе они работают. Тут вот именно что-то не срабатывает, есть какая-то проблема

[Dale]

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

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

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

[Mirra88]

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

[Dale]

Тогда запускайте SQL Server Profiler и ищите операции, которые сильно нагружают процессор и дисковый тракт. Нередки случаи, когда правильно построенные индексы повышают производительность базы в 100 и более раз.

[baldr]

Mirra88, а индексы есть в таблицах?

[Mirra88]

Да вот я ещё не очень сильна в среде Менеджмент-студия и сейчас разбираюсь где всё это можно посмотреть. На это потребуется некоторое время. Мне и самой сразу стало интересно есть ли там индексы и могу ли я их создать и безопасно поменять..

[Dimka]

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

Главный вопрос - кому, зачем и в какие моменты времени нужны на форме все посещения по больнице (как я понимаю, за всю историю больницы)?

где всё это можно посмотреть.

Каждая таблица в обозревателе объектов раскрывается как дерево - внутри есть папки, в которых находятся описания полей, индексов, триггеров и т.п. вещи.

[Mirra88]

Главный вопрос - кому, зачем и в какие моменты времени нужны на форме все посещения по больнице (как я понимаю, за всю историю больницы)?

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

[Dale]

открывается всё-равно долго. Может быть чтобы выйти на эти сегодняшние посещения просматривается вся база.. Не знаю..

Посмотрите планы выполнения своих запросов. Из них хорошо видно, какой механизм используется для выборки данных.

[Mirra88]

Запросы не мои. Они в ехе-файле разработчика и написаны не на SQL, а на Clarion. Следовательно я не имею возможности посмотреть их план.

[Dimka]

Mirra88, ты же говорила, что тормозит не Clarion, а SQL Server. На чём бы ни были написано приложение, оно всё равно генерирует запросы, которые посылаются на SQL Server из приложения. Про это и говорит Dale. Вместе с Management Studio у SQL Server есть другая программа - Profiler. Она перехватывает все запросы к серверу и собирает по ним статистику. С её помощью отследи, какие запросы идут к базе данных от клиентских приложений.

[Mirra88]

Я не знаю точно, что тормозит и почему. Однозначно могу сказать только то, что обращаясь к SQL-базе программа работает гораздо медленнее чем когда она же обращается к Clarion-базе. Это факт, с него я вчера начала. А всё остальное - это предположения и поиск истины. И мне уже тут такое море немеренное дали всяких хороших наводок к поиску этой истины (за что я очень благодарна участникам форума), что я её непременно должна найти! Например, сразу три человека посоверовали посмотреть индексы. Я их сейчас и изучала. По-правде говоря у меня сложилось впечатление, что с ними действительно что-то не то. Сама я построила бы их совсем по другому. Может быть это, наоборот, от моего незнания. Но ведь у меня же есть копия базы и возможность экспериментировать! Я думаю, что подсказки со стороны участников форума истину найти мне помогут. И вот тогда я смогу сделать утверждение в чём собственно было дело и что являлось причиной медленной работы, Clarion, SQL-сервер или что-то ещё. Пока же я могу только предполагать.

[x77]

Mirra88, ты же говорила, что тормозит не Clarion, а SQL Server. На чём бы ни были написано приложение, оно всё равно генерирует запросы, которые посылаются на SQL Server из приложения. Про это и говорит Dale. Вместе с Management Studio у SQL Server есть другая программа - Profiler. Она перехватывает все запросы к серверу и собирает по ним статистику. С её помощью отследи, какие запросы идут к базе данных от клиентских приложений.

по-моему, в Экспрессе нет родного профайлера.

[Mirra88]

Да, в нём действительно нет родного профайлера, как и многих других функций и программок про которые я читала (облизываясь) в книге про SQL2005. Там нет агента, планировщика и ещё много-много чего. Но я скачала какой-то профайлер, который работает и на express. Но от скачанного мною профайлера мало толку, там очень много функций недоступно.

[HandKot]

Да, в нём действительно нет родного профайлера, как и многих других функций и программок про которые я читала (облизываясь) в книге про SQL2005. Там нет агента, планировщика и ещё много-много чего. Но я скачала какой-то профайлер, который работает и на express. Но от скачанного мною профайлера мало толку, там очень много функций недоступно.

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

Код:

--В следующем примере возвращаются сведения о пяти первых запросах, отсортированных по среднему времени ЦП. В этом примере объединяются запросы в 
--соответствии с хэшем запроса таким образом, чтобы обеспечить группировку логически эквивалентных запросов по их совокупному потреблению ресурсов
SELECT TOP 5 query_stats.query_hash AS "Query Hash", 
    SUM(query_stats.total_worker_time) / SUM(query_stats.execution_count) AS "Avg CPU Time",
    SUM(query_stats.total_elapsed_time ) / SUM(query_stats.execution_count) AS "Avg Duration",
    MIN(query_stats.statement_text) AS "Statement Text"
FROM 
    (SELECT QS.*, 
    SUBSTRING(ST.text, (QS.statement_start_offset/2) + 1,
    ((CASE statement_end_offset 
        WHEN -1 THEN DATALENGTH(st.text)
        ELSE QS.statement_end_offset END 
            - QS.statement_start_offset)/2) + 1) AS statement_text
     FROM sys.dm_exec_query_stats AS QS
     CROSS APPLY sys.dm_exec_sql_text(QS.sql_handle) as ST) as query_stats
GROUP BY query_stats.query_hash
ORDER BY 2 DESC;

только отберите запросы с максимальным Duration и минимальным CPU Time

так же смотрите в сторону других DMV
sys.dm_db_missing_index_details и sys.dm_db_missing_index_columns

[x77]

<..> нет большого смысла в том, что выборка по одному полю быстрее, чем по многим. Да, быстрее, но может полей нужно больше; да, медленнее, но может меньше полей нельзя.

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

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

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

[Dimka]

x77, я в общем-то не про это говорил. Я говорил о том, что сначала нужно понять, что вообще происходит с данными с точки зрения предметной области. Индексы - это потом, после просветления.

Если "23-хлетняя девушка" представит достаточно рациональные обоснования, подверждённые экспериментальными замерами на копии боевой базы, то почему бы и нет? Если же отказ будет мотивирован ссылками исключительно на пол и возраст, то ничего не попишешь - гореть такой больнице в аду, а Mirra88 в таком случае можно с чистой совестью перестать волноваться за эту больницу.

[x77]

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

[Mirra88]

Через 4 с лишним месяца после моего обращения на форум вопрос о причинах торможения базы с увеличением количества записей в ней неожиданно решился благодаря разработчикам базы данных. Причём решилось всё в точности как сказал Dale:
 

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

Так и получилось! Нам разослали письма как и какие 2 индекса надо добавить в базу на SQL-сервере и перестроить их. И теперь всё работает быстро. Ура!

[Dimka]

За ум взялись те разработчики.