Нові підходи до Crystal Reports. Використання Crystal Reports разом з SQLBase і SQLWindows, Різне, Інтернет-технології, статті

Зміст



У попередній статті ми висвітлили питання використання Crystal Reports з SQLWindows. Ми навчилися викликати, переглядати і друкувати готові звіти за допомогою Report Designer Component (RDC). Crystal Reports не дозволяє безпосередньо зв’язуватися з SQLBase. У маркетингових матеріалах Seagate Software (хоч і під різними іменами) описується єдина можливість зв’язку – тільки через ODBC. Ця стаття дає огляд можливостей безконфліктного спільного використання зазначених коштів.


Дещо про ODBC


Коли ви створюєте новий звіт за допомогою Seagate Crystal Reports 8, З’являється вікно перегляду даних, що дозволяє вам вибрати джерело даних для звіту. Якщо ви розкриєте гілку ODBC, Ви помітите, крім інших, елемент з ім’ям CRGUP (За умови, що Crystal Reports правильно встановлений). Цей елемент CRGUP представляє джерело даних ODBC для SQLBase, встановлений при інсталяції. Ви можете погодитися з тим, що ім’я кілька застаріло, але не переймайтеся про це – все інше досить актуально.


Насправді всі доступні драйвера ODBC, будь то від Seagate Software або від Centura, походять від однієї компанії під ім’ям Merant (Раніше Intersolv). Ця компанія ліцензує використання своїх драйверів ODBC іншими компаніями. Для усунення конфлікту імен ці драйвера отримують унікальне ім’я для кожного продукту, з яким вони поставляються. Якщо ви інсталюєте драйвер ODBC фірми Centura, джерело даних буде називатися “SQLBase”, в Crystal Reports його ім’я буде “CRGUP”.


Для більш детальної інформації відкрийте контрольну панель і виберіть джерела даних ODBC. Тепер клацніть на закладці “Drivers” і ви побачите вікно, схоже на наступний екранний знімок. Ви можете помітити, що існує чотири відповідних елемента, які можуть мати справу з SQLBase. Забігаючи вперед, можна додати, що ім’я компанії якийсь час назад змінилося з Intersolv на Merant. У списку ви можете побачити, що за винятком імені компанії, CRGUP14.DLL і C2GUP14.DLL здаються ідентичними.

Драйвера ODBC забезпечують стандартний інтерфейс до різних типів і видів баз даних. За допомогою одного загального інтерфейсу ви можете отримати доступ до текстових файлів таким же чином, що й до баз даних dBase, SQLBase або Oracle. У теорії звучить як хороша ідея, але в реальному житті, як завжди, є кілька проблем. З одного боку використання ODBC вимагає накладних витрат по продуктивності і досить відчутно до конфігурації і проблем інсталяції. З іншого боку, функціональні можливості, що надаються клієнтського інтерфейсу, залежать від складності драйвера. Так що існує частина набору функціональних можливостей бази даних, недоступна через драйвер.


Звідси правило: драйвера ODBC гарні для універсальної організації доступу до даних, запитів і обміну даними. Для реальних додатків, можливо, краще використовувати власні інтерфейси баз даних.


Джерела даних ODBC


ODBC пропонує два режими конфігурування – системні і користувальницькі імена джерел даних (DSN – data source name). Перші встановлюються в реєстрі машини (в гілки HKEY_LOCAL_MACHINE) і доступні всім користувачам. Другі – джерела даних конкретного користувача і доступні тільки користувачу поточного сеансу (вони реєструються в гілки реєстру HKEY_CURRENT_USER).


Ім’я джерела даних містить кілька загальних установок і специфічні для конкретної бази даних конфігураційні параметри. Запустіть Regedit.exe і погляньте на гілку реєстру HKEY_CURRENT_USERSoftwareODBCODBC.INI. Тут присутні різні конфігураційні поля. (Коли вперше з’явилися драйвера ODBC, до появи реєстру в Windows 95, всі установки ODBC управлялися файлами INI, от чому ця гілка реєстру має таке веселе назву.)


