Newsgroup: it.comp.appl.access
Titolo: Cosa NON si puo' fare in  Access ???

Da poco mi sono avvicinato al sistema Access che avevo sempre sottovalutato, 
sto usando la versione 2003 in accoppiata con Firebird via odbc
Lo trovo un ambiente davvero semplice ed al tempo stesso notevolmente 
potente
Vorrei chiedere a chi di voi lo usa ed usa anche degli ambienti di 
programmazione classici tipo Visual Studio o Delphi:  quand'e' che Access 
mostra i suoi limiti?
O meglio, cosa non si riesce a fare con Access e bisogna ricorrere ai 
classici linguaggi di programmazione?
Magari circoscrivendo il discorso a sistemi di tipo gestionale, capisco 
benissimo che per fare un driver di stampante ci voglia altro, ma mi sembra 
che usando il vba Access riesca ad arrivare molto vicino ai classici 
linguaggi tipo Visual Basic, C#, Delphi
Insomma, non riesco ancora ad apprezzare esattamente i limiti del sistema 
rispetto ai linguaggi sopra descritti
Parlo di Access come font-end, come db si intende sempre un classico db 
server tipo sql-server, oracle, firebird, postresql, ecc
Ciao e grazie
RobertoA

 ha scritto nel messaggio 
news:45f8...@newsgate.x-privat.org...

Access è insuperabile per la gestione dei front-end dei database...in 
assoluto il top, il migliore.
Come hai detto, in accoppiata con tabelle sqlserver o simili, è il massimo.
Il paragone con VS o Dph con regge perchè sono prodotti diversi. Realizzare 
un database con Access è praticamente un gioco rispetto a crearlo con i due 
applicativi citati.
Cosa diversa è se vuoi creare un database per il web: qui Access è molto 
carente e mi riferisco all'interfaccia.
Ciao, Carlo 

 ha scritto nel messaggio news:45f8...@newsgate.x-privat.org...

Se ci fosse un compilatore (Ecco fatto! L'ho detto!) per access, il cerchio si sarebbe chiuso...
Ciao.
-- 
Sergio MAZZA

 Se ci fosse un compilatore (Ecco fatto! L'ho detto!) per access, il
cerchio si sarebbe chiuso...
Sergio, il "compilatore" per Access (ammesso che fosse realizzabile, e non
lo è) non servirebbe assolutamente a nulla.
Basta e avanza la possibilità di distribuire applicazioni Runtime .MDE/ADE
in esenzione da royaltees.
Soluzione d'altra parte utilizzata da i tanti DB-RAD sul mercato.
Ciao.


Concordo.
un limite di access è sicuramente che no si può fare la doccia, per il 
resto, parlando di gestionali non credo ce ne siano  di limiti. Magari c'è 
qualche limite a delle tecniche in particolare, ma si possono ottenere le 
stesse cose con cose diverse. Es. Tu fai una subquery, questo rende la query 
di sola lettura, ma se invece della subquery fai una funzione ottieni la 
possibilità di scrivere
-- 
-- 
Massimiliano Amendola
www.accessgroup.it
Cisa - Conferenza Italiana Sviluppatori Access

 Ciao.
Ciao.
P.S. Ovviamente concordo con te, non avendone mai sentita la necessità; ed 
era una provocazione...
-- 
Sergio MAZZA 

 ha scritto nel messaggio 
news:45f8...@newsgate.x-privat.org...

Io penso che uno dei difetti maggiori di Access sia la reportistica. Se 
devi fare report semplici hai tutti gli strumenti a tua disposizione, ma 
appena la cosa si complica un pochino (ad esempio più dati provenienti 
da diverse query/tabelle in un unico foglio per risparmio di spazio e 
per impatto di sintesi) ci sono dei limiti quasi insuperabili.
Un altro difetto (ma chiaramente è un falso difetto) è che permette 
anche agli gnurant :-))) di avvicinarsi ai db e alla progettazione di 
interfacce (troppo RRRRRAD) e spesso ne escono macelli inenarrabili ai 
quali magari devi mettere una pezza tu che sei un pochino più esperto 
:-)
Un mio amico guardando un foglio elettronico - "Ma come hanno assunto 
gli impiegati in questa azienda?"
Io - "Hanno fatto uno scrupoloso test di ingresso in Excel, e poi hanno 
assunto tutti quelli che non l'hanno superato!"
Bye
Il Bove 

 Questa risponde pienamente al quesito di RobertoA.
