Разработка отчетов для баз данных SQL (часть 2)

Работа с предложениями SQL

В первой части данной статьи (опубликованной ранее) говорилось, что SQL (можно произносить буквы раздельно, но многие произносят sequel) - это акроним structured query language (язык структурированных запросов). Этот язык запроса базы данных был введен в качестве псевдостандартного метода запрашивания баз данных. Термин "псевдо" используется, потому что, хотя American National Standard Institute (ANSI) основывается на стандартном SQL, каждый поставщик баз данных виртуально добавляет свои собственные штрихи, несмотря на кажущуюся приверженность стандарту ANSI.

Визуализация SQL - запроса

Поскольку Crystal Reports работает с базами данных SQL, он должен, в конечном счете, переводить таблицы, поля, связи, сортировку и группирование, используемые при разработке отчета, на язык SQL. Можно визуализировать предложения SQL, создаваемые Crystal Reports, выбирая опцию Database I Show SQL Query в раскрывающемся меню.

Рассмотрим закладку Design отчета, использующую данные базы данных XTREME, преобразованной из Microsoft Access в Microsoft SQL Server, доступ к которому обеспечивается посредством ODBC. Этот отчет использует таблицы Orders и Customer, связанные с помощью левостороннего внешнего объединения по Customer ID. Select Expert ограничивает отчет только заказчиками из USA. Обратите внимание на поля, помещенные в графе подробностей. Обратите также внимание, что была создана группа, основанная на Customer.Region.

Для визуализации предложения SQL, создаваемого Crystal Reports для запроса базы данных, выберите опцию Database I Show SQL Query. Вы увидите диалоговое окно, показанное на рис. 6. Обратите внимание на разные части (операторы) предложения SQL:

• SELECT Подбирает поля базы данных, необходимые для вашего отчета (для графы подробностей, формул, группирования и т.д.)
• FROM Выбирает таблицы, которые будут использоваться, и определяет типы объединения для связывания таблиц
• WHERE Определяет область выбора записи для сервера
• ORDER BY Посылает серверу SQL запрос на сортировку записей в соответствии с Customer.Region (для группы Region) до их отсылки клиенту

Синтаксис SQL может варьироваться в зависимости от типа используемой для отчета базы данных и метода соединения с ней – с помощью ODBC или же прямых драйверов баз данных. Вы обнаружите также различный синтаксис для объединения таблиц. Кроме того, текущее объединение таблиц может задаваться или оператором FROM, или оператором WHERE.

Здесь показано в точности то же диалоговое окно Show SQL Query, использующее прямой драйвер базы данных на Microsoft SQL Server:

А также, для версии Microsoft Access образца базы данных XTREME.MDB с соединением через ODBC:

Возможно, вы и не считаете себя большим спецом по базам данных и не имеете привычки написания огромных предложений SQL из головы, в умении видеть запросы SQL и манипулировать ими есть два больших преимущества:

• Контроль за тем, что Crystal Reports представляет на сервер базы данных, может быть полезен в случае эксплуатационных проблем или других специфических ситуаций.
• Понимая основы SQL, можно вручную менять большинство текущих запросов SQL.

Изменение SQL - запроса

Иногда Crystal Reports не использует все преимущества расширений SQL на вашем сервере, так что у вас может возникнуть необходимость в модификации SQL и включить эти расширения. Или же у вас может возникнуть желание скопировать SQL из другого инструмента запросов в диалоговое окно Show SQL Query. Вы можете изменять по своему желанию операторы FROM, WHERE и ORDER BY в предложении SQL. При этом, не имея практически никаких ограничений. Что касается оператора SELECT, то изменение его запрещено. Можно печатать поверх него, но ни одно внесенное изменение не будет сохранено. (Даже не пытайтесь заменить SELECT на DELETE или UPDATE — ваши изменения не вызовут никаких изменений на сервере!)