Використання машинно-залежних джерел даних може стати кілька проблематичним і обмежує, якщо ODBC використовується для доступу до баз даних на декількох клієнтських машинах. Щонайменше, в драйвері SQLBase для кожного з’єднання з базою даних потрібно окреме ім’я DSN. Уявіть, що ви змінили або додали базу даних на сервері SQLBase – кожен клієнт повинен бути сконфігурований з новими установками. Це стає абсолютно нездійсненним в мережі з великою кількістю користувачів (без автоматизації).


На щастя, існує третій режим конфігурування, званий “файловий DSN”, – джерело даних не залежить від конкретних установок реєстру. Якщо ви подивитеся на File DSN в діалозі контрольної панелі ODBC, ви помітите стандартний каталог для таких *. Dsn файлів. Файл DSN для джерела даних SQLBase виглядає приблизно так:



[ODBC]
DRIVER=Centura SQLBase 3.5 32-bit Driver -NT & Win95
UID=
DB=ISLAND
SRVR=


Це досить схоже на *. Ini файли Windows і містить ту ж інформацію, що і джерела даних в реєстрі. Однак цей спосіб більш прийнятний, коли йдеться про супровід. Такий файл може бути легко поширений простим копіюванням і може розташовуватися в поділюваному каталозі на файловому сервері.


При необхідності, в файл можуть бути додані установки, специфічні для SQLBase, наприклад, ключові слова для часу інтервалу блокування, багатопотоковості і рівнів ізоляції. Все це описано у файлі довідки, що супроводжує драйвер ODBC.


Поширення DSN при використанні Crystal Reports


Важливо не змішувати імена DSN та імена баз даних SQLBase. Якщо ви використовуєте графічний інтерфейс Crystal Reports для доступу до різних баз даних, вам буде запропоновано діалог входу, який дозволяє вам вказати ім’я використовуваної бази – SqlDatabase. Однак програмно, під час виконання, за допомогою RDC (описаному в першій частині цієї статті) можуть бути задані тільки ім’я користувача та пароль. Я думаю це вірно і для інших ODBC-сумісних додатків. Це означає, що вам необхідно окреме ім’я DSN для кожної з баз даних, до яких ви хочете отримати доступ.


Переконайтеся, що ви дали різні імена джерела даних ODBC і вашій базі даних SQLBase. З різних причин SQLWindows перевіряє джерела даних ODBC при виклику SqlConnect (), що може привести до повідомлення про помилку. Якщо це станеться, буде створений файл GUPTA.INI. Пошукайте такі файли на вашому жорсткому диску і при необхідності – видаліть їх.


Я використовую описові імена для моїх баз даних, навіть під час звичайного входу в програму. Наприклад, якщо користувач вибирає “Island Outfitters Sales” як ім’я бази даних зі списку вибору, внутрішньої константі SqlDatabase буде присвоєно значення “ISLDSALE” і файл “Island Outfitters Sales.dsn” буде виглядати приблизно так:



[ODBC]
DRIVER=Centura SQLBase 3.5 32-bit Driver -NT & Win95
UID=
DB=ISLDSALE
SRVR=


Якщо ви або ваш замовник правильно використовуєте установки захисту Microsoft Windows NT, додавання системних джерел даних може стати важким завданням – адміністратор повинен увійти в систему на кожній машині або вам потрібно буде шукати спрощене, але все одно складне, рішення для установки системних імен DSN на великому числі комп’ютерів. Використання користувальницьких DSN простіше, вони персональні і можуть бути додані без використання адміністраторських прав. Але ви будете зобов’язані перевіряти їх існування кожен раз, коли додаток використовується для певної бази даних. Видалення програми теж може стати проблемою, тому що ви не знаєте, скільки джерел даних існує на кожній машині (або ви повинні перевірити це). Якщо ваш додаток з’єднується тільки з однією конкретною базою даних, вам не потрібно турбуватися про ці проблеми.


Кращим рішенням (для мене) буде використання файлових джерел даних. Я розміщую файли DSN на поділюваному мережевому диску в каталозі з іменем “ODBC”, який знаходиться прямо в каталозі встановленого додатки (якщо воно запускається через мережу). Не потрібно встановлювати ніяких спеціальних шляхів для кожного клієнта – на кожній машині повинні бути правильно встановлені тільки компоненти ODBC. Ви можете встановити повний шлях і ім’я файлу DSN, який буде використовуватися з Crystal Reports, за допомогою RDC. Ім’я користувача і пароль не повинні зберігатися у файлі DSN. Замість цього, програма має передавати SqlUser і SqlPassword програмно, з метою забезпечення безпеки.


Виконання звітів


Я визначив клас cCrystalReports, який охоплює всі функціональні можливості. Він наведений у вихідних кодах для того, щоб ви могли його використовувати і розширювати. Виклик функції “construct” встановлює зв’язок з інтерфейсом, виконавчі RDC. Так само тут встановлюється зв’язок з поточною базою даних. Кожен звіт, що відкривається за допомогою цього класу, може повторно використовувати з’єднання, одноразово встановлене в конструкторі.



Functional Class: cCrystalReports
Class Variables
Variant: vOpt
Instance Variables
CRAXDRT_Application: oCRApplication
CRAXDRT_Ireport: oCRReport
Functions
Function: construct
Description:
Returns
Boolean:
Parameters
Static Variables
Local variables
Boolean: bOk
Variant: vDatabase
Variant: vUser
Variant: vPassword
Actions
Set bOk = TRUE
!
Set bOk = bOk AND oCRApplication.Init( )
!
Set bOk = bOk AND oCRApplication.SetMatchLogOnInfo( TRUE )
Set bOk = bOk AND vDatabase.SetString( SqlDatabase )
Set bOk = bOk AND vUser.SetString( SqlUser )
Set bOk = bOk AND vPassword.SetString( SqlPassword )
Set bOk = bOk AND oCRApplication.LogOnServer( “PDSODBC.DLL”, m_sODBCDataSource, vDatabase, vUser, vPassword )
!
Return bOk


Як тільки створення екземпляра успішно завершено, звіт може бути відкритий за допомогою функції openReport (). Значенням методу, забезпечуваним CRAXDRT_Application, є oCRReport, яке в свою чергу є змінною екземпляра класу.



Function: openReport
Description:
Returns
Boolean:
Parameters
String: p_sFileName
Static Variables
Local variables
Boolean: bOk
Variant: vOpenMethod
Actions
Set bOk = TRUE
!
! open report
Set bOk = bOk AND vOpenMethod.SetNumber( crOpenReportByTempCopy, VT_I2 )
Set bOk = bOk AND oCRApplication.OpenReport( p_sFileName, vOpenMethod, oCRReport )
! *** To Do ***
! – en/disable parameter prompting
! – do other initialisation tasks
!
Set __sFileName = p_sFileName
!
Return bOk


Фрагмент, зазначений “*** ToDo ***”, Може, наприклад, використовуватися для призначення або запиту певних параметрів. Інакше Crystal Reports запросить їх у вас через свій власний діалог параметрів.


Важливе доповнення


Написання коду на основі наведеної вище інформації може викликати наступну проблему: якщо виконуваний модуль Crystal Reports звільняється за допомогою функції destruct (), ви помітите, що всі ваші зв’язку з SQLBase зникнуть. Ця помилка / проблема існує досить довгий час. Це пов’язано, швидше за все, з Crystal Reports, або що ще більш імовірно, з драйвером ODBC. Судячи з усього власні зв’язку бази даних не враховуються при відкритті обробника зв’язку з базою даних. Від’єднання останнього ODBC приводить до звільнення всіх обробників вивільняється процесу. Мені здається, що це результат свого роду збірки сміття – з помилкою.


