Discussione:
Access con Jet oppure Access con SQL server 2500 express
(troppo vecchio per rispondere)
Four wheeler
2006-04-09 16:15:26 UTC
Permalink
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
Alessandro Baraldi
2006-04-09 16:59:01 UTC
Permalink
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
VedoTondo
2006-04-12 16:15:01 UTC
Permalink
"Alessandro Baraldi" <***@libero.it> ha scritto nel messaggio news:***@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
Alessandro Baraldi
2006-04-12 18:42:56 UTC
Permalink
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
VedoTondo
2006-04-13 08:45:24 UTC
Permalink
"Alessandro Baraldi" <***@libero.it> ha scritto nel messaggio news:***@z34g2000cwc.googlegroups.com...
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

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
Alessandro Baraldi
2006-04-13 09:14:41 UTC
Permalink
Chi è Miccola...?

@Alex
VedoTondo
2006-04-13 09:37:19 UTC
Permalink
"Alessandro Baraldi" <***@libero.it> ha scritto nel messaggio news:***@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
MA
2006-04-13 11:04:44 UTC
Permalink
Post by Alessandro Baraldi
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
VedoTondo
2006-04-13 11:20:53 UTC
Permalink
Post by MA
iuo non scarterei l'opportunità di ridiseganre le gerarchie e mettere come
capo sviluppo tuo figlio
;-)
Potrebbe essere un'idea :-)

Saluti Andrea
Bobo
2006-04-15 10:57:41 UTC
Permalink
Post by Alessandro Baraldi
E' noto che JET in rete possa dare qualche problema di corruzione, ma
a questo potresti ovviare con tecnologia T.S.(Terminal Service).
E come fa la tecnologia TS ad essere + sicura? A quel che ne capisco,
se ho 5 client che girano, che il codice del client sia eseguito dal
client, o dal terminal server e poi visualizzato dal client dovrebbe
essere lo stesso, dal punto di vista della sicurezza della base dati.
ergo, ne deduco di aver capito male e ti chiedo lumi...
Post by Alessandro Baraldi
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.....!
E il logoff come lo fai in access, chiudendo la maschera o chiudendo
l'intero frontend?
Te lo chiedo perché io ho implementato la multiutenza con un backend
con i dati, e i frontend con le tabelle collegate, e mi chiedo:
quale è la condizione per cui il client impegna la base dati? bisogna
che ci sia una maschera aperta su una tabella, per impegnare quella
tabella, oppure basta che sia aperto il client Access con le tabelle
collegate per dar fastidio a tutte le tabelle?
Post by Alessandro Baraldi
@Alex
ciao & tks
Alessandro Baraldi
2006-04-15 13:24:07 UTC
Permalink
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

Simone Calligaris
2006-04-09 17:43:51 UTC
Permalink
"Four wheeler"
Post by Four wheeler
oppure devo utilizzare necessariamente Access come front-end e SQL
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
Four wheeler
2006-04-09 22:47:30 UTC
Permalink
On 9 Apr 2006 09:59:01 -0700, "Alessandro Baraldi" <***@libero.it>
wrote:

[CUT]
Post by Four wheeler
un'applicazione
JET ben sviluppata è tranquillamente in grado di supportare una decina
di utenti
contemporanei senza particolari problemi.
Per" ben sviluppare" è sufficiente seguire quanto riportato su un
documento della Knowledgebase di MS o c'è altro? non è che per ben
sviluppare bisogna stravolgere tutte le logiche di sviluppo o ...
arrampicarsi sui vetri per aggirare i problemi di Jet?
Post by Four wheeler
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.....!
Ehm! se anche SAP lo fa allora ... Ma se un utente va a bersi il caffè
al bar (....) e lascia la maschera in "dirty" la procedura cosa fa?
salva il record (o per lo meno ci prova) ed esce oppure annulla le
modifiche con un rollback? si può fare anche con Jet?
In caso affermativo sai dove si può trovare un'esempio che mi faccia
capire la logica di funzionamento? (sul sito comune e su quello di
Donkarl non ho trovato nulla, così come su google )
[CUT]
Post by Four wheeler
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.
Ne deduco che il limite dei 2GB di access sia legato a Jet. Esiste un
sistema semplice per avere una stima delle dimensioni totali che
assumerà il back end Jet?
Post by Four wheeler
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.
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
Alessandro Baraldi
2006-04-10 06:23:34 UTC
Permalink
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
Simone Calligaris
2006-04-10 06:41:44 UTC
Permalink
"Four wheeler"
Post by Four wheeler
Mi era sembrato di capire che ODBC fosse una modalità alquanto lenta;
ADP "ceteris paribus" non dovrebbe essere più veloce?
A te non deve "sembrare di capire", devi sempre testare personalmente le
affermazioni di altri (anche le mie).
Se ti basi solo su opinioni di altri, prima di fare scelte difficili, stai
fresco :-)