Non intendevo come 'chiusura eseguibile' ma come funzionalita' disponibili 
che magari coi classici linguaggi di programmazione permette di fare cose 
non possibili dall'interno dell'ambiente Access
Pero' ho visto che, comunicare con le seriali ci si riesce, utilizzare ocx e 
dll ci si riesce, e quindi derogando il 'lavoro sporco' a librerie esterne 
credo che la differenza tra Access ed i classici linguaggi di programmazione 
(per classici intendo Visual Basic, Dot Net, Delphi,...) sia davvero ridotta 
esclusivamente alle prestazioni / risorse impiegate
Ed essendo attualmente la media delle macchine ben dotata di cpu e ram, 
credo che la differenza maggiore sia da cercare nelle doti velocistiche del 
risultato finale, nel senso tempo apertura applicativo, velocita esecuzione 
cicli particolarmente impegnativi, ecc...
Voi che siete piu' esperti, ditemi se sbaglio
Ciao
RobertoA 

 assunto tutti quelli che non l'hanno superato!"
E quando non riesci coi report di Access cosa usi ?
Ciao
RobertoA

 per impatto di sintesi) ci sono dei limiti quasi insuperabili.
"Il bove", se conosci artigianalmente Access evita di postare in Thread di
questo genere: crei confusione.
Il Report Engine di Access è uno dei punti di forza del prodotto: in tanti
anni di utilizzo non ho mai incontrato Reports irrealizzabili o
problematici, a qualunque livello di complessità.
A meno di prendere in considerazioni misure del foglio da Plotter:  ma qui
si andrebbe OT...
Naturalmente in un'area pubblica ognuno può dire la sua: ma sono certo che
gli MVP del ng. confermeranno quanto scrivo.

 per impatto di sintesi) ci sono dei limiti quasi insuperabili.
Ed io che pensavo, invece, che la reportistica di access fosse tra le 
cose migliori. Il mondo e' bello perche' e' vario?! ;<)
Al momento non ho avuto alcun problema, anche con i report piu' 
complicati. Male che vada, ma deve andare proprio male, male, male, si 
possono sempre costruire via VBA.  Certo c'e' il problemino che se 
voglio stampare un migliaio di pagine con altrettante immagini "gna fa" 
ma posso sempre stampare mille report con una immagine. Sta storia "de 
maometto e le montagne" torna sempre comoda.
-- 
ac
y-1=x

"RobertoA"

Anzitutto, come ti scrive Carlo Access è un generatore di applicazioni
DeskTop: non ha di fatto caratteristiche web (lascia perdere le DAP,
peraltro non più supportate da A '2007).
In secondo luogo non è un generatore di codice, come Delphi, ma un classico
DB-RAD ... per quanto molto potente nel linguaggio (che non è un sistema di
scripting come in altri prodotti simili).
Di conseguenza su vari aspetti non hai possibilità di controllo totale, a
meno di sfruttare molto pesantemente l'API del sistema operativo (cosa che
Lebans, 
www.lebans.com
,  ama fare).
Per esempio non puoi personalizzare una ComboBox per colorare
differentemente le colonne.
O inserirvi immagini.
O personalizzare l'iconcina dei selettori records nelle Forms.
Va detto che ci sono ActiveX che fanno queste cose, ma molti preferiscono
far finta che non esistano: quindi accantoniamo il discorso.
Ma in genere il controllo grafico "totale" dell'applicazione non è
fondamentale: in tal caso Access è un generatore di applicazioni Desk privo
di
limitazioni, o quasi (compresa la Reportistica, al di là del post "del
Bove").
Connettività Client-Server di Access via ODBC: il connubbio con il Server
SQL di Microsoft è ovviamente ottimo.
E' piuttosto gettonato anche MySQL come BE per Access e non mancano
testimonianze di chi s'è interfacciato con soddisfazione a Oracle o altri
Server: in questo caso scrivo cmq solo per sentito dire.
Concludendo: a mio avviso Access era di gran lunga il miglior ambiente di
sviluppo per DB fino all'inizio del nuovo millenio, nonostante gli sterili
flames "Access vs Visual Basic" e simili.
Ora, con l'avanzata di .NET e delle tecnologie web, non saprei che dire:
forse sarebbe meglio puntare su 
ASP.NET
 in toto.
Ma sono discorsi evidentemente controversi e non del tutto chiari.
Ciao.

 un limite di access è sicuramente che no si può fare la doccia, 
ma ci hai mai provato? Ho ancora qualche problemino con i timer ma la 
doccia mi parte e suona una musichetta quando la temperatura e' quella 
ottimale. Devo ancora fare in modo che il letto si ribalti e mi ci 
scarichi direttamente dentro. Finita la doccia l'asciugacapelli (per 
quei pochi che mi sono rimasti), anche quello con partenza automatica, 
fa anche lui il suo "porco" lavoro.
Tu pensa al/ai magazzini sta storia della doccia non fa per te ;<)
-- 
ac
y-1=x

