🚀 go-pugleaf

Tadeusz Główczyński wrote:
> 
>                                     Czeœć!
> 
> Problem:
> U kolegi odnalazłem zainstalowanš wersję A95, której nie chcę ruszać.
> Czy mogę dać mu swojš bazę w postaci nie odwołujšcej się do tego co
> zainstalowane?

Zaraz, po kolei. Skoro kumpel ma zainstalowanego A'95 to jaki problem
uruchomic u niego Twoja baze? Pod warunkiem ze jest ona w wersji A'95
(lub starszej), bo mdb robione pod A'97 na pewno nie pojdzie.

> Dla wersji 2 był kompilator - a tu?

Hm, a czy moglbys mnie (i innych) oswiecic gdzie takie cudo dla 2-jki (i
innych) widziales? Bo IHMO  dla Accessa kompilatora nigdy nie bylo i nie
bedzie... 

> Gdzie go znaleŸć i czy wersja skompilowana powołuje się na zainstalowane
> biblioteki?

Nie pozostaje mi nic innego jak poraz kolejny zacytowac pytanie (bardzo
mi sie podoba) Dymitra:
"NO LUDZIE POMYSLCIE! JAK MOZNA SKOMPILOWAC COS, CO W SRODKU MOZE
ZAWIERAC TABELE, INDEKSY???"

Stanley

To nie kompilator tylko Run-time!!! Oczywiscie istnieje dla ACC '97!

pozdrowienia

Stanley P napisał(a) w wiadomości:
<364845CF.1381BBB2@pertus.com.pl>...
|"NO LUDZIE POMYSLCIE! JAK MOZNA SKOMPILOWAC COS, CO W SRODKU MOZE
|ZAWIERAC TABELE, INDEKSY???"

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.

--
+- Krzysztof Czurylo                                             -+
+- Technical University of Gdansk & Medical University of Gdansk -+
+- krzycz2@SPAM.polbox.KILLER.com                                -+
+- remove 'SPAM.' and 'KILLER.' before reply !!!                 -+

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.

Pozdrawiam,
Janusz

Krzysztof Czuryło napisał(a) w wiadomości: <3648935f.0@news.vogel.pl>...
>Stanisław Starek napisał(a) w wiadomości:
><36488d3b.0@news.vogel.pl>...
>|To nie kompilator tylko Run-time!!! Oczywiscie istnieje dla ACC '97!
>
>No wiem, że nie kompilator. Chodziło mi o to, że pytania ludzi nie są
>takie głupie jak to ktoś sugerował. Jeśli ktoś nie wie jak to jest z
>Accessem, to może przypuszczać, że kompilacja do pliku EXE jest
>możliwa. (oczywiście kompilacja samej aplikacji, a nie aplikacji z
>danymi). Można to sobie wyobrazić. Jak wszyscy wiemy, Microsoft nie
>stworzył takiego narzędzia.
>


Stanley P na pl.comp.bazy-danych na pytanie Access i exe odpowiadł ze 30000
razy. Nie dziw się, że lekko się zirytował. ;-)

--
Tadeusz Olszewski
tadeusz-olszewski@elknet.pl

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... ;-)

Witam !

Stanley P napisał(a) w wiadomości: <36498A91.38EA9A7@friko.onet.pl>...

[...] nie bede cytowal bo dlugi list napisales.

Moze dopowiem cos od siebie.
Runtime w A97 wyglada w ten sposob, ze w wierszu polecenia podajesz komende
/runtime (w skrocie)
np.:
"C:\Program Files\Microsoft Office\Office\MSACCESS.EXE"   /runtime
"mojabaza.mde" /ini konfig.ini

Jak widzicie bezpieczenstwo jakby zmalalo ( moze sie myle? ).
Na dodatek instalacja runtime'a wyglada nieco dziwnie...
1. jak nie ma Accessa do katalogu okreslonego przez tworce bazy laduje sie
prawdziwy runtime ( tzn zwykly Access, ale jakies 2 biblioteki sa inne i nie
da rady go uruchomic jako Access)
2. gdy jest juz Access, instalator odnajduje go i dopisuje sie do
istniejacego pliku. ( tak tez to zrobil w zamieszczonym przezemnie
przykladzie <jak widac chyba>)