Убедитесь, что модификация подчиняется правилам конкретного синтаксиса SQL, служащего основой для вашего отчета. Три примера предложений SQL, приведенные ранее, отчетливо выявляют небольшие синтаксические различия между разными методами связи с одними и теми же данными. Если вы используете некорректный синтаксис SQL, то при обновлении отчета возникнет сообщение об ошибке. Если вы вручную меняете запрос SQL, а затем находите лучшее решение, вы всегда можете нажать кнопку Reset в нижнем правом углу диалогового окна Show SQL Query. При этом удаляются все внесенные изменения запроса, и восстанавливается его значение по умолчанию в Crystal Reports.

Очень важно понять, как взаимодействуют друг с другом использование диалогового окна Show SQL Query и отбор записей для отчета. Это становится особенно актуальным, если учесть, что обсуждаемый процесс был несколько изменен в Crystal Reports 8. В более ранних версиях эти два метода были, в действительности, взаимоисключающими: вы могли либо, используя Select Expert или формулу выбора записей, определить выбор записи, локально выполняемый Crystal Reports, либо определить серверу пределы запроса, применяя оператор WHERE, но не то и другое вместе. Сейчас это выглядит иначе.

При первой генерации отчета по базе данных SQL и выборе записи с помощью Select Expert или формулы выбора записи, Crystal Reports пытается преобразовать выбор записи в оператор SQL WHERE. Если затем вручную изменить оператор WHERE в диалоговом окне Show SQL Query, то, как и в предыдущих версиях Crystal Reports, выбор записи, сделанный с помощью формулы или Select Expert, исчезнет. Ограничение записей отчета в Crystal Reports будет зависеть от ваших настроек SQL. Вы можете затем вернуться к Select Expert или Record Selection Formula Editor и увидеть, что там ничего нет. Если снова сделать выбор в Select Expert или ввести формулу отбора записей, появится сообщение:

Этим Crystal Reports 8 отличается от предыдущих версий. Раньше изменение выбора вытесняло изменения, сделанные в операторе WHERE. Теперь Crystal Reports фактически использует оба набора критериев для ограничения записей: Select Expert/формула выбора записи и обычный оператор WHERE. Оператор WHERE выполняется первым. Затем результирующий набор из базы данных подвергается локальному отбору записей, заданному с помощью Select Expert или формулы выбора записи. Будьте внимательны, увидев это сообщение: вполне возможно, что две опции выбора напрямую конфликтуют друг с другом, и в вашем отчете не будет ни одной записи.

Чувствительность к Регистру

Возможно вы знаете, что базы данных PC-типа чувствительны к регистру при отборе записей. Иллюстрацией к вышесказанному может служить сравнение поля базы данных, содержащего название страны, и строки "USA". Любые данные, хранящиеся в базе данных как "россия" или "РОССИЯ", не будут извлечены в отчет.

Вероятно, вы также знаете, что при работе с базами данных SQL возможен выбор чувствительности к регистру. Чтобы изменить опции только для текущего отчета, выберите File I Report Options и отметьте Case-Insensitive SQL Data. Если вы хотите, чтобы запросы SQL были нечувствительны к регистру во всех последующих отчетах, начиная с этого момента, выберите File I Options и отметьте Case-Insensitive SQL Data на опции Database.

Помните, что эти опции могут не работать, если используемый вами конкретный сервер базы данных, драйвер ODBC или прямой драйвер базы данных, не поддерживает нечувствительность к регистру. В таких ситуациях может существовать возможность вручную изменить предложение SQL и игнорировать регистр. Например, следующий оператор WHERE Microsoft Access (на ODBC) чувствителен к регистру:

Where

Customer.'Country' = 'РОССИЯ'

Используя специальную "изюминку" Microsoft Access SQL, можно сделать запрос нечувствительным к регистру, изменив его следующим образом:

Where

UCASE(Customer.'Country') = 'РОССИЯ'

При этом встроенная функция SQL UCASE переведет в верхний регистр все буквы записи базы данных до того, как сервер сравнит их с буквами верхнего регистра "РОССИЯ".

Использование хранимых процедур SQL

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