Comunque, no, l'interfacciamento ODBC a SQL Server è molto veloce se non si
commettono alcune "classiche" ingenuità.
Post by Four wheeler
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?
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
Four wheeler
2006-04-11 21:49:45 UTC
Permalink
On Mon, 10 Apr 2006 08:41:44 +0200, "Simone Calligaris"
Post by Simone Calligaris
"Four wheeler"
Post by Four wheeler
Mi era sembrato di capire che ODBC fosse una modalità alquanto lenta;
ADP "ceteris paribus" non dovrebbe essere più veloce?
A te non deve "sembrare di capire", devi sempre testare personalmente le
affermazioni di altri (anche le mie).
Se ti basi solo su opinioni di altri, prima di fare scelte difficili, stai
fresco :-)
Si, ma gli altri non sono il primo che passa...o no? ;-)
"un nome = una garanzia" E' un po' come se se dovessi costruire un
palazzo: prima di farlo mi informerei su si fa; altrimenti provo a
costruirlo, crolla perchè non ne sono capace, e ricomincio ...Ma
intanto potrei essere rimasto sepolto dal crollo ... :-|
Post by Simone Calligaris
Comunque, no, l'interfacciamento ODBC a SQL Server è molto veloce se non si
commettono alcune "classiche" ingenuità.
Post by Four wheeler
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?
Fondamentalmente sì, anche se devi rinunciare all'utilizzo di alcune
features poco gradite da ODBC (Dlookups, FindFirst invece che Select, etc.)
Giusto per curiosità qual'è l'alternativa a Dlookup (e anche a Dmax,
immagino!): una stringa SQL con un Where e SQL con un Where + la
funzione Max (supportata da SQLserver) oppure qulacosa di diverso?
Post by Simone Calligaris
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à.
Simone Calligaris
2006-04-11 22:20:06 UTC
Permalink
"Four wheeler"
Post by Four wheeler
Si, ma gli altri non sono il primo che passa...o no? ;-)
"un nome = una garanzia" E' un po' come se se dovessi costruire un
palazzo: prima di farlo mi informerei su si fa; altrimenti provo a
costruirlo, crolla perchè non ne sono capace, e ricomincio ...Ma
intanto potrei essere rimasto sepolto dal crollo ... :-|
Hai ragione anche tu ;-)
Ma un conto è avere un'opinione da una persona che conosci bene e di cui ti
fidi, un'altra affidarsi alle dicerie dello Usenet che a volte è prezioso,
altre inganna.

Il fatto stesso che tu non abbia provato connessioni odbc in rete e mappato
la modalità con cui vengono spediti i pacchetti al Client, significa che ti
sei fidato delle "voci" sulla lentezza di questa modalità: errore.

Comunque facendo una ricerca con google ho trovato un vecchio post, che
leggo pure io per la prima volta, interessante nei contenuti (in rapporto
alla domanda sugli adp che facevi):

http://groups.google.it/group/microsoft.public.it.office.access/browse_frm/t
hread/bffb70428528a9d1/b0a59a74a5f19426?q=Adp+%2Bprestazioni&rnum=1#b0a59a74
a5f19426
Post by Four wheeler
Giusto per curiosità qual'è l'alternativa a Dlookup (e anche a Dmax,
immagino!): una stringa SQL con un Where e SQL con un Where + la
funzione Max (supportata da SQLserver) oppure qulacosa di diverso?
Vedi che il discorso si amplia?
Potresti utilizzare l'SQL del Server, senza dimenticare che le query Pass
Th. restituiscono Recordset a sola lettura.
Ma spesso è possibile utilizzare subqueries supportate da Jet per ottenere
il risultato.
Post by Four wheeler
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. :-(
Beh, dovresti mettere due PC in rete e fare delle prove per qualche tempo,
questo è scontato.

Ciao, Simone
ringo
2006-04-13 08:06:49 UTC
Permalink
Post by Simone Calligaris
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
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
Alessandro Baraldi
2006-04-13 08:13:30 UTC
Permalink
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
Simone Calligaris
2006-04-13 08:31:51 UTC
Permalink
"ringo" <
Post by ringo
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?
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
Loading...