Форум программистов «Весельчак У»
  *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

  • Рекомендуем проверить настройки временной зоны в вашем профиле (страница "Внешний вид форума", пункт "Часовой пояс:").
  • У нас больше нет рассылок. Если вам приходят письма от наших бывших рассылок mail.ru и subscribe.ru, то знайте, что это не мы рассылаем.
   Начало  
Наши сайты
Помощь Поиск Календарь Почта Войти Регистрация  
 
Страниц: [1] 2  Все   Вниз
  Печать  
Автор Тема: Вызов хранимой процедуры SQL2005 Express  (Прочитано 51185 раз)
0 Пользователей и 1 Гость смотрят эту тему.
Mirra88
Постоялец

ru
Offline Offline

« : 03-07-2011 14:28 » 

Есть хранимая процедура (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
Блюзмен
Команда клуба

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #1 : 03-07-2011 15:24 » 

В SQL Server Management Studio Express процедура выполняется без проблем, когда же я пытаюсь в Builder6 из компонента  ADOQuery вызвать её сформировав строку запроса вот так:
Код:
select * from pPolsq()
то выходит ошибка: "Недопустимое имя объекта "pPolsq"". Никакие переименования процедуры не помогают. А вот если вместо имени процедуры поставить имя любой таблицы той же SQL-базы, то всё выполняеься прекрасно.

А в самой SQL Server Management Studio Express запрос
Код:
select * from pPolsq()
срабатывает?
Записан

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

Ходить по воде и разрабатывать программное обеспечение по спецификациям очень просто, когда и то, и другое заморожено. - Edward V. Berard

Любые проблемы в информатике решаются добавлением еще одного уровня косвенности – кроме, разумеется, проблемы переизбытка уровней косвенности. — Дэвид Уилер.
Mirra88
Постоялец

ru
Offline Offline

« Ответ #2 : 03-07-2011 15:31 » 

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

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #3 : 03-07-2011 15:41 » 

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

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

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

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

Ходить по воде и разрабатывать программное обеспечение по спецификациям очень просто, когда и то, и другое заморожено. - Edward V. Berard

Любые проблемы в информатике решаются добавлением еще одного уровня косвенности – кроме, разумеется, проблемы переизбытка уровней косвенности. — Дэвид Уилер.
Mirra88
Постоялец

ru
Offline Offline

« Ответ #4 : 03-07-2011 15:52 » 

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

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #5 : 03-07-2011 16:07 » 

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

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

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

Ходить по воде и разрабатывать программное обеспечение по спецификациям очень просто, когда и то, и другое заморожено. - Edward V. Berard

Любые проблемы в информатике решаются добавлением еще одного уровня косвенности – кроме, разумеется, проблемы переизбытка уровней косвенности. — Дэвид Уилер.
Dimka
Деятель
Команда клуба

ru
Offline Offline
Пол: Мужской

« Ответ #6 : 03-07-2011 18:47 » 

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

Если у тебя действительно хранимая процедура, возвращающая один или несколько табличных результатов, то достаточно вызывать
Код: (Text)
exec pPolsq
разумеется, текущая база данных должна быть указана правильно.
Записан

Программировать - значит понимать (К. Нюгард)
Невывернутое лучше, чем вправленное (М. Аврелий)
Многие готовы скорее умереть, чем подумать (Б. Рассел)
Mirra88
Постоялец

ru
Offline Offline

« Ответ #7 : 04-07-2011 11:55 » 

Ура, спасибо всем, кто мне помог, вывести результат хранимой процедуры получилось. А вышла я из положения так, вначале на 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ервер, в результате чего я "от чего уйду, к тому и приду", не получив выигрыша в скорости? Оптимален-ли вариант с временными таблицами?
« Последнее редактирование: 04-07-2011 12:00 от Mirra88 » Записан
Dale
Блюзмен
Команда клуба

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #8 : 04-07-2011 12:09 » 

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

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

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

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

Ходить по воде и разрабатывать программное обеспечение по спецификациям очень просто, когда и то, и другое заморожено. - Edward V. Berard

Любые проблемы в информатике решаются добавлением еще одного уровня косвенности – кроме, разумеется, проблемы переизбытка уровней косвенности. — Дэвид Уилер.
x77
Модератор

ro
Offline Offline
Пол: Мужской
меняю стакан шмали на обратный билет с Марса.


« Ответ #9 : 04-07-2011 12:29 » 

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

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

Mirra88
Постоялец

ru
Offline Offline

« Ответ #10 : 04-07-2011 12:44 » 

Да конечно, саму хранимку плавно перенести нельзя, я плавно перенесла только ТЕКСТ ВЫЗОВА хранимки, а именно свойство 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
Модератор

ro
Offline Offline
Пол: Мужской
меняю стакан шмали на обратный билет с Марса.


« Ответ #11 : 04-07-2011 13:01 » 

Цитата
СКОРОСТЬ - ЭТО САМОЕ ГЛАВНОЕ

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

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

Mirra88
Постоялец

ru
Offline Offline

« Ответ #12 : 04-07-2011 13:06 » 

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

ro
Offline Offline
Пол: Мужской
меняю стакан шмали на обратный билет с Марса.


« Ответ #13 : 04-07-2011 13:15 » 

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

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

Записан

Mirra88
Постоялец

ru
Offline Offline

« Ответ #14 : 04-07-2011 13:17 » 

Спасибо.
Записан
Dimka
Деятель
Команда клуба

ru
Offline Offline
Пол: Мужской

« Ответ #15 : 04-07-2011 13:28 » 

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

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

Программировать - значит понимать (К. Нюгард)
Невывернутое лучше, чем вправленное (М. Аврелий)
Многие готовы скорее умереть, чем подумать (Б. Рассел)
Mirra88
Постоялец

ru
Offline Offline

« Ответ #16 : 04-07-2011 13:39 » 

Спасибо
Записан
x77
Модератор

ro
Offline Offline
Пол: Мужской
меняю стакан шмали на обратный билет с Марса.


« Ответ #17 : 04-07-2011 13:46 » 

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

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

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

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

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

если вы просто экспериментируете, то в чем заключается цель эксперимента? что потом надо делать с этими данными (менять, удалять, добавлять, просматривать, печатать, экспортировать)?
« Последнее редактирование: 04-07-2011 14:13 от x77 » Записан

Mirra88
Постоялец

ru
Offline Offline

« Ответ #18 : 04-07-2011 14:42 » 

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

ro
Offline Offline
Пол: Мужской
меняю стакан шмали на обратный билет с Марса.


« Ответ #19 : 04-07-2011 14:49 » 

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

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

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


Добавлено через 3 минуты и 31 секунду:
Цитата
я удалила треть данных SQL-базы и база стала открываться не за 45, а за 5 секунд)
а если база вырастет в 10 раз? такое поведение программы говорит о кривой логике работы с БД. за минуту SQL-сервер может отдать десятки (если не сотни) тысяч записей, ни один человек не в состоянии работать одновременно с таким массивом информации. такие запросы просто не нужны (и вредны). давайте попробуем продумать логику доступа к вашим данным, только сначала опишите их. это справочные таблицы или операционные, что в них хранится, кто эти данные заполняет, кто читает, как часто и т.д.
« Последнее редактирование: 04-07-2011 14:52 от x77 » Записан