Для увеличения гибкости хранимые процедуры могут содержать один или более параметров хранимой процедуры, которые предлагают пользователю ввести то или иное значение. Это значение затем используется хранимой процедурой для реализации запроса. Например, если имеется хранимая процедура, возвращающая несколько полей из связанных таблиц и основанная на параметрах Country (Страна) и Order Date (Дата заказа), то при ее выполнении появляется подсказка на введение конкретного названия страны и даты заказа. Процедура вернет результирующий набор, содержащий только записи, согласующиеся с введенными значениями параметров.

Выбор хранимых процедур

Crystal Reports обращается с хранимыми процедурами почти так же, как с обычными таблицами базы данных. Хранимые процедуры появляются в Data Explorer и используются в отчете, как обычные таблицы базы данных. Единственное отличие состоит в том, что с хранимой процедурой могут быть связаны параметры. Однако у вас есть возможность выбрать, будут или нет, хранимые процедуры появляться в Data Explorer при открытии базы данных. Самый быстрый способ гарантировать их появление - нажать кнопку Options в Data Explorer и пометить опцию Stored Procedure в диалоговом окне Database Options (показанном ранее на рисунке 2 первой части статьи Разработка отчетов на основе баз данных SQL). Можно также сделать это изменение постоянным для всех будущих новых отчетов, отметив ту же опцию на закладке Database, предварительно выбрав File I Options в раскрывающемся меню.

С этого момента, открывая базу данных SQL, вы будете видеть хранимые процедуры наряду с постоянными таблицами базы данных.

Ваш отчет может быть основан на хранимой процедуре или на комбинации одной или более таблиц базы данных, но не на том и другом одновременно. Нельзя связать хранимую процедуру в Visual Linking Expert, поэтому вы не сможете использовать готовую процедуру в точности так же, как таблицу. Если хранимая процедура не содержит все нужные вам данные, попросите администратора базы данных добавить в нее дополнительные поля, или используйте связанный подотчет для извлечения необходимых данных.

Работа с параметрами хранимой процедуры

Выбрав хранимую процедуру для подготовки отчета, вы получите подсказку на введение любых значений для любых параметров готовой процедуры в диалоговом окне Enter Parameter Values. Это диалоговое окно идентично окну для полей параметров отчета.

Введите желаемые значения параметров и нажмите OK. Затем можно просто продолжить процесс проектирования отчета обычным образом. Хранимая процедура предоставит список полей, которые можно использовать в отчете, как если бы это была обычная таблица базы данных.

Параметры хранимых процедур ведут себя почти идентично полям параметров Crystal Reports. Параметры хранимых процедур появляются в категории Parameter Fields в Field Explorer.

Можно отредактировать параметр хранимой процедуры, выбрав его и нажав кнопку Edit, набрав ctrl-e, или щелкнув справа от параметра и выбрав Edit во всплывающем меню. Хотя нельзя изменить тип величины или выбрать интервал или несколько значений, можно задать список для выбора значений по умолчанию, установить пределы длины или редакторский шаблон для строковых параметров, или определить пределы для параметров чисел и дат. При обновлении отчета вы получаете ту же подсказку, что и при использовании полей параметров.

Вы можете выбрать, воспользоваться ли существующими значениями параметров хранимых процедур или вызвать новые значения. В последнем случае сервер выполнит хранимую процедуру с новыми значениями и возвратит новый результирующий набор в Crystal Reports.

Использование полей SQL - выражения

Иногда требуется, чтобы сервер базы данных фактически выполнил для вас некоторые вычисления, возвращая при этом вычисленное поле вместе с результирующим набором базы данных. Это достигается с помощью полей выражений SQL, которые можно создать непосредственно из Field Explorer. Выражение SQL выглядит как формула, за исключением того, что оно полностью состоит из полей базы данных и функций SQL, поддерживаемых языком конкретного сервера SQL, с которым вы работаете. Использование выражения SQL вместо формулы Crystal Reports иногда дает ощутимые преимущества. Выражение обрабатывается сервером, а не клиентом, что часто улучшает рабочие характеристики.

