Румяна Цанкова Владимир Л. Станчев Работа с бази от данни в примери на access 2003 2007


Създаване на активни страници - Pages за достъп чрез Web SERVER до база данни на Access 2003 – четене и внасяне на данни



Изтегляне 3.1 Mb.
страница14/20
Дата13.11.2018
Размер3.1 Mb.
#104752
ТипГлава
1   ...   10   11   12   13   14   15   16   17   ...   20

Създаване на активни страници - Pages за достъп чрез Web SERVER до база данни на Access 2003 – четене и внасяне на данни

На основата на таблици, заявки, отчети и формуляри от Access 2003 могат да бъдат разработени „активни страници” - Pages за достъп до базата от данни чрез Web пространството на Internet. Тази цел се постига чрез ползване на проектиране - Design или на Съветник – Create data access page by using wizard за създаване на обекти от тип Pages. Друга възможност за създаване на Pages от съществуващ обект e чрез меню File / Save as / as Data Access page.



Фиг. 14.4. Заявка използвана за създаване на активна страница.

От заявката Доставки показана на фиг. 14.4. може да се изгради активна страница чрез Съветник. Резултатът е показан на фиг. 14.5. с добавена контрола за избор на имена на доставчици чрез комбиниран списък – Combo Box.



Фиг. 14.5. Резултат от работа със Съветника в режим - Design View.
На фиг. 14.6. е показана активната страница в действие за промяна в базата от данни през четец - Web Browser. В адресната част на четеца се вижда адреса на активната страница в локалния Web сървър. За да бъде достъпна през Internet след създаването си, активната страница трябва да бъде записана в работната област на локалния Web сървър: C:\InetPub\wwwroot

Фиг. 14.6. Активната страница в действие през четец - Web Browser.
Част III. Решени задачи



Решени задачи

с ACCESS,

VBA, ADO и SQL

Глава 15. Задача 1. База от данни за покупки и продажби.


Условие: Да се отразят покупките на едро и продажбите на дребно в малко предприятие чрез база от данни.

Целта на програмното решение е да се постигне пълно удовлетворяване на условията на задачата чрез ефективно проектиране на базата от данни с необходимите свързани таблици, формуляри, заявки, отчети и допълнителни обекти. Данните, въведени за проверка на качествата на създадената база от данни и нейните обекти, трябва да осигурят достатъчно разнообразие, за да може да се проследят всички особености при прилагане на решението.


    1. Д
      а се създаде базата от данни.


Фиг. 15.1.1. Проектиране на таблица Dostavchici.


Проектирането на база от данни по условието се основава на таблиците и техните връзки, дефинирани и изградени в Глава 8. Таблицата Dostavchici (фиг. 15.1.1.) е проектирана с брой и тип полета, достатъчни за обхващане на данните за доставчиците на малкото предприятие. Въведените начални данни са показани на стр. 62. Таблицата Dostavki е проектирана (фиг. 8.9.) с брой и тип полета, достатъчни за обхващане на данните от доставките на предприятието. Въведените данни са представени на фиг. 8.15.

Таблицата Nomenklatura с въведени начални данни (стр. 62) е проектирана с брой и тип полета достатъчни за обхващане на номенклатурата на-продуктите-в-предприятието-(фиг.-8.10.).


Фиг. 15.1.2. Проектиране на таблица Klienti.
Т
аблицата Klienti е проектирана с брой и тип полета, достатъчни за обхващане на клиентите на предприятието. Въведените начални данни (стр. 63) са подходящи за проверка на решението.

Фиг. 15.1.3. Проектиране на таблица Prodazbi.


Таблицата Prodazbi с въведени първоначални данни (стр. 63) е проектирана с брой и тип полета, достатъчни за обхващане на продажбите на предприятиетов(фиг.15.1.3.).

Фиг. 15.1.4. Проектиране на таблица Razprostraniteli.

Таблицата Razprostraniteli с въведени начални данни (стр. 63) е проектирана с брой и тип полета, достатъчни за обхващане на разпространителите към предприятието (фиг. 15.1.4). Проектирането на ключовите полета и връзките между таблиците са показани в Глава 8.

    1. Да се създаде формуляр за доставки и да се въведат данни.


За удовлетворяване на условието (15.2.) е достатъчно изграждане на формуляр с подформуляр (съдържащ падащ списък Combo box) за избор на доставчиците по име. Видът на проект-формуляра е показан на фиг. 15.2.1. Проектирането на формуляра може да се основава на примера в Глава 12. Въведените данни трябва да носят дати от един календарен месец. Трябва да се забрани възможността за въвеждане на данни в полетата, свързани с таблица Nomenklatura.



Фиг. 15.2.1. Формуляр с данни за доставки.

    1. Да се изготви отчет за доставка на стоките, чиито остатъчни количества в резултат на продажбите са спаднали под норматива.

