🚀 go-pugleaf

Janusz Baranowski wrote:
> 
> Krzysztof Czuryło napisał:
> 
> > O ile mi wiadomo, dane i aplikację można rozdzielić. Nie widzę
> > przeszkód w kompilowaniu aplikacji. I byłoby fajnie, gdyby taka
> > kompilacja była możliwa. MDE i Run-time to nie to samo co EXE.
> 
> Niestety Krzysztofie, w Accessie nawet po podziale na dane i aplikacje w
> bazie stanowiacej aplikacje bedziemy mieli rozne tabele systemowe. Jest
> wiec tak jak twierdzi Stanley, ze nic nie wyjdzie z execa i musimy
> zostac przy runtime. Jesli zas ktos chce plik exe to zawsze jest np.
> Visual Basic.

Dzieki Januszu za poparcie :-) 
Ponadto podzial accessowej bazy na plik z tabelami przechowujacymi dane
oraz plik aplikacji (formularze, rapoty itd.) nie zawsze jest taki
oczywisty. Np. ja w swoich plikach aplikacji czesto stosuje lokalne
tabele, ktore przechowuja np. preferencje uzytkownika na danym
stanowisku. I co taki hipotetyczny kompilator mialby z tym zrobic?
Powiedziec "sorry, nie skompiluje, bo masz w pliku jakies tabele, zrob
cos z tym" ? Nie wspomne o tym, ze przeciez w kazdej chwili aplikacja
moze "sama" programowo w pliku .mdb utworzyc (czy usunac) jakis obiekt,
chocby wlasnie tabele. I co wowczas? Kompilator mialby najpierw badac
caly kod, makra, czy nie ma przypadkiem w nim jakiegos polecenia np.
importu formularza?

Zreszta swoje zdanie na temat runtime vs "kompilatora" w Accessie
wyrazilem dosyc niedawno na grupie bazy-danych. Poniewaz wowczas osobnej
grupy msaccess jeszcze nie bylo, przytocze je jednak nizej (troche
przydlugie, nie zainteresowani moga nie czytac ;-)

Pozdrawiam -
	Stanley

PS. Odnosnie innego listu w tym watku - nie wkurzylem sie (no moze
troszeczke ;-), aczkolwiek rzeczywiscie chyba z 10E6 razy odpowiadalem
(i nie tylko zreszta ja), ze nie ma czegos takiego jak kompilator .mdb
do .exe. I byc moze bede odpowiadal nastepne tyle razy, dopoki mi sie
Access nie znudzi ;-) Przytoczylem tylko wypowiedz jednego z
dyskutantow, ktora - tak uwazam  - krotko i bardzo dobrze obrazuje
problem.

-----------------------
Tomasz Sosiński wrote:
> 
> Krzysztof Kolaczkowski wrote:

> > >> ps. mozesz korzystac z tzw. run-time Accessa dostepnego w Access
> > >> Developers Toolkit, ale tak czy tak to nie jest exe :-(
> > >

(tutaj moje...)
> > >Sorry, ze moze glupio sie spytam, ale skad ten smutek odnosnie > > >.exe?
> > >W koncu jak sie odpowiednio wykona aplikacje, to z punktu widzenia
> > >uzytkownkia zachowuje sie ona jak wykonywalny program. A czy "w
srodku"
> > >jest to .exe, czy runtime, Access czy cokolwiek innego - to
przecietnego
> > >usera z reguly nie interesuje (tak przynajmniej uwazam).
(end tutaj moje ;-)

> > Smutkiem jest np to, ze jesli odpowiednio nie zabepieczysz
> > bazy to kazdy bardziej rozgarniety user posiadajacy Access
> > moze ja rozebrac na kawalki.
> >
> > Albo to, ze najmniejsza aplikacja w Accesie ciagnie za soba
> > ogona w postaci MSARN cos tam.
> >
> > Pozdrawiam,
> > K.
> 
> jest jeszcze jedna sprawa: bezpieszczenstwo systemowych baz danych
> (mda/mdw), koniecznosc "dalaczamnia" podczas instalacji zabezpieczonej
> bazy itp.. Poza tym IMHO turdniej sprzedac mdb/mde niz exe.
> 
> nie wspominajac o _koszcie_licencji_. O ile wiem msarnxxx.exe kosztuje
> prawie tyle samo co msaccess.exe. (exec raz skompilowany rozprowadzasz
> za darmo).
> 
> Swoja droga, mdb powienien sie kompilowac do exe i chodzic samodzielnie
> ew. z vbrun
 

Przede wszystkim: nie zamierzam dyskutowac i udowadniac wyzszosci
runtime nad skompilowanym exe (lub odwrotnie; czyli wyzszosci swišt...
nad... itd.). Uwazam po prostu, ze w przypadku Accessa jest jak jest.
Jak zauwazyl tutaj kiedys jeden z dyskutantow  - trudno byloby
skompilowac cos, co w srodku moze zawierac tabele, indeksy, itp. A nawet
jesli ktos uwielbia ;-) przechowywac dane w formacie .mdb, moze tworzyc
interfejs uzytkownika w innym narzedziu, np. VB czy Delphi'm.