Особое преимущество связано с вычислениями или другими специальными функциями, используемыми при выборе записи. Если для выбора записи применяется формула Crystal Reports, сервер базы данных не может осуществить отбор, так как он не понимает язык формул Crystal Reports. Однако, создавая выражение SQL и используя его при выборе записи, сервер SQL полностью поймет выражение, и сервер базы данных реализует желаемый выбор.

Создание выражений SQL

Первое необходимое условие для работы с выражениями SQL заключается в использовании базы данных SQL или ODBC. Если вы используете базу данных PC-типа, выражения SQL не применимы, и вы даже не увидите закладку SQL Expression в Field Explorer. При использовании базы данных SQL, в Field Explorer включена дополнительная категория, называемая SQL Expression Fields. Выбирая опцию Insert I SQL Expression Field всплывающего меню, можно вызвать Field Explorer, в котором эта категория уже выбрана.

Нельзя применять поля выражений SQL с хранимыми процедурами. Если ваш отчет основан на хранимой процедуре, категория SQL Expression Fields даже не появится в Field Explorer.

Создание выражений SQL очень похоже на создание формул Crystal Reports. Сначала вас просят ввести имя выражения SQL. Как и в случае с именами формул, следует подобрать приемлемо короткое и простое для понимания имя выражения SQL. Имя может содержать пробелы и буквы верхнего и нижнего регистров. Имя, данное выражению SQL, будет также заголовком столбца при размещении выражения SQL в разделе деталей отчета.

После того как вы ввели имя выражения SQL и нажали OK, появляется SQL Expression Editor, как показано на рисунке 7.

Обратите внимание на похожие черты SQL Expression Editor и других редакторов формул в Crystal Reports. Написание выражений SQL, в основном, не отличается от написания других формул: можно напечатать выражение прямо в текстовом окне Formula, или дважды щелкнуть по трем верхних окнам, чтобы получить помощь в построении выражений. Заметьте, что, как и в формулах, полях параметров и текущих результирующих полях, Crystal Reports добавляет специальный символ к началу имени выражения SQL. Символ процента (%) используется для обозначения полей выражений SQL.

Функции и операторы SQL Expression Editor зависят от используемой базы данных и драйвера базы данных. Рассмотрев окно, содержащее дерево функций, изображенное на рисунке 7, вы заметите некоторый набор имеющихся в наличии функций SQL. Этот пример дан для отчета, использующего Microsoft SQL Server посредством ODBC. В то же время, Expression Editor предлагает совершенно другой набор функций SQL при использовании прямого драйвера базы данных для соединения с той же базой данных. По этой причине, при переходе от одной базы данных к другой с помощью опций Set Location или Convert Database Driver, имеющихся в раскрывающемся меню Database, может потребоваться редактирование или модификация некоторых выражений SQL. Чтобы получить детальное описание различных встроенных функций SQL именно для вашей базы данных или драйвера, обратитесь к документации для этой базы данных или драйвера.

Пусть, например, вы хотите, чтобы программа просмотра отчета могла определить полное или частичное контактное имя для поиска с помощью единственного поля параметра. Если существует заказчик, чье описание подходит под введенные данные, он будет включен в отчет. В таблице Customer в образце базы данных XTREME, включенном в Crystal Reports, контактная информация в настоящее время разделена в базе данных на поля имени и фамилии. Без использования выражений SQL имеется две возможности реализации данного поиска:

• Создать два поля параметров—одно для имени и второе для фамилии —и попытаться сравнить их с полями базы данных.
• Создать формулу Crystal Reports, объединяющую контактное имя и фамилию, и сравнить эту формулу с полем параметра.

