Newsgroup: it.comp.appl.access
Titolo: Access con Jet oppure Access con SQL server 2500 express

La domanda è molto semplice e diretta (non credo che la risposta lo
sia altrettanto!) "Riuscirò" con Access a realizzare un'applicazione
per gestire le commesse  di una società di servizi (dalle offerte al
cliente fino alla fatturazione) che dovrebbe essere utilizzata da una
dozzina di utenti, ma con accessi contemporanei di non più di 6-7 (al
massimo tutti i 12 utenti potrebbero avere aperta l'applicazione senza
fare nulla, come di solito capita con tutte le applicazioni gestionali
che rimangono aperte e inattive).
Le  tabelle principali con la relativa numerosità di record e
l'ipotesi di media di creazione di nuovi record per giorno lavorativo
sono le seguenti: 
				N.rec.	Trans./g
Offerte preventivi		300	1,4
Commesse			150	0,7
Attività per commessa(10x150)	1500	6,8
Ordini Fornitori			700	3,2
Fatture Fornitori			500	2,3
Fatture Clienti			400	1,8
Righe per fattura(400x5)	2.000	9,1
Note spesa			200	0,9
Timesheet(15x52)		780	3,5
Anagrafica Clienti		50	rara
Anagrafica Fornitori		600	rara
oppure devo utilizzare necessariamente Access come front-end e SQL
Express come motore DB?
Il termine "Riuscirò" è relativo evidentemente al livello di
prestazioni e di sicurezza dei dati (non nel senso di tener lontano i
curiosi - problema non molto critico nell realtà in oggetto - ma di
salvaguardare l'integrità referenziale del database!) tenendo conto di
utilizzare il back- end jet su un server collegato ad una rete
ethernet in classe 6 (gigabit) e client sufficiente mente moderni e
performanti.
Ciò che ho letto su questo NG, sui siti collegati ed amici
programmatori (con la P maiuscola, non i dilettanti come me!) mi ha
solo messo una gran paura sull'utilizzo in multiutenza di access:
secondo alcuni oltre i tre-cinque utenti è meglio lasciare perdere e
passare, quantomeno  a SQL server come Back-end.
Grazie per i vostri commenti

E' noto che JET in rete possa dare qualche problema di corruzione, ma
a questo potresti ovviare con tecnologia T.S.(Terminal Service).
In ogni caso se quanto dici è un progetto già a analizzato nei
dettagli
io personalmente preferirei orientarmi su SQL-Server anche se
un'applicazione
JET ben sviluppata è tranquillamente in grado di supportare una decina
di utenti
contemporanei senza particolari problemi.
Per gli utenti che aprono l'applicazione senza fare nulla ci sono
metodi per
evitare queste cose(un LogOff dopo tempo di inattività), infondo anche
un ERP come SAP R/3 lo usa.....!
@Alex

 Express come motore DB?
Anch'io ti consiglio di puntare su SQL Server Express, ma non tanto per un
fatto d'affidabilità (come diceva Alex, si possono usare in T.S.) quanto di
volume dati indirizzabile.
2 GB potrebbero essere pochini in prospettiva pluriennale.
Comunque, piuttosto che gli ADP, ti consiglio di provare bene
l'interfacciamento ODBC tra Access e SQL Server.
O comunque di confrontare con molta attenzione le due modalità per scegliere
quella che più si adegua alle tue esigenze, conoscenze, tempi di design.
Ciao, Simone

quella che più si adegua alle tue esigenze, conoscenze, tempi di design.
Mi era sembrato di capire che ODBC fosse una modalità alquanto lenta;
ADP "ceteris paribus" non dovrebbe essere più veloce? Altrimenti cosa
l'hanno fatto a fare?
Comunque sia le mie conoscenze di SQL server sono praticamente =0. Ho
provato a installare SQL express e ho provato a fare l'upsize guidato
a progetto ADP  di tre tabelle di prova con un paio di quey e
integrità referenziale e mi sono perso alla prima stored procedure...
Temo che apprendere un minimo di operatività costi moltissimo in
termini di tempo anche con un po' di esperienza di Access :-(
Con la modalità ODBC lo sviluppo è più vicino al modo di procedere con
Jet?
Grazie ad entrambi per la disponibilità
Grazie

JET è un Engine di DB un pò diverso da quelli SQL, quindi
è opportuno sapere che le Queries vengono sempre e comunque
eseguite lato Client, a fronte di ciò è fondamentale l'uso
dell'indicizzazione
per i campi sui quali si effettuano ricerche.
C'è poi la possibilità di ottimizzare il piano di esecuzione delle
stesse
usando uno strumento che assomiglia a QueryAnalizer di cui trovi
dettagli
nel SC.
Se l'utente lascia la form in Dirty non è un problema, ovviamente
dipende da te che sviluppi la logica di logOff, ma fai UNDO sulla form
Dirty
e chiudi(come fa SAP)
La dimensione del BE non è stimabile a mio avviso.
ODBC è estremamente veloce ed affidabile, nonchè scalabile su
qualsiasi
altra piattaforma SQL.
ADP si appoggia ad OLEDB, è ottimizzato per un SERVER_SQL(MS)
quindi potrebbe risultare più flessibile, ma richiede un
ingegnerizzazione
elevata lato SERVER che rende il tutto poco scalabile(quì la scelta è
fondamentale) ovviamente si può usare ADP con ingegrerizzazione lato
Client, ma si sfruttano poco le potenzialità di ADP.
La maggiorparte dei DB non ha abbandonato ODBC, anzi...!
Cosa l'hanno fatto a fare ADP.....?
Beh sai che le strategie di mercato subiscono vari tentativi di
deviazione, questo
è uno di quelli meglio riusciti, ma che non ha poi convinto tutti i
produttori
di Database rimasti fedeli a ODBC.
Rimanendo al funzionamento ODBC la cosa rimane certamente più simile
al precedente, ma devi imparare ugualmente ad usare SP e Query_PT come
il pane...!
Ciao
@Alex

 Jet?
Fondamentalmente sì, anche se devi rinunciare all'utilizzo di alcune
features poco gradite da ODBC  (Dlookups, FindFirst invece che Select, etc.)
Comincia a leggere la seguente documentazione (e il white paper):
http://support.microsoft.com/default.aspx?scid=kb;en-us;128808
(lascia perdere, inizialmente, il discorso sulle querty pass Through che
rischia di confonderti).
Ciao, Simone


Va be' ... in ogni caso  ho capito: mi metto a studiare (ma che casino
il White Paper!, accidenti) e per il momento questo progetto lo faccio
fare a qualcunaltro.  :-(
Grazie di nuovo per la vs. disponibilità.

 fare a qualcunaltro.  :-(
Beh, dovresti mettere due PC in rete e fare delle prove per qualche tempo,
questo è scontato.
Ciao, Simone

 ha scritto nel messaggio 
news:1144601941.3...@i40g2000cwc.googlegroups.com...
E' noto che JET in rete possa dare qualche problema di corruzione, ma
a questo potresti ovviare con tecnologia T.S.(Terminal Service).
evitare queste cose(un LogOff dopo tempo di inattività), infondo anche
un ERP come SAP R/3 lo usa.....!
@Alex
Ciao Alex mi sapresti spegare come utilizzare un logOff su una maschera di 
access?
Saluti Andrea 

Ci sono diversi metodi e diversi utilizzi della cosa.
Io uso una Maschera nascosta che controlla l'inattività del Client e
dopo 10 Minuti
chiude il Client stesso.
La uso anche per verificare se ho attivato un'utility di Manutenzione
del Server, con
la quale setto a True un campo in una tabella, che forza sempre i
Client al LogOff
dopo 3Minuti...!
Ovviamente su Logon verifico che il valore sia False...!
Ciao
@Alex

 Ciao, Simone
Scusa Simone ma io sarò molto ignorante ma ADP e ODBC MDB/SQL Server
sono due concezioni totalmente diverse cioè
se io interrogo una tabella collegata via ODBC mi "sbrodola" per
la rete tutto il suo contenuto mentre con una richiesta da ADP
a sql server ottimizzo in maniera incredibile la quantità di dati che 
passano sulla rete...
o mi sfugge qualcosa?
grazie e ciao
ringo 

Sbagli completamente.
Una Query SQL anche eseguita via ODBC restituisce il Resultset lato
Client
e l'elaborazione(a meno di funzioni non native di SQL che richiedono
l'esecuzione
lato client) viene eseguita lato Server, pertanto nessuno sbrodolamento
di nulla.
Provare per credere...!
@Alex

 o mi sfugge qualcosa?
E' il discorso di prima: hai riferito un luogo comune, ma la realtà è
differente.
D'altra parte basta che tu metta in rete due pc e con l'analizzatore di rete
(o lo strumento di SQL Server) analizzi il traffico da Server a Client.
Come ti scrive Alessandro, il 95% del codice SQL scritto per JET viene
eseguito lato Server (fanno eccezione alcuni tipi di query a campi
incrociati e le query eterogenee).
Tutto questo è ufficialmente documentato anche nel white paper relativo a
ODBC di cui si parlava.
JET usa la chiamata ODBC SQLGetinfo per chiedere al Driver quali operatori e
funzioni siano disponibili sul Server SQL.
Solo quando JET trova un operatore o funzione non elaborabile lato Server
sposta tutto il Recordset sul Client.
Probabilmente esistono Server SQL che hanno una connettività ODBC scadente
verso JET, ma se restiamo in casa Microsoft (quantomeno fino a SQL Server
2000, che utilizzo) le cose funzionano ottimamente, da "manuale".
Comunque, il link a quel vecchio post relativo ad .ADP vs ODBC, che ho
postato sopra nel Thread,  è interessante e va letto interamente.
Ciao, Simone

 ha scritto nel messaggio 
news:1144867376.5...@z34g2000cwc.googlegroups.com...


Ciao
@Alex
Interessante, vedrò con "Miccola" di mettere a punto qualcosa del genere, ho 
la maschera di creazione preventivi che qualcuno lascia sempre aperta sul 
Client, non è un grosso problema ma visto che sono a sbucciare i peli, 
potrebbe essere una soluzione valida per apprezzare ancora di più 
l'applicativo.
Saluti Andrea 

Chi è Miccola...?
@Alex

 ha scritto nel messaggio 
news:1144919681.5...@z34g2000cwc.googlegroups.com...
Chi è Miccola...?
@Alex
Mio figlio chiama "Miccola" Nicola di Martino, ci ritroviamo quasi tutte le 
settimane per sviluppare, ovviamente il capo è lui ed io eseguo, ancora la 
mia conoscenza è estremamente limitata, lui invece essendo un pò più avanti 
di me mi ha preso sotto braccio e mi stà letteralmente iniziando ad access.
In pratica ci divertiamo unendo il dilettevole all'utile.
Saluti Andrea 


iuo non scarterei l'opportunità di ridiseganre le gerarchie e mettere come
capo sviluppo tuo figlio
;-)
-- 
_ _
Ciao
MAssimiliano Amendola            
www.accessgroup.it
Cisa - Conferenza Italiana per Sviluppatori Access
Info:  
www.donkarl.com/it

 ;-)
Potrebbe essere un'idea :-)
Saluti Andrea 

 @Alex
ciao & tks

La sicurezza sta nel fatto che un DB(Acces) in Rete è soggetto a
corruzioni, mentre
con TS hai solo l'interfaccia dati lato Client.
Leggiti informazioni su TS sia nel mio sito che in AccessGroup.
Per il LogOff ovviamente si deve chiudere l'applicativo.
Il Client impegna il Server quando è aperto un Recordset, quindi
con una Form Associata, con una Query in Visualizzazione, con un
Recordset Aperto...!
Nel caso nessuno di questi sia vero il Server è libero, anche se il
Client
risulta connesso(vedi il file LDF), ma serve sapere l'intenzione finale
prima
di trarre conclusioni...!
@Alex