Mirra88
Постоялец

ru
Offline Offline

« Ответ #20 : 04-07-2011 15:15 » 

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

ro
Offline Offline
Пол: Мужской
меняю стакан шмали на обратный билет с Марса.


« Ответ #21 : 04-07-2011 15:38 » 

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

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

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

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

ну и т.д.
« Последнее редактирование: 04-07-2011 15:44 от x77 » Записан

Mirra88
Постоялец

ru
Offline Offline

« Ответ #22 : 04-07-2011 15:45 » 

Так я же и не пытаюсь больше открывать целую таблицу.. Я теперь пытаюсь сформировать запросы из разных таблиц на конкретного пациента. К примеру пришли Вы к врачу и врач вводит Вашу фамилию, а там сразу и числа всех Ваших предыдущих посещений с диагнозами и именами врачей. Всё это выбирается из разных таблиц, но в нашей базе это тоже происходит медленно.. Я хочу попробовать, чтобы быстро.
« Последнее редактирование: 04-07-2011 15:48 от Mirra88 » Записан
x77
Модератор

ro
Offline Offline
Пол: Мужской
меняю стакан шмали на обратный билет с Марса.


« Ответ #23 : 04-07-2011 15:49 » 

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

Добавлено через 1 минуту и 37 секунд:
судя по USE [tatApril11], данные по посещениям за месяц хранятся в разных таблицах? т.е. на каждый новый месяц заводится новая таблица?
« Последнее редактирование: 04-07-2011 15:51 от x77 » Записан

Mirra88
Постоялец

ru
Offline Offline

« Ответ #24 : 04-07-2011 15:58 » 

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

ro
Offline Offline
Пол: Мужской
меняю стакан шмали на обратный билет с Марса.


« Ответ #25 : 04-07-2011 16:00 » 

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

Mirra88
Постоялец

ru
Offline Offline

« Ответ #26 : 04-07-2011 16:03 » 

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

ro
Offline Offline
Пол: Мужской
меняю стакан шмали на обратный билет с Марса.


« Ответ #27 : 04-07-2011 16:13 » 

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

Код:
select FAM
from mibAPAC

?
Записан

Mirra88
Постоялец

ru
Offline Offline

« Ответ #28 : 04-07-2011 16:21 » 

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

Добавлено через 4 минуты и 59 секунд:
Но ведь на скорость в программе играет роль не только скорость самой выборки, пользователю открывается clarion-форма, он чего-то там меняет, закрывает форму. На это открытие-закрытие почему-то тоже уходит много времени (в зависимости от размера SQL-базы)
« Последнее редактирование: 04-07-2011 16:26 от Mirra88 » Записан
x77
Модератор

ro
Offline Offline
Пол: Мужской
меняю стакан шмали на обратный билет с Марса.


« Ответ #29 : 04-07-2011 16:27 » 

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

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

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

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

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

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

Код:
select count (123)
from MyTable
,

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

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

запросы проверять не в самом билдере, а в профайлере или в менеджмент-студии.
« Последнее редактирование: 04-07-2011 16:34 от x77 » Записан

Страниц: [1] 2  Все   Вверх
  Печать  
 

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines