Який генератор звітів вибрав я
Delphi site: daily Delphi-news, documentation, articles, review, interview, computer humor.
Який генератор звітів я вибрав.
Замість прологуЧасто в різних форумах зустрічаю питання: "А де взяти нову версію ReportBuilder-а" або "А де знайти кряк для ReportBuilder-а" на яку є одна єдина відповідь: "Викинь це лайно і використовуй FastReport .". На жаль, життя показало, що не завжди лайно є лайном, а просто непогану річ не можуть правильно використовувати. Нижче я написав, з якими проблемами я стикався особисто, і як я їх вирішував. Почитайте, можливо вам не доведеться наступати на ті граблі, на які наступив я.
Постановка завданняНаприкінці 2001 року начальство спантеличило мене розробкою програми для масового друку газових квитанцій. Реальний друк проводиться на принтерах HP 8150 зі швидкістю друку близько 32 сторінок формату А4 в хвилину. Для передачі БД використовувався формат бази даних DBase-IV та компонент Карпова VKDBF для прямого доступу. До речі, компонент дуже крутий, і я всім його раджу спробувати, поки він безкоштовний. Машини, з яких виробляється (досі до речі) генерація та друк звіту мають таку конфігурацію: 1. AMD-233, 128Mb ОЗУ, 10Гб HDD 2. Celeron-333, 128Mb ОЗУ, 10Гб HDD Операційна система Windows NT WS із встановленим сервіспаком 5.
"Танці з бубнами"Перше завдання, яке я почав вирішувати - підвищення швидкості друку. Першу проблему вирішити не вдалося. Написав розробнику, і вони майже присягали запевнили мене, що вони вже самі думали в цьому напрямку, і "через пару місяців вийде нова версія, яка це все може бути реалізує". "Зрозуміло", подумав я, і вирішив зайти з іншого кінця. Думка, яка мені спала на думку: "чому Access може друкувати 32сторінки за хвилину, FoxPro теж може, а FastReport – ні? Проста тестова програмка, яка виводила на друк 1 рядок тексту, просто малюючи на канві принтера, сформувала файл у черзі принтера близько 45 кілобайт.При збільшенні кількості рядків до 20 розмір файлу в черзі практично не змінився. подумав я, "а як же зроблено у FastReporte." Подивився у вихідних текстах (слава богу, що їх дають), і за кілька днів розібрався.
Так робити не можна!Розробники FastReport-а пішли шляхом найменшого опору. Вони формують свою канву у вигляді вікна, малюють на ній сторінку, яка виходить у вигляді бітової карти, потім розтягують її за розміром канви принтера та друкують. Дешево й сердито. До чого там усілякі перерахунки дюймів у міліметри і назад. В результаті ось вам і 800 кіл у черзі замість 50. Ось вам і пам'ять для зберігання кожної сторінки в пам'яті. Уявіть собі: у мене звіт на 2000 сторінок, множимо на 800 = 1600 мегабайт пам'яті + ще стільки ж у системному каталозі Windows, поки це все не "ляже" в чергу друку і "лежатиме", поки не вийде на принтер. Природно такого ОЗУ ні в кого немає, все це "вийде", так що "гальма" моторошні і система "хрещиться" постійно. Виникло споконвічно українське запитання:А що робити?Оскільки Word і Excel формують сторінку так само, займає вона стільки ж, а саме рідні 800 кілобайт. Тому варіанти з написанням звітів на них відкидаються одразу. Accecc і FoxPro – втрачається автономність програми. В результаті глибинного копання "всесвітнього інформаційного смітника", під буржуйськимназвою InterNet, на світ було вилучено рішення.
Проблеми ReportBuilder-аПроблема з пожиранням пам'яті вилікувалася вимкненням CashePages. В результаті прога в пам'яті займає максимум близько 16 мегабайт на звіті 2500 сторінок. Проблема з продуктивністю Windows NT WS трохи складніша. Швидкість формування у мене із запасом, проте системі треба близько 30-40% продуктивності для того, щоб встигати SpoolManager-ом проштовхувати завдання на принтер, оскільки інтерфейс все-таки паралельний. Думаю, що на USB принтерах та оснащених мережевими картами цих проблем не виникне. Напрошувалося ще рішення – поставити NT Server, у якого не повинно бути подібних проблем, повісити на нього обидва принтери, об'єднати їх у пул (опція pooling) та формувати завдання на одній машині. У цьому випадку, я думаю, листи вилітали б на будь-який із вільних принтерів. Однак начальство сказало – break, систему ми міняти не будемо. Довелося повісити на таймер процедуру, яка гальмувала програму на 31 відсоток і при старті формування завдання (відсоток затримки був обчислений експериментально для цих робочих станцій, для інших конфігурацій це інший, але на машині Celeron 800, система WinXP і принтер LaserJet6L spooler їсть 20- % ресурсів, все-таки нікуди не подітися – паралельний інтерфейс). Ще я змінюю пріоритет завдання з нормального на низький, по закінченню природно повертаю назад. Як це зробити подивіться у порадах Озерова – там є приклади. Була ще ідея динамічно вимірювати завантаження системи та формувати динамічну затримку, але як це зробити я поки що не знаю. Може, хтось знає – відпишіть тоді. Проте все вилікувати не вдалось. Залишилася проблема із системою. Програма перестала їсти пам'ять і почала її культурно їсти. Однак ядро її як "жерло", так і"жере". Причому після відпрацювання завдання та навіть після завершення програми її не звільняє. Через війну, коли зайнята ядром пам'ять перевищує " залізні " 128 мегабайт – система часто " крішиться " . Часто з'являються глюки зі шрифтами що у формах. Чомусь форма зроблена в одній версії ОС не завжди може використовувати ті ж шрифти на іншій. Але це вже дрібниця.
МоральМораль проста: FastReport дуже хороший, коли звіт 10-20 або навіть 200 сторінок і швидкість друку принтера до 15 сторінок за хвилину або взагалі не важлива. Надійність і простота у поєднанні з потужністю та простотою вбудованої скриптової мови завоювала серця мільйонів і не оминула і мене. ReportBuilder, як кажуть, "йому і в підмітки не годиться", але коли важлива швидкість, продуктивність та апаратні ресурси - FastReport просто бажає кращого. Так що слово Fast у назві цього продукту виправдовує себе лише в одному сенсі, а саме можна швидко та просто намалювати 99% можливих варіантів друкованих форм.
PS2:Під час написання цієї статті натрапив на опитування на Delphi Plus, де було опитано понад 700 осіб і більшість із них – 28% використовують ReportBuilder, а FastReport – лише на 3 місці (15%), поступається навіть QuickReport-у (22%). Тож робіть висновки – колеги.