Access2003 - savet

Ako može jedan pametan savet a vezan je acces2003 i uopšte baze podataka.

Problem: Aplikacija je razvijena u access2003 sa dva mdb-a: back-end sa podacima (oko 80 tabela sa uspostavljenim relacionim vezama) i front-end programski deo sa
formama, upitima, izveštajima i sl. U back-endu nema i jedan jedini red koda, ni jedan izvešta, upit ili sl. samo tabele sve se nalazi u front end mdb-u. Podaci se gomilaju
i rastu i to postaje priličan broj zapisa (0.5m trenutno) sa tendencijom eksp. rasta. Programski deo je alat koji te podatke obradjuje sa jako mnogo VBA koda na
formama a i na izveštajima (gotovo se sve radi preko koda a izveštaj se koristi samo za formatiranje). Naravno da postoji veza sa MS WORD-om da bi se neki
dokumenti prikazali i dodatno obradili. Aplikacija ima neke funkcije DMS-a. Gde je kvaka? Pa to što se broj zapisa povećava, što to sve radi u mreži a i to što ima mnogo
zaista mnogo VBA koda na front end strani. Sve se ovo koristi svaki radni dan bez mogućnosti da se interveniše na back-endu zato što su tabele u
upotrebi. NApomena: pri obradi podataka kroz VBA su korišćeni SQL stringovi za formiranje upita.

Šta uraditi kada se ovako nešto dogodi, šta je pametno uraditi i preći na neko rešenje orijentisano na web.

Ovo sto si opisao deluje kao preporucljiva strategija. Back-end plus front end sa VBA kodom. Jedino sto ne vidimo iz teksta je gde je front end, da li na lokalnim stanicama ili je na serveru. Nije dobro ako je front-end na serveru pa ga korisnik startuje sa servera. Jos je gore ako mogu dva korisk=nika d astartuju isti front end, koji sedi na serveru. Access to dozvoljaba i cak moze i da radi neko vereme bez problema, ali nije dobro, jer pre ili kasnije se nesto zaglavi.

Ne znam sta tacno znaci 0.5m za velicinu back-enda, sigurno nien 0.5 MB. Access back end moze da raste do 1 GB teorijski. U praksi je manje, i uz redovno kompaktovanje i solidnu konfiguraciju mreze sve je OK, vidjao sam baze velike 300 MB koje rade lepo, a vidjao sam i prazne baze koje se zakoce i nece da prime ni jedan jedini rekord jer je sistem lose konfigurisan (tabele i kod u istoj bazi, na serveru, pristup vise korisnika odjednom)

Ako sve lepo radi, neka radi i dalje. Prelaz na web nece ti resiti probleme ni brzine ni broja korisnika, a izgubices mnogo od funkcionalnosti koje imas u ovom trenutku. Ako si pod 'prelaz na web' mislio u stavri 'premestanje back-end na SQL tip baze (MS SQL, ORQCLE i slicno)' to moze da se uradi i da front end ostane Access/VB/VBA. Medjutim, ne mgu se jednostavno tabele iz Access back enda prekopirati u MS SQL, linkovati i nastaviti rad kao normalno. To ce tek da uspori sistem, gore nego zagusena mreza, jer podaci putuju kroz istu mrezu, i imas jos i usporenje jer SQL server radi svoje dodatne provere i kontrole. Prelaz sa Access back enda na SQL je ozbiljna operacija, zahteva dosta razmisljanja, planiranja i ima puno posla, i na back-end i na front-endu. U tom momentu imas dobru sliku o tome sta sistem treba da radi i kako, i to je dobro, ali sve ostalo manje vise mora da se odradi nanovo.

Sve u svemu, ako sistem radi, ne diraj ga.

Da bi i Zidar stekao sliku evo još malo objašnjenja

Veličina baze je oko 400Mb sa brojem tabela kako sam već naveo (ovo je ukupna cifra a ne samo glavna tabela! U glavnoj tabeli ima oko 40.000 zapisa!). Ima tendenciju da raste oko 100Mb godišnje. Kad se uradi Compact i Repair pdane to na oko
150Mb (sada) što svakako još nije granica. Procena je da trena razmišljati o prelasku na nešto "ozbiljnije" u narednih par godina uz rad sadašnjeg sistema.

Sve radi u mreži. Mreža je 100Mb/s sa oko 100računara. Jedan server je samo za podatke ove aplikacije i nešto malo korisničkih file-ova. Sve je na UPS
uredjaju od 1.5kW (server, switch...) sa eksterni m baterijama.