За удовлетворяване на условието (15.3.) са достатъчни данните от таблици Dostavki, Prodazbi и Nomenklatura. Проектирането и изпълнението на няколко заявки за избор по поставеното условие ще изгради основата на решението на задачата в последователни стъпки. Първата заявка за избор трябва да осигури изчисляване на сумата от количествата доставени стоки в групи по поле ProduktNo. Заявката ще бъде именувана a11SumDKolichestvo. В резултат на тази заявка за всеки продукт (ProduktNo) трябва да се сумират доставените-количества. ва.


Фиг. 15.3.1. Проектиране на заявката за определяне на сума от количествата доставени стоки.
При проектирането (фиг.15.3.1.) на заявката (на основата на примерите в Глава 9) трябва отчетливо да се определят основните значими елементи:

  • Видът на резултата да бъде в таблична форма (фиг. 15.3.2.) с колони – полета (ProduktNo и Kolichestvo) от таблица Dostavki (фиг.15.1.3).

  • Формата на заявката да осигури яснота в резултата чрез избор на минимален брой полета за показване с подходящо форматиране. Полетата EdinichnaCena и Stojnost са включени за ползване в следващи условия.

  • Подредбата на данните да бъде зададена в ред Sort като сортировка във възходящ ред по поле ProduktNo.

  • Обобщения за определяне на показваните в резултата данни ще се ползват в реда Total на полета Kolichestvo и EdinichnaCena, съответно с функциите за сума - Sum и за средно аритметично - Avg.


Реализацията на проектирането на заявката може да започне чрез Съветник – Create / Query Wizard и да завърши в режим за проектиране Query Design (фиг. 15.3.1.) във вид на заявка за обобщение - Total. Заявката се изпълнява-чрез-Run-или-Open.

Фиг. 15.3.2. Заявката за сумата на количествата на доставките.

При проектиране на заявката за обобщение не трябва да се допусне грешката да се опитва едновременно изчисляване на сумата от количествата на доставените и на продадените стоки чрез свързване на противоречиви за обобщаване таблици (Dostavki и Prodazbi). Противоречието се изразява в невъзможността да се групират записи с различно съдържание макар и с еднакъв ProduktNo. Затова погрешно е свързването с таблица Prodazbi, дори и без да се използва поле от нея. Ако се допусне тази грешка, при изпълнението на проектираната заявка (фиг. 15.3.3.) ще се получи предупреждаващо съобщениев(фиг.-15.3.4.)-или-грешен-резултат.




Фиг. 15.3.3. Погрешно свързани таблици за изчисляване на сумата.



Фиг. 15.3.4. Предупреждаващо съобщение при изпълнение на погрешно свързани таблици за обобщение.
Втората заявка за избор трябва да изчисли сумата от количествата продадени стоки, групово обобщени по поле ProduktNo. Заявката ще бъде именувана a11SumРKolichestvo. В резултат на тази заявка за всяка стока (ProduktNo) трябва да се изчисли общата сума от продадените количества.Ф

Фиг. 15.3.5. Заявката за определяне на сумата от количествата

продадени стоки в изглед Design View.
П
ри проектирането, изграждането и изпълнението на тази заявка ще приложим същия подход както при първата заявка. Затова крайният резултат е подобен (фиг. 15.3.6.).
Фиг. 15.3.6. Заявката за определяне на сумата от количествата продадени стоки в табличен изглед - Datasheet View.
Третата заявка е за избор на стоките с остатъчни количества спаднали под норматива. Данните в заявката трябва да са групово обобщени по поле ProduktNo. Заявката ще бъде именувана a11PodNormativa. В резултат на тази заявка спадането под норматива за всеки ProduktNo ще се представи в колона с “Да”.

При проектирането на този заявка трябва особено точно да се определят значимите елементи:


  • Видът на резултата да бъде представен в таблична форма (фиг. 15.3.10.) с колони – полета (ProduktNo, Kolichestvo, Ostatak, Normativ, PodNormativa), избрани от свързани “едно към едно” заявка a11SumDKolichestvo, таблица Nomenklatura и заявка a11SumРKolichestvo.




Фиг.15.3.7. Съставителят на изрази - Expression Builder сe ползва за съставяне на функция – IIf (проверка на условие “ako”) в израз.



  • В заявката да се осигури яснота в резултата чрез избор на минимален брой полета за показване с подходящо форматиране.

  • В
    полето Ostatak – ред Field трябва да се съдържа израз за изчисляване на разликата между доставеното количество и продаденото количество на всяка стока: Ostatak:[a11SumDKolichestvo]![SumOfKolichestvo]- [a11SumPKolichestvo]![SumOfKolichestvo]

Фиг. 15.3.8. Съставителят на изрази - Expression Builder може да се ползва при съставяне на израз в изчисляемо поле и за задаване на име на изчисляемото поле – “PodNormativa”.