Оба подхода не идеальны. Если выбран первый вариант, то программе просмотра будет намного сложнее оперировать при вводе полного или частичного (сокращенного) контактного имени, например, "Ира" (например, при одновременном поиске Ира и Ираида). Действительно, в таком случае понадобится некоторое дополнительное логическое условие для игнорирования поля параметра фамилии. Наоборот, если программа просмотра должна найти все позиции с фамилией "Иванов," независимо от имени, потребуется применить то же логическое условие для поля параметра имени. Было бы значительно проще, если можно было бы просто напечатать Ира* или *Иванов для поиска желаемых заказчиков.

При выборе второго варианта, упомянутые в предыдущем абзаце полный или частичный поиски будут работать, но поскольку имя и фамилия объединены в формуле, выбор записи на сервере базы данных не произойдет (вспомните, что большинство формул Crystal не могут быть преобразованы в SQL, так что отбор записей будет произведен на клиентской машине).

Использование выражения SQL является оптимальным решение данной проблемы. Имя и фамилия могут быть объединены в одном объекте и сопоставлены с полем параметра. Но так как объединение выполняется на сервере базы данных, он будет осуществлять выбор записи и возвращать не все имена заказчиков, а только результат поиска.

Выполняемое для этого выражение SQL удивительно похоже на формулу Crystal Reports:

Customer."Contact First Name" + ' + Customer."Contact Last Name"

Однако обратите внимание на пару различий:

• Вокруг имен полей нет фигурных скобок.
• Буквенные строки, разделяющие поля имени и фамилии, должны использовать апострофы—знаки вопроса работать не будут.

Как только выражение SQL создано, его можно поместить в отчет, как если бы это было поле базы данных, поле формулы, или другой объект. Его также можно использовать в стандартных формулах отчета или условных форматирующих формулах. Обратите внимание на изменение запроса SQL (просматриваемого с помощью Database I Show SQL Query) после помещения этого выражения SQL в секции подробностей:

И это несмотря на то, что полю выражения SQL было присвоено имя в отчете. Crystal Reports просто добавляет саму формулу выражения SQL в предложение SQL. Это имя используется в Crystal Reports в Select Expert или где-нибудь еще в отчете.

Теперь можно применить выражение SQL для выбора записей, воспользовавшись оператором Like Select Expert, который проведет поиск комбинации контактного имени и фамилии по групповому символу. Если вызываемое строковое поле параметра (?Contact Prompt) уже создано, Select Expert будет выглядеть следующим образом:

Когда вы обновляете отчет и получаете запрос на ввод поля параметра Contact Prompt, то ввод группового символа Александр* приведет к возвращению следующих записей:

Customer Name (Имя заказчика)	Contact Name (Контактное имя)	Last Year's Sales (Прошлогодние продажи )	City (Город)	Region (Область/ Регион)
Администрация	Александр Долматинов	1 045,99	Тюмень	Тюменская
Рога и Копыта	Александра Александрова	34 777,55	д. Лопухово	Московская

Теперь взгляните на запрос SQL, посылаемый на сервер базы данных:

Обратите внимание на то, что оператор WHERE включает текст формулы выражения SQL и оператор сравнения SQL, позволяющий поиск по групповому символу. При этом результатом является гибкость формул Crystal Reports и скорость выбора записей, основанных на сервера.

Образование групп на сервере базы данных

Другой сильной стороной серверов баз данных SQL является обработка и образование групп на основе сервера. Образование групп на основе сервера связано с умением сервера SQL проводить совокупные вычисления на группах записей, возвращая на клиентскую машину только промежуточные итоги, сводки и прочие виды совокупностей. Если вы готовите суммарный (сводный) отчет (что случается очень часто), эта возможность может значительно уменьшить количество данных, проходящих по сети. Кроме того, совокупные вычисления скорее можно провести на серверной машине, чем на клиентской.

Рассмотрим следующий простой отчет Sales by Region (Продаж по регионам):

Этот отчет позволяет показать всех заказчиков, сгруппированных по регионам, вместе с промежуточными суммами итогов по продажам для каждой группы. Сервер базы данных посылает список всех заказчиков, проживающих в интересующих пользователя регионах, в Crystal Reports. Клиент же вычисляет промежуточную сумму и итог для каждой группы по мере создания отчета. Это иллюстрируется видом запроса SQL для данного отчета:

Обратите внимание, что это довольно простое предложение SQL отбирает поля базы данных и ограничивает записи одной страной (в данном случае Россией). Единственное свойство сервера, используемое здесь для образования групп – это оператор ORDER BY, который предварительно сортирует набор результатов по признаку Region до того, как отослать их на клиентскую машину.

Вы можете заметить, что теперь оператор SELECT включает только поле группы (в данном случае, Region) и две совокупные функции, которые проводят суммирование и подведение итогов прямо на сервере до отсылки данных клиенту. Обратите также внимание на новый для вас оператор GROUP BY. Эта новая функция SQL говорит серверу, что надо сгруппировать записи базы данных и вычислить сводку по всему серверу. Только итоговая сводка будет отправлена на клиентскую машину.

Что требуется для группирования на основании сервера

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

Требование	Объяснение
В отчете должна быть хотя бы одна группа	Для того чтобы оператор GROUP BY был добавлен к запросу SQL, необходимо чтобы в отчете присутствовала хотя бы одна группа.
Раздел деталей должен быть скрыт	Если раздел деталей является видимым, то на сервере не будет присутствовать ни одной группы. Потому что в таком случае серверу придется отправить все отдельные записи базы данных для отображения их в разделе деталей.
Включайте только групповые поля или сводные поля в верхние и нижние колонтитулы группы.	Если вы включите любые другие поля базы данных (или поля формулы, содержащие что-либо, отличающееся от групповых или сводных поле), то сервер будет вынужден послать детальные данные на клиентскую машину для правильного показа отчета.
Не производите группировку в формулах Crystal Reports	Из-за того, что большинство формул не может быть преобразовано в формат SQL, они должны быть вычислены на клиентской машине до того, как по ним будем сгруппирован отчет. Из-за этого требования, сервер должен послать детальные записи клиенту. Это еще одна причина, по которой вы скорее всего склонитесь к использованию выражения SQL как альтернативы формулам.
Выполнение вычислений типа итого должно основываться на сводных полях	Если подобного рода вычисления основаны на детальных полях, Crystal Reports необходимо иметь подробные данные для вычислений в процессе составления отчета. Это мешает реализовать группировку на сервере.
Отчет не должен содержать значения Average или Distinct Count или Top N	Crystal Reports не может преобразовывать эти специфические функции в SQL. Таким образом, при использовании этих функций группирование будет производиться на клиентской машине.
Группы отчета могут быть отсортированы только в порядке убывания/возрастания. Никакие другие виды сортировки не будут работать.	Так как Crystal Reports использует свою внутреннюю логику для обеспечения сортировки, отличной от убывания/возрастания, ему необходимо будет иметь детальные записи для того, чтобы корректно вычислить место размещения указанных групп.

Эффекты анализа Drill-Down (детализации по иерархии)

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

Однако, если вы активируете группировку на сервере, детальных данных для отображения при детализации по иерархии не будет —клиенту посылается только сводка данных! Тем не менее, Crystal Reports все еще позволяет делать детализация по иерархии; он просто посылает другой запрос на сервер SQL каждый раз, когда пользователь продвигается вглубь. Этот второй запрос просто запрашивает детальные данные для группы, по которой проводится описываемый анализ, добавив дополнительный критерий к оператору WHERE. Этот метод обеспечивает выгоды группирования на сервере, не мешая при этом возможностям интерактивной детализации по иерархии. Цена, которую платит пользователь, связана с тем, что запрос детализации по иерархии может потребовать от сервера проведение дополнительной настройки. Взгляните на пример, показанный на рис. 8. Обратите внимание, что когда пользователь вызывает детализацию по иерархии в определенной области, появляется новая закладка детализации по иерархии, показывающая детальные данные для этой области. Обратите внимание на новый запрос SQL, созданный в процессе работы.