Roberto, Carlo, Sergio & C.
-----------------------------
Finalmente qualcosa che non sia la banale risposta al
Cretinetti di turno che chiede come colorare di rosso
un campo con valore negativo ovvero come far
sparire un menu dalla barra strumenti, al solo scopo
di "stupire" - pensa lui - il povero utente!
Vi leggo con molto interesse.
Bruno


Sarà che non le uso molto...


 ma ci hai mai provato? Ho ancora qualche problemino con i timer ma la
E' lě il discorso!
Ogni scusa č buona per non lavarsi...
Antonio


Guarda che solo gli sporcaccioni si lavano. MA ed io siamo angeli non 
abbiamo bisogno di queste cose da umani.
Lo dovrest sapere. Tu che hai visto tutte quelle cose fra Alnilam, 
Alnitak e Mintaka.
-- 
ac
y-1=x

 impatto di sintesi) ci sono dei limiti quasi insuperabili.
Mi sa che "Il Bove" conosce poco i report di Access...non ha idea di cosa 
significa fare un report con Crystal Report...
Ciao, Carlo 


Questa domanda fatta in un NG di access rischia di essere di parte....
qualche volta mi piacerebbe leggerla in un NG di C++... ;-)
Beh ti hanno già spiegato che Access è un'applicazione Desk quindi
nella comparazione ad altre applicazioni equivalenti potrebbe avere
solo i limiti dovuti al Linguaggio di sviluppo.
Ti hanno già esposto pareri relativi alla struttura, io mi limito ad
esporti limiti di programmabilità e programmazione.
Mentre i linguaggi da te citati possono fare sia applicativi Desk che
librerie, come Dll COM o Activex, o dll standard(ma questo nemmeno VB6
può), ovviamente Access non può farlo, la possibilità di fare MDE da
usare come Librerie è una voglia più che altro... ma nulla di
realmente paragonabile.
Sei pertanto costretto, se servono, a realizzarti DLL esterne o OCX in
linguaggi diversi, e sperare di aver generato un componente
compatibile.
OCX e/o DLL non sempre risultano pienamente compatibili, in
particolare gli Eventi delle Dll istanziate con WithEvents possono
evidenziare brutte sorprese...., oppure relativamente ad OCX eventi
visibili in C++ o in VB6 non sono esposti in Access.
Con access non puoi istanziare Ocx senza averli piazzati nella
maschera, in particolare nel caso dell'utilizzo di Winsoc.OCX potrebbe
essere un problema, in quanto andrebbe realizzata una maschera(come
classe) da usare in MultiIstanza, ma personalmente non lo farei
mai....
Con Access e con VB6 l'ereditarietà ed il polimorfismo sono il punto
debole della programmazione e della programmabilità, l'ereditarietà si
ferma al 2° livello, in pratica non esiste una vera ereditarietà.
Access ha limiti evidenti sulla gestione degli Oggetti, in particolare
degli Handle(questo per la struttura di progetto iniziale per la quale
un controllo riceve l'handle solo quando è attivo)...!
Non può gestire assolutamente ContextDevice (Hdc per i non addetti ai
lavori)... su nessun Oggetto, e per la grafica è una limitazione
importante.... è pur vero che per la grafica, intendo elaborazione
grafica, solo un pazzo si metterebbe a farlo con Access....
Detto questo, ma sicuramente si potrebbe aggiungere altro,
l'importante è comprendere i Limiti, e definire le esigenze, poi se
uno sviluppatore ha basi solide in altri linguaggi sicuramente trova
in Access uno strumento potente e veloce per la realizzazione di
applicativi anche Importanti di Gestione.
Mi pare ovvio che applicazioni RealTime non siano alla sua
portata.....
Saluti
@Alex

 RobertoA
Ciao.
-- 
Sergio MAZZA 

 problematici, a qualunque livello di complessità.
Sottoscrivo pienamente.
Ciao.
-- 
Sergio MAZZA 

 non ha idea di cosa significa fare un report con Crystal Report...
ahhhhhhhhhhhh......
che dolore quel nome... non pronunciatelo che ci sto bestemmiando da qualche mese...
comunque sottoscrivo.
in access non ho ancora trovato report che non si possa fare, inoltre, l'80 % dei report li crei molto velocemente con wizard e/o piccoli/medi adattamenti
del restante 20% direi che solo un 2-3% richiede normalmente complessità descritte da alessandro per cui necessiti di usare VBA, il resto con una _BUONA_conoscenza dello strumento si fa in modo discretamente semplice
inoltre, come velocità di creazione è appunto molto molto veloce.
Ciao,
Max

 ha scritto nel messaggio 
news:etbaqi$284$1...@tdi.cu.mi.it...

Confermo...
Morgan 


Cosa non approvi in Crystal Report ?
Ciao
RobertoA

 Soluzione d'altra parte utilizzata da i tanti DB-RAD sul mercato.
quali altri concorrenti essito ad Access ?
Io cono Lotus Aprocc ma è obbiettivamente inferiore al nostro Access.
FileMaker ?
Anche quello di OpenOffice è inferiore...
Qualche parere ?

Qualche parere ?
No, non mi riferivo ai prodotti che hai citato (assai limitati a livello di
linguaggio).
Pensavo a DB-RAD come Omnis Studio, Visual Fox-Pro, Power-Builder...
Saluti.

 possibilità di scrivere
e questa chicca da dove l'hai tirata fuori???


tempera e pennello ...
i report di access sono la sua forza. Per quanto riguarda il problema di cui
parli, l'accesso a più dati e più tabelle, è tranquillamente bypassabile
facendo porting su sistemi di database di tipo server. Non c'entra nulla la
reportistica.

 RobertoA
una cosa di sicuro non si può fare con access:
I   S O L D I   !!!!
luigi
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 luigi
Ciao.
-- 
Sergio MAZZA 

 ha scritto nel messaggio 
news:45f98856$0$4789$4faf...@reader4.news.tin.it...

Mi appendo qua, perché non so dove farlo, troppo tentacolare il thread 
:-)
Cmq la mia non voleva essere una critica spietata, anzi. E molto 
probabilmente la colpa č mia che non lo so usare bene, dicevo solo la 
mia.
A proposito di report, vi cito uno dei problemi che ho avuto e che non 
ho mai risolto.
Una volta mi chiesero di fare una specie di programma di fatturazione, 
per ogni movimento di cassa (chiamiamolo cosě) potevano venire generate 
da 1 a 3 "ricevute" a seconda della tipologia di movimento.
Si voleva che il report fosse una pagina di A4 diviso in 3 parti (con un 
bel tratteggio :-D), la prima parte doveva essera la 1° ricevuta (che 
c'era sempre), le altre 2 parti dovevano contenere le altre due ricevute 
se erano presenti o essere vuote.
Io ci sono un po' impazzito, ma dai messaggi che vedo, probabilmente si 
poteva fare ;-)
Bye
Il Bove 

 Il Bove
