Як ефективно обробляти помилки у програмах Access, Access, Статті, Програмування -
Як вам добре відомо, програм без помилок не буває. Навіть такі монстри, як Microsoft, регулярно публікують списки офіційних багів, патчі і.т.д. У додатках з урахуванням Access , розроблюваних одним-двома програмістами ймовірність появи помилок ( Run - Time errors ) на стадії експлуатації дорівнює 100%. Наше завдання таким чином полягає не тільки в тому, щоб виключити помилки на стадії програмування та тестування, але й ефективно виявити та усунути неполадки в процесі роботи. Тут виникає 2 проблеми:
1) Технічна. Як правило, помилки на стадії експлуатації виникають при збігу кількох факторів, усі комбінації яких наперед протестувати неможливо. Для усунення таких помилок необхідно насамперед їх відтворити та зрозуміти причину. Однак, як правило, це важко: розробник може бути вилучений в просторі і часі, користувач може не запам'ятати за яких умов сталася помилка.
2) психологічна. Цей користувач, не зацікавлений у процесі налагодження. Він справедливо вважає, що це справа розробника, і всілякі повідомлення про помилки, а тим більше зупинка і перехід в режим налагодження викликають природне роздратування, яке може на ранньому етапі сформувати тривале негативне ставлення та недовіру до застосування, що є значною перешкодою для впровадження, ніж помилка.
Зіткнувшись у процесі роботи з цими проблемами, я дозволю собі запропонувати один із варіантів вирішення. Радий його обговорити, покращити, вислухати альтернативи. Також я буду радий, якщо мій досвід комусь допоможе
Компоненти рішення
Все сказане тут і нижче в основному відноситься до клієнта/серверної архітектури,де Access виконує роль клієнта, проте може бути поширено і на Access базу, що використовується в розрахованому на багато користувачів режимі.
Суть підходу у цьому, що це помилки перехоплюються, обробляються і користувачеві видається повідомлення у рядку стану, після чого робота триває. Коди помилок та значення важливих параметрів пишуться в таблицю на сервері, яка централізовано переглядається адміном, аналізується та вживаються відповідні заходи.
Отже, для отримання повної картини події нам допоможе наступна інформація:
1) Ім'я машини, на якій виникла проблема та ім'я користувача домену
Для того, щоб визначити ім'я робочої станції, на якій виконується Access, достатньо прочитати значення змінної оточення ENVIRON (“COMPUTERNAME”), та ім'я користувача – ENVIRON (“USERNAME”), однак у ряді випадків (наприклад, якщо у вас Win Me робочі станції з UNIX PDC) це може не спрацювати. Є більш надійний спосіб, заснований на API викликах – у доданому файлі ви знайдете Class Module SystemInfo, в якому реалізовані функції. Так чи інакше, нам знадобляться функції GetUserName() та GetCompName()