Bardzo ciekawe efekty sa gdy instalujemy pelnego A97 na zainstalowanego
runtime'a
Wogole to zauwazylem, ze najlepiej wywalic (mozna z reki) caly katalog z
runtime'm (cala baze) zainstalowac Office97, sa potem jeszcze raz runtime.

Ponadto mamy jak w banku, ze dowiemy sie na kogo byl zarejestrowany A97 Dev.
Runtime wpisuje te dane do ekranu startowego.
( UWAGA ! nie uzywalem nigdy programu do tworzenia instalek, tak wiec byc
moze czesc tych wad mozna wyeliminowac, mam tylko runtima dostarczanego mi
przez pewna firme)

Tez bylbym za tym gdyby mozna bylo skompilowac mdb, moze niekonieczne do
exe, ale jakos bardziej sensownie, tzn jak runtime to runtime - w jednym
katalogu i zadnego grzebania Access'em, no i zeby nie mialo wplywu czy jest
czy nie pelny Access

Pozdrawiam Robert
BAD

Witam,

Wg moich wiadomosci mozna skonstruowac baze Accessa ktora nie wymaga
Accessa - tylko jeden drobiazdzek. Trzeba miec Accessa DEVELOPER EDITION
(albo jakos podobnie sie to nazywa), i z niej jest mozliwe wygenerowanie
prawdziwego EXEC-a ktory ruszy bez zainstalowanego accessa na komputerze
klienta.
Zrodlo danych: VB for Access, autora nie pamietam. Byla do kupienia w
warszawskim MPiK-u.


PozdraWWWiam,
Grzegorz

>Witam,
>
>Wg moich wiadomosci mozna skonstruowac baze Accessa ktora nie wymaga
>Accessa - tylko jeden drobiazdzek. Trzeba miec Accessa DEVELOPER EDITION
>(albo jakos podobnie sie to nazywa), i z niej jest mozliwe wygenerowanie
>prawdziwego EXEC-a ktory ruszy bez zainstalowanego accessa na komputerze
>klienta.
>Zrodlo danych: VB for Access, autora nie pamietam. Byla do kupienia w
>warszawskim MPiK-u.
>
>
>PozdraWWWiam,
>Grzegorz
>
>

Co do Accessa zgadza sie (poczytaj moj mail nieco wyzej)
Ale exe'ca i tak nie dostaniesz, tylko pelnego Accessa z dwoma innymi
bibliotekami, ktore blokuja dostep do form itd.
Tak wiec nie jest to tak hop siup. Jedno jest pewne: mozna to
rozpowszechniac za darmo, lub pobierac oplaty za wlasna baze.(Tyle ze wersja
DEV troszke kosztuje)

--
BAD
Uwaga !
W naglowku adres ANTYSPAMOWY
Usun ANTISPAM lub pisz na: bad@et.put.poznan.pl
news.tpnet.pl napisał(a) w wiadomości: ...

news.tpnet.pl wrote:
> 
> Witam,
> 
> Wg moich wiadomosci mozna skonstruowac baze Accessa ktora nie wymaga
> Accessa - tylko jeden drobiazdzek. Trzeba miec Accessa DEVELOPER EDITION
> (albo jakos podobnie sie to nazywa),

To co napisales to prawie prawda. I juz chyba wszyscy zainteresowani
watkiem wiedza, ze aby utworzyc wersje instalacyjna aplikacji "accessa
bez accessa", nalezy posiadac pakiet o nazwie ADT (dla A'2.0 i A'95,
oczywiscie dla tych dwoch wersji sa to odrebne narzedzia) oraz ODE (dla
A'97). Rozszyfrowuje skroty: Access Developer's Toolkit oraz Office
Developer Edition.

Gdzie je dostac? (tu nawiazuje do pierwszego maila watku, bo jasna
odpowiedz chyba nie padla). Legalnie - u dystybutorow oprogramowania M$.
Nielegalnie - nie wiem ;-)

> i z niej jest mozliwe wygenerowanie
> prawdziwego EXEC-a ktory ruszy bez zainstalowanego accessa na komputerze
> klienta.
> Zrodlo danych: VB for Access, autora nie pamietam. Byla do kupienia w
> warszawskim MPiK-u.