Sicuro che si poteva fare!
Comunque mi sembra un po' avventato giudicare i report di Access basandosi 
solo sulla propria inesperienza...
potevi chiedere qui e, sono sicuro, avresti risolto in un solo post.
Ciao, Carlo

 RobertoA
Ciao,
Max

 poteva fare ;-)
L'unica cosa che non sono riuscito a fare in Access riguarda anche
per me il report per una fattura.
Avrei voluto inserire in ognuna delle tre (esemplificando) pagine
la numerazione 1/3, 2/3, 3/3, ma non sono riuscito a conoscere
il numero complessivo delle pagine prima della stampa.
Se non contando le righe del testo cosa che, nella fattispecie,
non aveva senso avendo dei campi con proprietà CanGrow
che potevano confondere le idee...
Parlo di tempi in cui Internet non si sapeva nemmeno cosa fosse.
Poi ho provveduto diversamente e non ci ho più pensato.
Qualcuno ha risolto tale problema?
Bruno 

 Bruno
Non so se puo' esserti di aiuto..
http://www.accessgroup.it/HomeArgomenti.asp?ID=130&Oggetto2=Reimpostare%20il%20nr.%20pagina%20in%20un%20nuovo%20Gruppo
--
sv


 luigi


 Il Bove
A mio caro Pio,
se questo per te è un problema allora capisco la tua affermazione.
Credimi si può in mille modi diversi (uno è quello sul sitocomune, un'altro 
è mettere il report come sottoreport di report che ha come origine una 
tabella temporanea con n record a seconda di quanti te ne servono.. e potrei 
continuare).


 
http://www.accessgroup.it/HomeArgomenti.asp?ID=130&Oggetto2=Reimpostare%20il%20nr.%20pagina%20in%20un%20nuovo%20Gruppo
Ok, grazie della segnalazione.
Ho scaricato il file ma non ancora fatto prove.
Ti terrò informato.
Bruno