Back-end je na serveru a Front-end je kod klijenta. Da bi se lakše instalirale nove verzije front-end-a na serveru se nalazi folder
u koji se stavljaju nove verzije. Kod klijenta je napravljen batch file koji prilikom startovanja sa servera kopira na klijentski računar
najnoviju verziju front-end-a i parametarski file. Sam front end je parametrizovan i čita podatke o tome gde se nalazi back-end mdb
kao i naziv samog back-end mdb. Radi proveru konekcije tabela i ....

Back-end je u velikoj meri pripremljen da može da se poveže na SQL server (otvaranje tabela, recordset i dr.) i sve što se radi
sa podacima se radi preko SQL upita koji se formiraju preko koda (veoma malo se koriste standardni acces upiti). Nekda davno je pokušan prelaz
da back-end bude SQL server ali to nije funkcionisalo kako treba nešto zbog neprilagodjenosti front-end a nešto i zbog same brzine.

Trenutno je neki prosek klijenata koji u odredjenom trenutku koriste ovu aplikaciju oko 20+-5 na dnevnom nivou sa tendencijom porasta.
Inače sistem radi od 01.02.2008. godine i nije do sada pokazivao slabosti u funkcionisanju čak i uz stalne nadogradnje back-end-a i vrlo malo
promena na back-end-u (bila je tema poredjenja dva mdb baš zbog toga!).

Praksa je pokazala a nije mi jasno zašto čika Bili to ne uzima u obzir da ako treba neki duži tekst od 255 char da se unosi onda se mora preći na
memo polje dok u SQL serveru se more koristiti varchar od 4096 char (mislim da je varchar) što je sasvim dovoljno. Lično ne volim memo i pokušao
sam da ga izbegnem kad god sam mogao ali jednostavno što se mora mora se.

Mislim da je back-end dobro koncipiran ali to bi trebao da potvrdi neko koje baš IT struke i majstor za baze. Nažalost ne mogu da vam pošaljem back-end
na vašu ocenu.

Pitanje br. 1 je samo dokle ovo može da radi a pitanje br. 2 šta ako neko hoće da se prikači i da koristi sistem a nije u lokalnoj
mreži (lokal na nivou objekta) već se nalazi u drugom objektu ili čak drugom gradu?

Zanima me vaše mišljenje, hvala!

Mala greška !

Front end (klijentski mdb) je pripremljen u velikoj meri za povezivanje na SQL server a ne back-end. Izvinjavam se!

Svaka cast. Deluje kao veoma profesionalno odradjen posao.

1 je samo dokle ovo može da radi a pitanje br. - verovatno jos podugo. Da je mreza problem ili bilo sta drugo, vec bi se do sada pokazalo

2 šta ako neko hoće da se prikači i da koristi sistem a nije u lokalnoj
mreži (lokal na nivou objekta) već se nalazi u drugom objektu ili čak drugom gradu? - VPN konekcija. Ako je fizicka veza dobra, onda nema problema. Serveri koej moja forma koristi za 'lokalnu mrezu' u stvari sede u Bramptonu, 50 km od nase zgrade, a neki su u Chicagu. NE znam kako je to vezano, hardware nije moja oblast, nekad su se spominjale reci kao T1 ali mislim da su presli na nesto drugo. Ince, od kuce lepo radim preko VPN, konekcija je cable tv modem, DSL?

Napravite test bazu na SQL pa probajte

Srecno

Znao sam da Zidar uvek ima dobre odgovore !

Uh a sad još jedna muka, isprobavao sam konekcije sa udaljenih lokacija ali ovo je zemlja Srbija i nisu baš brzine
da se smrzneš. Dešavalo se da u zgradi koja je na par stotina metara ide sporo ali prihvatljivo (3 na skali od 1-5)
a onda iz Leskovca ili Vranja nije ni za 1 a onda u Mitrovici ili Novom Sadu radi za 4. E to je nešto što nikako
nije jasno i mislim da nikakav VPN ili bilo šta slično (ne poznajem hardver) neće u skorije vreme promeniti.

Al šta je tu je, poslušaću Zidara i napraviti ponovo test sa SQL serverom pa šta bude. U svakom slučaju
napisaću vam svoja iskustva.

Što se profesionalnosti tiče mislim da medju vama ima daleko većih profesionalaca i majstora možda
samo malo manje upornih.

Hvala još jednom svima!

Vas slucaj je kalsican primer potrebe za reinzenjeringom. Zahtevi korisnika, okruzenja, topologije i tehnologije diktiraju kakav model baze cete imati. Dobrim reinzenjeringom zadovoljicete te zahteve. Cesto sam zbog problema koje ste istakli modelirao bazu tako da sto vise umanjim negativan uticaj okoline o kojoj ste rekli. SQL Server je proveren izbor. Preporucio bih Vam da za reinzenjering baze koristite CASE alat ERwin kojim cete mnogo lakse i brze uraditi model baze.

Potpis

http://zoraneremija.wix.com/eremijacv