Poczytaj troche postow wstecz, bo rece juz opadaja (dobrze, ze chociaz
na klawiature ;-). Dla Accessa "kompilatora do prawdziwego .exe" nigdy
nie bylo i IHMO, przy zalozonej przez M$ koncepcji plikow .mdb (.mde),
nigdy nie bedzie. To co umozliwiaja pakiety ADT i ODE, jest wykonaniem
instalacji runtime, czyli w uproszczeniu mowiac, uzytkownik dostaje w
zasadzie pelnego Accessa bez mozliwosci projektowania (ze to moze potem
na upartego obejsc to juz inna sprawa, ale przeciez od czego sa w
Accessie mechanizmy zabezpieczen obiektow, czy tez mozliwosc
wygenerowania plikow mde w A'97; albo oba sposoby lacznie).

Do moich argumentow przeciw mozliwosci tworzenia ".exe z .mdb" dorzuce
jeszcze jedna cegielke (oprocz slynnego: "jak mozna skompilowac tabele,
indeksy?" ;-). Otoz jak wiadomo, w plikach.mdb sa przechowywane
informacje o uprawnieniach do obiektow (tabel, formularzy, itp.).
Uprawnienia moga byc przeciez modyfikowane, zarowno "recznie" przez
uzytkownikow, jak i programowo w kodzie aplikacji. Przeciez po
hipotetycznym skompilowaniu, zawartosc pliku .exe modyfikowac byloby
raczej trudno.

Reasumujac:
 Nadal podtrzymuje swoja teze, ze w koncu dla przecietnego "koncowego
usera" jest w sumie bez znaczenia, czy wsrodku aplikacji siedzi
"prawdziwy .exe", czy runtime. A ze niektorym grupowiczom runtime sie
nie podoba - no trudno, jest jak jest, nie ma co gdybac. W koncu nie ja
projektowalem Accessa i format .mdb ;-). Ponadto - o czym juz tutaj
wielokrotnie pisano - nic nie stoi na przeszkodzie, zeby dane (tabele)
trzymac w plikach.mdb (jesli ktos ten format bardzo chce), a aplikacje
zawierajaca interfejs uzytkownika napisac w innym "kompilowalnym do exe"
narzedziu, np. Visual Basicu (aczkolwiek w przypadku VB, jego .exe tez
nie jest do konca takie prawdziwe).

> PozdraWWWiam,
> Grzegorz

PozdrawiaMail&News ;-) -
	Stanley

BAD wrote:
> 
> Witam !
> 
> Stanley P napisał(a) w wiadomości: <36498A91.38EA9A7@friko.onet.pl>...
> 
> [...] nie bede cytowal bo dlugi list napisales.

i dobrze, dzieki ;-)
 
> Moze dopowiem cos od siebie.
> Runtime w A97 wyglada w ten sposob, ze w wierszu polecenia podajesz komende
> /runtime (w skrocie)
> np.:
> "C:\Program Files\Microsoft Office\Office\MSACCESS.EXE"   /runtime
> "mojabaza.mde" /ini konfig.ini
> 
> Jak widzicie bezpieczenstwo jakby zmalalo ( moze sie myle? ).

troche nie rozumiem... Bezpieczenstwo plikow mdb (tudziez mde, choc jak
wiadomo nie mozna w nich modyfikowac formularzy, raportow i kodu) zalezy
od nadanych uprawnien do obiektow w tychze plikach. Jesli  przy
projektowaniu aplikacji nie wykorzystano accessowych mechanizmow
zabezpieczen, jasnym chyba jest, ze kazdy, nieco bardziej kumaty moze,
jak to juz kiedys okreslono - "rozebrac aplikacje na kawalki". Chocby po
"wylaczeniu" parametru runtime czy prostym przeniesieniu danego pliku
mdb na komputer, gdzie ma "pelnego" Accessa.

> Na dodatek instalacja runtime'a wyglada nieco dziwnie...
> 1. jak nie ma Accessa do katalogu okreslonego przez tworce bazy laduje sie
> prawdziwy runtime ( tzn zwykly Access, ale jakies 2 biblioteki sa inne i nie
> da rady go uruchomic jako Access)
> 2. gdy jest juz Access, instalator odnajduje go i dopisuje sie do
> istniejacego pliku. ( tak tez to zrobil w zamieszczonym przezemnie
> przykladzie <jak widac chyba>)
> 
> Bardzo ciekawe efekty sa gdy instalujemy pelnego A97 na zainstalowanego
<...>
> ( UWAGA ! nie uzywalem nigdy programu do tworzenia instalek, tak wiec > byc moze czesc tych wad mozna wyeliminowac, mam tylko runtima > > dostarczanego mi przez pewna firme)
> 
> Tez bylbym za tym gdyby mozna bylo skompilowac mdb, moze niekonieczne > do exe, ale jakos bardziej sensownie, tzn jak runtime to runtime - w > > jednym katalogu i zadnego grzebania Access'em,