Co do zabezpieczen - zgoda, sam sie czasem wkurzam, ze aby zrobic
aplikacje w miare "odporna" na dociekliwych userow, trzeba sie troche
pomeczyc, a i tak w sumie efekt niezbyt pewny, w koncu nie ma rzeczy
zabezpieczonych na 100%  (zreszta dla Accessa jest "uzytek" 'GetAccess'
choc dziala w ograniczonym zakresie;  w A'97 jest juz troche lepiej -
mozliwosc konwersji do .mde, co przynajmniej "zabezpiecza" formularze,
raporty i kod). Ale: w zamian mam niejako gotowy, wbudowany system
zarzadzania kontami, nadawania uprawnien do obiektow, co w wielu
przypadkach jest b.przydatne. Np. ostatnio zrobilem "na szybkiego"
(zadanie z serii "na wczoraj" ;-) aplikacje pracujaca w sieci, ok. 30
stanowisk, w sumie utworzonych w Accessie ok. 50 kont uzytkownikow -
mozliwosc stosunkowo latwego przyznawania uprawnien, np. ze jedni moga
tylko odczytywac dane, inni je modyfikowac itp. (a jeszcze inni wcale
nie moga dostac sie do bazy ;-) , bardzo sie przydala. 

Zreszta, jak przynajmniej glosi napis na oryginalnych ksiazkach (mam
akurat od A2.0) jest to 'System zarzadzania relacyjnymi bazami danych'.
Tworzenie aplikacji dla "koncowego uzytkownika" jest jedna z mozliwosci
pracy z tym programem, choc tak naprawde nie bardzo wyobrazam sobie  pań
Zos, Krys, Marys, samodzielnie tworzacych w biurze, dostosowane do ich
wlasnych potrzeb zapytania, formularze, raporty, (kod?) itd., ;-) 
(zalozmy, ze struktura bazy jest juz gotowa, zrobiona przez
informatykow).

Co do "ogona" w postaci msarn.exe. Nie jestem w tych sprawach specem,
ale wydaje mi sie ze taka biblioteka "vbrun" w przypadku Accessa jest w
pewnym sensie wlasnie plik msarn200.exe (mowa o A2.0; w runtime A'97 nie
wiem jak to dokladnie wyglada, zapewne podobnie). W koncu nigdy nie
wiadomo z czego "skorzysta" dana aplikacja, np. z modulu zarzadzania
kontami, czy wrecz sama programowo przeprojektuje pewne swoje elementy.
Uwazam, ze skompilowanie tego wszystkiego (oprocz msarn sa oczywiscie
inne biblioteki, choby te stanowiace wlasciwy silnik bazodanowy) daloby
w efekcie plik o  dlugosci kilku MB, czyli tyle ile zamuje przecietna
instalka aplikacji runtime (w A2.0, w A97 zapewne sporo wiecej). A
dzieki temu, ze jest to runtime, w przypadku aktualizacji aplikacji,
wystarczy z reguly podmienic jeden, zwykle stosunkowo nieduzy plik .mdb,
a nie dostarczac i wykonywac od nowa cala instalke. Po drugie, w
przypadkach "awaryjnych", gdy trzeba np. szybko na miejscu poprawic
aplikacje, wystarczy msarn200.exe zastapic plikiem msaccess.exe - i juz
mamy "projektowalnego" Accessa (wyprobowane w A2.0, nie wiem jak jest w
A97, moze ktos odpowie?).

I jeszcze na koniec - o ile mi wiadomo, nabycie pakietu runtime uprawnia
do nieograniczonej dystrybucji wlasnych aplikacji. Na temat ceny :-( (tu
faktycznie smutek...) ADT czy ODE sie nie wypowiadam...

Pozdrawiam -
        Stanley

PS. Z gory sorry  panie Zosie, Krysie itd., tworzace samodzielnie
interfejs w Accessie czy czymkolwiek innym... ;-)