В изчисляемото поле PodNormativa – ред Field чрез Expression Builder (фиг. 15.3.8.) e записан израз, съдържащ функцията “Ako” - IIf (чрез която се постига отбелязване с “Да” на стоките, чиито остатъчни количества /доставени - продадени/ са спаднали под норматива).

        PodNormativa:

        IIf([a11SumDKolichestvo]![SumOfKolichestvo]

        -[a11SumPKolichestvo]![SumOfKolichestvo]

        <[Nomenklatura]![Normativ];"Да";"Не").




  • В
    ред Criteria на полето PodNormativa е записан като критерий символният низ “Да”. По този начин в резултата на заявката ще присъстват само записите, съдържащи “Да” в това поле.

Фиг. 15.3.9. Заявката за избор на стоките с остатъчни количества, спаднали под норматива в изглед Design View.



  • П
    одредбата на данните се подразбира като сортировка във възходящ ред по поле ProduktNo (защото данните в свързаните заявки и таблици са предварително сортирани).

Фиг. 15.3.10. Заявката за избор на стоките с остатъчни количества, спаднали под норматива в табличен изглед.



        Видът на резултата, представен в таблична форма (фиг. 15.3.10.) е със наименования на колоните – полета на латиница (например Normativ). За да се подобри заявката, трябва да се поставят наименования на кирилица чрез избор на Properties от контекстното меню на реда Field и задаване на новото наименование-в-Caption-(фиг.15.3.11).


Ф
иг. 15.3.11. Задаване на наименование на поле на кирилица чрез Caption в Properties от контекстното меню на реда Field.


Фиг. 15.3.12. “Заявка за определяне на стоките с остатъчни количества, спаднали под норматива” в табличен изглед.

  • Крайният резултат от изпълнението на “Заявка за определяне на стоките с остатъчни количества, спаднали под норматива” удовлетворява условието и е представен в таблична форма (фиг. 15.3.12.) със заглавия на колоните на кирилица.


Отчетът за показване на списък за доставка на стоки с количества, спаднали под норматива трябва да бъде изготвен във връзка със заявка a11PodNormativa и подреден по поле ProduktNo. Отчетът ще бъде именуван “Списък за доставка на стоки с количества под норматива”. В този отчет ще се покаже крайният резултат от решението на поставеното условие.

При проектирането на отчета трябва да се определят значимите съставки:


  • Видът на резултата да бъде представен в таблична форма (фиг. 15.3.19.) с колони (Продукт No, Наименование, Остатъчно количество, Норматив и Под норматива), избрани от заявка a11PodNormativa (фиг.15.3.12). Формата да осигури яснота в резултата чрез избор на минимален брой колони и редове за показване с подходящо форматиране.

  • Подредбата на данните да бъде зададена според сортировката в заявката (във възходящ ред по поле ProduktNo). Да бъде осигурено номериране на редовете в отчета.

  • Обобщения за показваните в резултата данни няма да се ползват.


Реализацията на проектирането на отчета може да започне чрез Съветник от Create / Report Wizard и да завърши в режим за проектиране Design (фиг. 15.3.18.). Отчетът се изпълнява се чрез Open.

Фиг. 15.3.13. Прозорецът за избор на Съветник за отчети с попълнено име на заявката, която осигурява данните за отчета.



        Подборът на полета е подобен на избора на полета при създаване на заявки.


Фиг. 15.3.14. Прозорецът на Съветника с вече подбрани полета (всички полета от заявката).


Съветникът дава възможност чрез последователност от диалогови рамки да се проектира отчета в подробности (виж Глава 11). Предлага се последователно да се усъвършенства вида на отчета и с бутон Next да се преминава към следваща настройка. Изборът на блоково подреждане на данните в отчета (фиг. 15.3.15.) е подходящ за данни, разположени в неголям брой колони.

Фиг. 15.3.15. Прозорецът на Съветника с избрано

блоково подреждане на отчета – Block.


Фиг. 15.3.16. Прозорецът на Съветника за задаване на име

на отчета и приключване с Finish.
В резултат на проектирането чрез Съветник се получава отчет (фиг. 15.3.17.), който може да бъде усъвършенстван чрез допълнително проектиране в режим Design (фиг. 15.3.18.).

Фиг. 15.3.17. Отчетът, проектиран чрез Съветник в Design View.


П
ри допълнителното проектиране се добавя нова колона чрез контрола – (Text Box) за номериране на редовете – записите и се оформя отчетът по начина, описан в Глава 11.

Фиг. 15.3.18. Крайният вид на проектирания отчет.

Разглеждането на резултата се постига чрез Open, а отпечатването - чрез Print. Този отчет - списък (фиг. 15.3.19.) е решение на условие 15.3.

Фиг. 15.3.19. Отчетът - решение на условие 15.3.



    1. Изтегляне 3.1 Mb.

      Сподели с приятели:
1   ...   10   11   12   13   14   15   16   17   ...   20



©obuch.info 2024
отнасят до администрацията
    Начална страница
Автореферат
Анализ
Бизнес-план
Биография
Глава
Диплом
Доклад
Задача
Закон
Занятие
Заседание