Poniewaz nie mam jeszcze zadnych doswiadczen z ODE, opisze ogolnie jak
sie ma rzecz w przypadku instalek wykonywanych za pomoca ADT2.0. Tam
instalacja aplikacji u uzytkownika wyglada wlasnie jak Ci sie "marzy",
czyli nie ma wplywu czy Access2.0 jest juz zainstalowany na stanowisku,
czy nie. No moze nie calkiem - jesli A2.0 (czy inna acessowa aplikacja
runtime) juz jest, nie sa powtornie kopiowane rozne pliki i biblioteki,
ktore znajduja sie w katalogu Windows\System. Trzeba bowiem pamietac, ze
Access to nie tylko plik msaccess.exe, ale caly zespol bibliotek
odpowiadajacych np. za silnik bazodanowy Jet. Biblioteki te moga byc
wykorzystywane nie tylko przez Accessa, ale i inne programy.

Kazda instalowana aplikacja runtime tworzy na dysku swoj katalog
(okreslany domyslnie w kreatorze instalek ADT) , np. C:\Mojapl. Do
takiego katalogu "wrzucany" jest przede wszystkim "wlasciwy" plik(i).mdb
oraz msarn200.exe (oraz jeszcze pare innych "towarzyszacych"). Ten
msarn200.exe jest wlasciwie tym samym co msaccess.exe, z wylaczona
mozliwoscia projektowania (np. F11 nie dziala), jako ciekawostka, jest
on tylko o pare KB mniejszy od msaccess.exe.
 
Jest pewna niedogodnosc czy raczej wlasciwosc takich instalek. Wyobrazmy
sobie, ze na danym stanowisku juz jest zaintalowana jakas aplikacja
runtime (czyli msarn200.exe itd.). Dostarczamy na te stanowisko jakas
kolejna, inna  aplikacje. W tym momencie do jej katalogu jest znow
kopiowany msarn200 (ok 2MB), mimo ze na dysku (tylko ze w innym
katalogu) wlasciwie juz jest zainstalowany caly "kombajn", potrzebny do
uruchomienia zwylke stosunkowo niewielkiego pliku.mdb. I w tym
kontekscie zgodze sie z wyrazonym przez kogos "ogonem w postaci
msarn...exe". No ale z drugiej strony, czym sa te przecietnie ok. 3MB
zajete na dysku przez kolejne aplikacje runtime (msarn200 itd.), przy
obecnych pojemnosciach HD... ;-)

> no i zeby nie mialo wplywu czy jest
> czy nie pelny Access

Z tego co opisales, zrozumialem (takze nie wykonywalem jeszcze zadnej
instalki za pomoca ODE), ze generalnie jesli na stanowisku jest juz
zainstalowany Access'97, to runtime w pelni go wykorzystuje, tworzac
tylko odpowiedni wiersz polecen dla uruchomienia pliku.mdb. Jesli tak
jest, uwazam to raczej za zalete - nie jest "marnotrawione" miejsce na
dysku  (ciekawe jak jest w przypadku braku obecnosci "pelnego" Accessa,
ale w sytuacji pisanej przeze mnie wyzej w ADT2.0 - instalacji kolejnych
aplikacji runtime na tym samym stanowisku).

Pozdrawiam -
	Stanley

                              Czesc!
-----
1. Tlumaczenie - sie
2. Ponowna próba sformulowania problemu
3. Podziekowania
-----

ad.1

Kiedy parę lat temu w bieszczdzkim schonisku w Wetlinie popeniłem jakis blad
facet, który razem z matka prowadził ten turystyczny interes powiedział mi:
         Niedzwiedziu! Popraw się!
On byl mlodszy niz ja.  A ja nie przypominalem niedzwiedzia (wtedy bylem
chudy - niedzwiedzie sa chyba grube?).