Можно увидеть запросы SQL на проведение детализации по иерархии, выбирая Database I Show SQL Query при просмотре закладки детализации по иерархии. Возвращаясь к главной закладке Preview и показывая запрос, вы снова увидите оператор GROUP BY.

Порассуждаем?

Базы данных SQL (или базы данных PC-типа, доступные через ODBC) выгодно отличаются от баз данных PC-типа. Как постоянно говорилось в этой статье, одним из главных преимуществ баз данных SQL над базами данных PC-типа является способность сервера базы данных выполнять отбор и локальную группировку записей, как только приходит запрос SQL от Crystal Reports. Лишь после того, как сервер базы данных сам произведет отбор и группировку записей, результирующий набор будет возвращен в Crystal Reports.

Пусть работает сервер

Обычно при составлении отчета всегда есть желание, чтобы сервер базы данных провел всю возможную обработку. Программное обеспечение сервера базы данных разрабатывается и настраивается таким образом, чтобы выполнять как раз операции такого рода. Программное обеспечение сервера часто размещают на очень мощной платформе, тем самым еще увеличивая производительность. Любая задача, решение которой приводит к отправке сервером каждой записи своей базы данных (базы данных SQL, содержащие более миллиона записей, совсем не редкость) для проведения выборки и локального суммирования в Crystal Reports, часто приводит к неудовлетворительным результатам.

Чтобы увидеть, сколько запросов (или есть ли они вообще) обрабатывается на сервере базы данных, визуализируйте запрос, выбирая опцию Database I Show SQL Query в раскрывающемся меню. Посмотрите на предложение SQL для оператора WHERE. Если вы его не видите, сервер не выполнит никакого выбора, и каждая запись в базе данных вернется на локальный компьютер для сортировки в Crystal Reports. Это может быть очень долгим занятием!

Когда вы сортируете или группируете отчет, найдите оператор ORDER BY. Если он есть, сервер базы данных предварительно рассортирует данные до их отправления в Crystal Reports. Это может ускорить форматирование отчета. Если вы не увидели оператор ORDER BY, но предписали проведение группировки или сортировки в отчете, сервер пошлет несортированные записи в Crystal Reports, и клиент будет вынужден их сортировать.

Если вы хотите реализовать группирование на сервере, убедитесь, что в запросе есть оператор GROUP BY. Это гарантирует, что сервер группирует и собирает воедино данные перед их отправлением в Crystal Reports. Если этого оператора нет, вернитесь к описанию требований для группирования с помощью сервера (выше в этой статье).

Чтобы обеспечить проведение отбора записей на сервере, Crystal Reports должен преобразовать формулу выборки записей в SQL-оператор WHERE. Несколько правил помогут вам гарантировать, что максимально возможное число правил отбора будет преобразовано в SQL и что отбор будет выполнен сервером:

• Не производите отбор записей по полям формул. Crystal Reports обычно не может преобразовать формулы SQL, поэтому большая часть отбора записей по полям формул будет выполнена в Crystal Reports.
• Не используйте в критерии отбора встроенные функции языка формул Crystal Reports, например, ToText. К сожалению, Crystal Reports не может преобразовать их в SQL, так что эти стадии выбора записей не будут выполнены на сервере.
• Избегайте использования строковых индексных функций в правилах выбора записей. Например, {Customer.Contact First Name}[l to 5] = "Ира" не может быть преобразовано в SQL, так что отбор записей будет оставлен на Crystal Reports. Вместо этого создайте выражение SQL, возможно, используя предложение SQL LEFT, например, LEFT(Customer.Contact_First_Name, 5). Затем используйте его для отбора записей.

Используйте индексированные поля

Вас может убаюкать фальшивое чувство безопасности работы, так как в базах данных SQL нет требования связывания индексированных полей (вспомните, что базы данных PC-типа позволяют создавать связь только с индексированным полем). Поскольку при использовании базы данных SQL даже нельзя увидеть в Visual Linking Expert, какие поля индексированы, можно подумать, что в действительности не имеет значения, к каким полям устанавливается связь или по каким полям происходит отбор.

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

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

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