Існує обхідний шлях, що дозволяє вам використовувати комбінацію власних і заснованих на ODBC зв’язків з SQLBase в рамках одного процесу.


Перед показом першого звіту, додаток SQLWindows ініціалізує обробник середовища ODBC, з’єднує його з базою даних і від’єднує його відразу після цього. Однак обробник продовжує існувати все час життя програми. Після від’єднання всіх власних зв’язків SQL, обробник середовища звільняється, що не призводить до некоректності будь-якого з непотрібних обробників.


Цей обхідний шлях має й іншу перевагу: під час запуску програми ми переконуємося в тому, що звіт може бути успішно відкритий і роздрукований.



Function: ODBCConstruct
Description:
Returns
Boolean:
Parameters
Static Variables
Local variables
Boolean: bOk
cRegistry: oReg
String: sValue
Actions
Set bOk = TRUE
!
Set bOk = bOk AND m_oODBC.construct( )
! Check Crystal Reports registry entries
Call oReg.SetRootKey( HKEY_CURRENT_USER )
Set bOk = bOk AND oReg.OpenKey( “Software/Seagate Software/Crystal Reports/DatabaseOptions/OuterJoin”, TRUE )
If bOk AND NOT ( oReg.ReadString( “PlusEqual”, sValue) OR sValue!= “” )
Set bOk = bOk AND oReg.WriteString( “PlusEqual”, “c2gup12;c2gup13;c2gup14” )
Set bOk = bOk AND oReg.CloseKey( )
!
Return bOk


Function: ODBCDestruct
Description:
Returns
Boolean:
Parameters
Static Variables
Local variables
Actions
Return m_oODBC.destruct( )


Function: ODBCValidateConnect
Description:
Returns
Boolean:
Parameters
Static Variables
Local variables
Boolean: bOk
Actions
Set bOk = TRUE
!
Set bOk = bOk AND m_oODBC.connectFromFileDSN( hWndNULL, m_sODBCDataSource, ODBC_DRIVER_NoPrompt )
Set bOk = bOk AND m_oODBC.disconnect( FALSE )
!
Return bOk


Приклад програми та вихідний код


Всі файли, за винятком CrystalReports2.app, можуть бути прямо використані у вашому проекті. Якщо ви захочете поекспериментувати з прикладом програми, вам за допомогою текстового редактора потрібно буде змінити номер версії у файлі Island Outfitters Sample.dsn.


Параметр в m_oODBC.disconnect () змушує залишатися активним обробник середовища ODBC, хоча з’єднання з базою даних розірвано. Ви можете захотіти заглибитися в деталі коду, щоб розібратися, як це працює.


Постскриптум …


Зверніть увагу на функцію ODBCConstruct () в доданому прикладі програми. Вона використовує функцію Registry.apl, Описану деякий час тому в статті Joe Meyer з Centura Pro. Ця функція перевіряє / додає специфічні для драйвера параметри в гілку реєстру для Crystal Reports. Це робиться з використанням синтаксису OuterJoin. Ви можете знайти додаткову інформацію про це за адресою www.support.seagatesoftware.com. Я рекомендую додати її в ваш додаток, якщо ви використовуєте Crystal Reports для перевірки, що зовнішні об’єднання працюють правильно з драйвером ODBC для SQLBase.


Висновок


Це не так просто, як “включив і працюй”, але, вивчивши кілька статей, ви зможете створити дуже цікаву комбінацію Crystal Reports з Centura Team Developer 1.5.x і 2000. Не соромтеся використовувати опубліковані бібліотеки у своїх власних проектах.


Ось список положень, висвітлених у цій статті, на які слід звернути увагу:



Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*