Podobne uczucie wstydu ogarnelo mnie po otrzymaniu odpowiedzi Stanleya.
Stanley wybacz te wszystkie niescislosci z poprzedniego tekstu oraz te,
które nastapia po nim.

Nie o A95 lecz o A97 chodzilo.
"Kompilator" to haslo, które wypisalem bezmyslnie powtarzajac to co mówili
znajomi.

Na komputerze, gdzie mialem zainstalowac pojedynczy plik mdb zawierajacy i
tabele i oprogramowanie byl juz wczesniej zainstalowany program, który jak
sadze po wysluchaniu dyskusji był runtimem.  Natrafilem na dysku na  plik o
nazwie msarn200.exe lub podobnej.  Wtedy nie wiedzialem jeszcze, ze nalezy
zwrócic na niego uwage.  Poniewaz program byl wazny obawialem sie, ze
instalujac A97 moge w jakis sposób go uszkodzic.  Byc moze obawy byly plonne
i na pewno wynikaly z braku podstawowej wiedzy w tym zakresie.  Co wiecej
zniecierpliwiony i tak podjalem próbe instalacji.


-----

ad. 2

Podjalem próbe ponownego (?) zainstalowania ACC.  Nie bylo to pierwsze
podejscie. Zauwazylem, ze przez ten komputer przewinelo sie wiele róznych
programów.
Mój plik mdb dawal sie otworzyc lecz powstawal problem, o którym nizej.

Dalszy opis nie bedzie grzeszyl scisloscia.  W czasie prób nie wiedzialem
jeszcze, ze rozpoczne poszukiwanie rozwiazania w ramach listy dyskusyjnej
gdzie
precyzja opisu może odegrac podstawowa role.

Na stanowisku zainstalowany byl pakiet oprogramowania Lotus.  Instalacja Acc
przebiegala pomyslnie gdy kopiowane były pliki na dysk twardy.  Niestety
pojawilo sie okno dialogowe, z którego wynikalo, ze plik - tu padla nazwa -
nie może zostac zaladowany ( a może zainstalowany ...)  Chodzilo o jakas
biblioteke (chyba plik dll).  Rzecz jasna nie spisałem nazwy pliku.  Czy to
mozliwe aby Instalacja Lotusa gryzla sie z Microsoftowa?

Caly ten balagan z instalacja spowodowany byl brakiem obsługi funkcji
data() uruchamianej na dzien dobry za pomoca jakiejs procedury, która
sprzeglem z
makrem autoexec.

Moze wlasnie od pytania o date powinienem rozpoczac dyskusje a nie od
runtima :-( ?

-----

Podziekowania:

     Chociaz nie calkiem trafilem z formulowaniem tematu usłyszalem kilka
ciekawych głosów.  Za wszystkie odpowiedzi pragne niniejszym goraco
podziekowac.


                                                                      Tadek

On Sat, 14 Nov 1998, Stanley P wrote:

> wielokrotnie pisano - nic nie stoi na przeszkodzie, zeby dane (tabele)
> trzymac w plikach.mdb (jesli ktos ten format bardzo chce), a aplikacje
> zawierajaca interfejs uzytkownika napisac w innym "kompilowalnym do exe"
> narzedziu, np. Visual Basicu (aczkolwiek w przypadku VB, jego .exe tez
> nie jest do konca takie prawdziwe).
> 
   Zadam takie pytanie, zeby byc pewnym na 100% w tej kwestii. Czy tworzac
aplikacje w VB lub Delphi (w postaci exe) korzystajaca z plikow *.mdb nic
wiecej nie bedzie mi potrzeba? Czyli przenosze execa i *.mdb na inny
komputer (gdzie nie ma Accessa) i wszystko dziala?
   Pozdrawiam.
   I. Stolowski

>   Zadam takie pytanie, zeby byc pewnym na 100% w tej kwestii. Czy tworzac
>aplikacje w VB lub Delphi (w postaci exe) korzystajaca z plikow *.mdb nic
>wiecej nie bedzie mi potrzeba? Czyli przenosze execa i *.mdb na inny
>komputer (gdzie nie ma Accessa) i wszystko dziala?
>   Pozdrawiam.
>   I. Stolowski


Nie wiem jak jest dokladnie w VB, ale na pewno potrzebne sa jeszcze wlasciwe
biblioteki vbrunxxx.dll .
Natomiast do Delphi jestem pewien a mianowiecie potrzebne sa:
- instalacja BDE (Borland Database Engine)
- zainstalowany wlasciwy driver ODBC (dopiero od Delphi 3 mozna dostac sie
do baz Accesa bez udzalu ODBC)
- w przyadku korzystania z ODBC powinny byc równiez dostepne biblioteki
enginu MSJet (czy jakosc tak sie to nazywa)

--
Janusz Dziadon
j.dziadon@bph.krakow.pl

On Wed, 18 Nov 1998, Janusz Dziadoń wrote:

> >   Zadam takie pytanie, zeby byc pewnym na 100% w tej kwestii. Czy tworzac
> >aplikacje w VB lub Delphi (w postaci exe) korzystajaca z plikow *.mdb nic
> >wiecej nie bedzie mi potrzeba? Czyli przenosze execa i *.mdb na inny
> >komputer (gdzie nie ma Accessa) i wszystko dziala?
> 
> Nie wiem jak jest dokladnie w VB, ale na pewno potrzebne sa jeszcze wlasciwe
> biblioteki vbrunxxx.dll .
> Natomiast do Delphi jestem pewien a mianowiecie potrzebne sa:
> - instalacja BDE (Borland Database Engine)
> - zainstalowany wlasciwy driver ODBC (dopiero od Delphi 3 mozna dostac sie
> do baz Accesa bez udzalu ODBC)
> - w przyadku korzystania z ODBC powinny byc równiez dostepne biblioteki
> enginu MSJet (czy jakosc tak sie to nazywa)
> 
   OK. Idac dalej, wyjasnie o co mi chodzilo w pytaniu. Zalozmy, ze ma byc
stworzona aplikacja bazodanowa dla klienta, pracujaca docelowo w sieci,
korzystajaca z *.mdb. Wyszly 3 mozliwosci:
  1. Access
  2. Delphi
  3. VB
W 1 mozliwosci klient musi zakupic Accessa (w tej chwili nie posiada) lub 
tez byla mowa o run-timie (podobno cena zblizona do ceny Accessa). W 3
potrzebna jest biblioteka vbrunxxx.dll (a wiec ogolnodostepna). Czy exec,
ta biblioteka i *.mdb wystarcza, by przeniesione na komputer klienta to
zadzialalo, czy potrzeba cos jeszcze?
Natomiast co do Delphi, to mam rozumiec, ze BDE, ewentualnie takze ODBC
oraz MSJet musza byc zainstalowane na stanowisku klienta, by program mogl
tam u niego zadzialac? Oraz, ze skladniki te naleza standardowo do pakietu
Delphi. A jesli tak, to co z prawami autorskimi? Majac zakupiony pakiet
Delphi moge te skladniki zainstalowac razem ze swoim napisanym programem u
klienta?? I ani w 2 i 3 przypadku nie sa tam potrzebne jakies biblioteki 
Accessa, by to chodzilo?
  Tyle watpliwosci. 
  I. Stolowski

Ireneusz Stolowski napisał(a) w wiadomości: ...
>On Sat, 14 Nov 1998, Stanley P wrote:
>
>> wielokrotnie pisano - nic nie stoi na przeszkodzie, zeby dane (tabele)
>> trzymac w plikach.mdb (jesli ktos ten format bardzo chce), a aplikacje
>> zawierajaca interfejs uzytkownika napisac w innym "kompilowalnym do exe"
>> narzedziu, np. Visual Basicu (aczkolwiek w przypadku VB, jego .exe tez
>> nie jest do konca takie prawdziwe).
>>
>   Zadam takie pytanie, zeby byc pewnym na 100% w tej kwestii. Czy tworzac
>aplikacje w VB lub Delphi (w postaci exe) korzystajaca z plikow *.mdb nic
>wiecej nie bedzie mi potrzeba? Czyli przenosze execa i *.mdb na inny
>komputer (gdzie nie ma Accessa) i wszystko dziala?
>   Pozdrawiam.
>   I. Stolowski

Bedzie dzialalo o ile zainstalujesz odpowiednie sterowniki do bazy danych
np. ODBC, dla bazy MS Access ODBC mozna dolaczac do programow nieodplatnie.
Delphi przynajmniej 1.0 wymaga instalacji obslugi IDAPI. (Tez darmowy)

------------------------------------------------------------------
Mariusz Walaszek
Zaklad Oprogramowania Komputerowego "PROGMAR"
e-mail: progmar@silesia.top.pl
ICQ:4470610
____/|
\ o.O|
=(_)=
    U

Ireneusz Stolowski wrote:
> 
> On Wed, 18 Nov 1998, Janusz Dziadoń wrote:
> 
> > >   Zadam takie pytanie, zeby byc pewnym na 100% w tej kwestii. Czy tworzac
> > >aplikacje w VB lub Delphi (w postaci exe) korzystajaca z plikow *.mdb nic
> > >wiecej nie bedzie mi potrzeba? 
<...>

>    OK. Idac dalej, wyjasnie o co mi chodzilo w pytaniu. Zalozmy, ze ma byc
> stworzona aplikacja bazodanowa dla klienta, pracujaca docelowo w sieci,
> korzystajaca z *.mdb. Wyszly 3 mozliwosci:
>   1. Access
>   2. Delphi
>   3. VB
> W 1 mozliwosci klient musi zakupic Accessa (w tej chwili nie posiada) lub
> tez byla mowa o run-timie (podobno cena zblizona do ceny Accessa). W 3
> potrzebna jest biblioteka vbrunxxx.dll (a wiec ogolnodostepna).
> Czy exec,
> ta biblioteka i *.mdb wystarcza, by przeniesione na komputer klienta to
> zadzialalo, czy potrzeba cos jeszcze?

Co prawda nie koduje w VB, ale jestam niemal na 100% przekonany, ze sam
vbrun nie wystarczy, musi takze byc zainstalowany MS Jet (czyli
odpowiedni zespol bibliotek), jesli program obsluguje bazy.mdb.

> Natomiast co do Delphi, to mam rozumiec, ze BDE, ewentualnie takze ODBC
> oraz MSJet musza byc zainstalowane na stanowisku klienta, by program <...>
> klienta?? I ani w 2 i 3 przypadku nie sa tam potrzebne jakies biblioteki
> Accessa, by to chodzilo?

Sadze, ze bardziej wyczerpujace odpowiedzi na temat wspolpracy VB czy
Delphi z bazami danych uzyskasz (byc moze ;-) na odpowiednich grupach,
poswieconych tym narzedziom.

Skoro jednak mowa o Accessie ( w koncu pisze na grupe msaccess ;-).
Tworzac w innym narzedziu aplikacje "wspolpracujaca" z danymi w
przechowywanymi w plikach.mdb nalezy wziasc pod uwage "utrate" pewnych
mozliwosci, ktore standardowo dostarcza Access. 
Mam tu na mysli np. nadawanie uprawnien do obiektow "interfejsu
uzytkownika" (formularzy/raportow), tzn. ze w danej aplikacji user
Kowalski moze otwierac np. Formularz1 a nie moze Formularza2, a user
Xsinski na odwrot. Oczywiscie zapewne podobny mechanizm mozna sobie
samemu oprogramowac w VB czy Delphim, ale zapewne bedzie wymagalo to
duuuuzo dodatkowych linii kodu.
Druga sprawa bardziej techniczna i mniej istotna. O ile mi wiadomo VB
nie ma takiego - wygodnego uwazam - elementu, jakim jest podformularz.
Tutaj jestem pewien w VB3.0, byc moze wyzsze wersje juz maja takie
"cus".

I jeszcze raz, na wszelki wypadek ;-) podkreslam: nie zamierzam
udowadniac wyzszosci run-time nad "skompilowanym" .exe. Nalezy sie
spodziewac, ze aplikacja napisana np. w Delphim bedzie szybsza
(przynajmniej w otwieraniu okienek, bo w samym przetwarzaniu danych
niekoniecznie), mniej obciazy zasoby, byc moze zajmie mniej miejsca na
HD itp. Jednak uwazam, ze accessowa aplikacja run-time ma takze swoje
zalety, ktore wymienilem ktoryms mailu, nie bede sie powtarzal. Zreszta
obecnie, w dobie PII-ilestamMhz, RAMu ilestam-setMB, dyskow iles-tam GB,
problem "mułowatosci" takich aplikacji praktycznie znika. Proponuje na
takim sprzecie sprawdzic Accessa2.0 - chodzi prawie jak assembler ;-)

Pozdrawiam -
	Stanley