Discussione:
dati sql server express e front end access
(troppo vecchio per rispondere)
tmtube
2014-02-26 19:36:49 UTC
Permalink
innanzi tutto mi chiedo se ne vale la pena
poi mi chiedevo se posso creare tabelle in sql server express e poi gestirle
come tabelle collegate in access come front end creando
tutte le query from report necessari ma avendo cosi le prestazioni di sql
server express?

grazie a tutti per le delucidazioni
774
2014-02-26 23:48:43 UTC
Permalink
Post by tmtube
innanzi tutto mi chiedo se ne vale la pena
poi mi chiedevo se posso creare tabelle in sql server express e poi
gestirle come tabelle collegate in access come front end creando
tutte le query from report necessari ma avendo cosi le prestazioni di sql
server express?
grazie a tutti per le delucidazioni
Quando, tanti anni fa, ho riscontrato un drammatico calo delle prestazioni
portando un mio gestionale in rete, ho deciso di utilizzare Sql Express e
interfacciarlo con Access come front end ma utilizzando il formato Adp. In
questo modo sql viene riconosciuto in modo nativo ed è possibile gestire
tabelle e query di sql server come se fossero locali all'applicazione
access. Un altro mondo. Le controindicazioni sono 2: bisogna programmare in
vba in modo leggermente diverso usando sintassi leggermente diverse nelle
query e, soprattutto, questo formato non è più supportato in Access 2013. Ma
per quanto mi riguarda non lo abbandonerò finchè posso. Avevo provato
all'inizio ad usare access come front end collegando le tabelle sql server
via odbc ma il tutto mi risultava lento e macchinoso, anche se vedo che nel
NG molti usano questo sistema, magari non ero in grado allora di utilizzarlo
al meglio. Il motivo per cui il formato Adp è molto effiiciente in rete è
dovuto al fatto che questo formato NON ha, a differenza dell'mdb (e accdb)
un proprio motore di database ma si appoggia a quello di sql server. In
questo modo ogni query che effettuiamo sui dati viene per forza trasformata
in una interrogazione al server e in rete viaggiano solo le interrogazioni
sql e i dati inviati dal server. Perdonatemi la lunghezza della risposta ma
per me tutto ciò è l'uovo di colombo: la semplicità d'uso di access come
front end per form e report e la potenza e la sicurezza di sql server come
base dati. Saluti
tmtube
2014-02-27 00:44:10 UTC
Permalink
Post by 774
questo modo ogni query che effettuiamo sui dati viene per forza trasformata
in una interrogazione al server e in rete viaggiano solo le interrogazioni
sql e i dati inviati dal server. Perdonatemi la lunghezza della risposta ma
per me tutto ciò è l'uovo di colombo: la semplicità d'uso di access come
front end per form e report e la potenza e la sicurezza di sql server come
base dati. Saluti
Utilizzo access xp, (troppo vecchio?) e vorrei adottare il tuo sistema adp +
sql server express 2012?
possiamo sentirci per un eventuale consulenza più approfondita in merito?

se interessato scrivimi a tmtube73(""chiocciola"")gmail.com

Grazie.
Fair87
2014-02-27 16:46:26 UTC
Permalink
Post by tmtube
Post by 774
questo modo ogni query che effettuiamo sui dati viene per forza trasformata
in una interrogazione al server e in rete viaggiano solo le interrogazioni
sql e i dati inviati dal server. Perdonatemi la lunghezza della risposta ma
per me tutto ciò è l'uovo di colombo: la semplicità d'uso di access come
front end per form e report e la potenza e la sicurezza di sql server come
base dati. Saluti
Utilizzo access xp, (troppo vecchio?) e vorrei adottare il tuo sistema adp +
sql server express 2012?
possiamo sentirci per un eventuale consulenza più approfondita in merito?
se interessato scrivimi a tmtube73(""chiocciola"")gmail.com
Grazie.
Personalmente non userei mai un costrutto (adp) che è stato già deprecato. E' da pazzi, dovendo cominciare ora. ODBC funziona perfettamente (oltre ad essere ora raccomandato da Microsoft) e le prestazioni sono alte. Mai usato Adp, ma penso siano confrontabili. Se poi, visto che c'è, usassimo anche le qualche particolarità dell'Sql invece che ostinarsi a fare tutto da Access, migliorerebbero ancora.
pfmarro
2014-03-01 08:15:04 UTC
Permalink
Grazie del messaggio cosa intendi per SQL e non access?
pfmarro
2014-03-01 09:35:02 UTC
Permalink
Fair87
2014-03-01 12:51:37 UTC
Permalink
viste, stored procedure, t-sql
BFS
2014-02-27 09:05:16 UTC
Permalink
Post by 774
Post by tmtube
innanzi tutto mi chiedo se ne vale la pena
poi mi chiedevo se posso creare tabelle in sql server express e poi
gestirle come tabelle collegate in access come front end creando
tutte le query from report necessari ma avendo cosi le prestazioni di sql
server express?
grazie a tutti per le delucidazioni
Quando, tanti anni fa, ho riscontrato un drammatico calo delle prestazioni
portando un mio gestionale in rete, ho deciso di utilizzare Sql Express e
interfacciarlo con Access come front end ma utilizzando il formato Adp. In
questo modo sql viene riconosciuto in modo nativo ed è possibile gestire
tabelle e query di sql server come se fossero locali all'applicazione
access. Un altro mondo. Le controindicazioni sono 2: bisogna programmare in
vba in modo leggermente diverso usando sintassi leggermente diverse nelle
query e, soprattutto, questo formato non è più supportato in Access 2013. Ma
per quanto mi riguarda non lo abbandonerò finchè posso. Avevo provato
all'inizio ad usare access come front end collegando le tabelle sql server
via odbc ma il tutto mi risultava lento e macchinoso, anche se vedo che nel
NG molti usano questo sistema, magari non ero in grado allora di utilizzarlo
al meglio. Il motivo per cui il formato Adp è molto effiiciente in rete è
dovuto al fatto che questo formato NON ha, a differenza dell'mdb (e accdb)
un proprio motore di database ma si appoggia a quello di sql server. In
questo modo ogni query che effettuiamo sui dati viene per forza trasformata
in una interrogazione al server e in rete viaggiano solo le interrogazioni
sql e i dati inviati dal server. Perdonatemi la lunghezza della risposta ma
per me tutto ciò è l'uovo di colombo: la semplicità d'uso di access come
front end per form e report e la potenza e la sicurezza di sql server come
base dati. Saluti
confermo tutto
pure io uso da anni sql server + adp
prestazioni ed affidabilita sono stratosferiche.
sarà per quello che microsoft ha tolto il formato adp...funzionava :-)

ciao
BFS
tmtube
2014-02-27 19:18:58 UTC
Permalink
Post by BFS
confermo tutto
pure io uso da anni sql server + adp
prestazioni ed affidabilita sono stratosferiche.
sarà per quello che microsoft ha tolto il formato adp...funzionava :-)
ciao
BFS
Bella questa e pure realistica
Stefano C
2014-03-02 10:48:48 UTC
Permalink
Ciao,

io personalmente sottoscrivo in toto ciò che ha scritto Fair87: non
utilizzare mai l'adp, oltre ad essere deprecato, quando le dimensioni
dell'applicativo crescono fa acqua da tutte le parti, a partire dalle
prestazioni.

Usa ODBC e ADO, forms disconnessi (late binding) e query passthrough. E'
un poco (un poco veramente, non in senso ironico!) di lavoro in più
all'inizio, ma ne vale davvero la pena, non ti troverai mai in un vicolo
cieco a chiederti perché qualcosa improvvisamente rallenta o smette di
funzionare.

Ciao.
Stefano
Post by tmtube
innanzi tutto mi chiedo se ne vale la pena
poi mi chiedevo se posso creare tabelle in sql server express e poi
gestirle come tabelle collegate in access come front end creando
tutte le query from report necessari ma avendo cosi le prestazioni di
sql server express?
grazie a tutti per le delucidazioni
Mancini
2014-03-02 14:26:42 UTC
Permalink
Ba !!! visto che è Domenica e stiamo conversando ci metto il becco anchio
che purtroppo non sono piu giovanissimo bensi piu giovane dei giovani vecchi

Ai tempi di SQLServer98 ( forse 97 ) la versione Express si chiamava MSDN
che era composta solo ed esclusivamente dal motore del DB e mancava totalmente ManagementStudio.

Pertanto per la gestione di MSDN era praticamente obbligatorio usare i file .adp che di fatto inglobavano la gestione e creazione del DB lato Server e la creazione della applicazione lato maschere.

Certamente .adp era molto molto rapido e potente, si poteva fare tutto sul DB, poteva essere considerato di fatto il DB

( -------
Piccola parentesi, mi sta tornando alla mente il casino che ho combinato quella volta che dovevo fare delle piccole modifiche alla applicazione,
Faccio una copia del mio .adp e comincio a modificare tabelle e query
- ma ero ancora connesso al DB principale
- da quella volta ho imparato bene
------------)

Torniamo a noi
Poi è arrivato SQLServer2005 ( poi 2008 2012 e 2014 ) con il suo ManagementStudio con cui si puo lavorare sulla parte Server, ci ho messo un po di tempo ad abituarmi perche gli .adp erano sempre li pronti e comodissimi

ma un giorno con ManagementStudio ho generato lo Script di un DB creato e modificato con .adp e mi sono accorto che avevo oltre a quanto necessario quintali e quintali e quintali di "ProprietaEstese" che all'inizio non capivo,
ma poi ho capito che quelle erano tutte le modifiche storiche che avevo fatto.

Quindi se io un campo per esempio lo avevo modificato da Nvarchar(50) a Nvarchar(60) e viceversa questo mi restava nel DB

Io da quel giorno ho abbandonato .adp a favore di ManagementStudio per le modifiche al DB e Access per la applicazione.

__________________________________________________________

Verissimo Access è piu lento, ma la colpa non è di Access bensi di come vengono costruite le query di Access,

Se nella query ci mettiamo
.... WHERE Campo=Forms!......!..... eccetera
questa non puo essere interpretata da SQLServer quindi tutta la massa di record della tabella transita nella rete e poi la query viene eseguita da Access

Se invece nella query ci mettiamo
.... WHERE Campo=" & Forms!......!..... & " eccetera
allora VBA interpreta questa query
e prima di spedirla a SQLServer la traduce cosi:
.... WHERE Campo=5 eccetera
Questa puo essere interpretata direttamente da SQLServer e pertanto nella rete viaggiano solo i record interessati.

NB: a questo proposito devo dare il merito a @Alex ( che saluto) per avermi aperto gli occhi con i suoi articoli e risposte su queste problematiche che non ho ancora compreso pienamente

_______________________________________________________________

Poi se vogliamo ancora velocizzare Access su SQLServer abbiamo le query passTrought e le Stored

Ma non mi dilungo oltre se non postando sotto il testo di una query "Sperimentale" e senza significato pratico che ho testato in mattinata
si tratta di una PassTrought unica che di fatto contiene 3 query nidificate che fanno riferimento l'una all'altra

[code]
-- prepariamo 3 query di origine ( qqq01, qqq02, qqq03 )

WITH
qqq1 AS (
SELECT TaId, TaNote, TaNum FROM TempT
),

qqq2 AS (
SELECT TaId, TaNote, TaNum FROM TempT
),


qqq3 AS (
SELECT TaId, TaNote, TaNum FROM qqq1
UNION ALL
SELECT TaId, TaNote, TaNum FROM qqq2
)


-- Con quest'ultima sintetizzo le precedenti 3 query
-- osserva che qqq03 è gia prodotta a sua volta da qqq1 e qqq2

SELECT TaId, TaNote, TaNum FROM qqq1
UNION ALL
SELECT TaId, TaNote, TaNum FROM qqq2
UNION ALL
SELECT TaId, TaNote, TaNum FROM qqq3
[/code]



Scusatemi se mi sono dilungato ( ma è domenica )
pfmarro
2014-03-03 16:26:19 UTC
Permalink
meno male che ogni tanto e' domenica e qualcuno si prolunga a scrivere!!!

GARZIE!!!

E' che vorrei portare aventi questo argomento.
avevo posto alcune domande. vedasi thread "Msaccess con dati SQL-server e query" che purtroppo solo uno ha risposto.

access con Sql server via ODBC penso sia la strada migliore.

- viste di SQL server le trovo molto utili anche se noto che collegate ad access perdono gli eventuali ordinamenti.
di negativo noto che il refresh dei dati e' lento e ogni volta che aggiorno il FE non mi basta utilizzare Gestione Tabelle collegate, ma per le viste devo cancellare i collegamenti e ricrearli perche' se si fa il refresh del collegamento diventano solo lettura. (Avete provato a creare degli indici per viste?)

- creare delle query pass-through. utili ma non utilizzabili per altre query. (query di query: es query di raggruppamento di una query pass-through)
molte volte per standardizzare le procedure creo una query (in MaAccess) da VBA con i filtri definiti dall'utente in effetti la stringa SQL ha il filtro tipo where ID = 5 come scrivi tu e non riferimenti alla maschera.
la query poi e' materia prima di query successive di raggruppamento. Tale procedura la trovo utile anche se lenta in fase di esecuzione


- la sicurezza della query pass-through? la password resta in chiaro!
Post by Mancini
Ba !!! visto che è Domenica e stiamo conversando ci metto il becco anchio
che purtroppo non sono piu giovanissimo bensi piu giovane dei giovani vecchi
Ai tempi di SQLServer98 ( forse 97 ) la versione Express si chiamava MSDN
che era composta solo ed esclusivamente dal motore del DB e mancava totalmente ManagementStudio.
Pertanto per la gestione di MSDN era praticamente obbligatorio usare i file .adp che di fatto inglobavano la gestione e creazione del DB lato Server e la creazione della applicazione lato maschere.
Certamente .adp era molto molto rapido e potente, si poteva fare tutto sul DB, poteva essere considerato di fatto il DB
( -------
Piccola parentesi, mi sta tornando alla mente il casino che ho combinato quella volta che dovevo fare delle piccole modifiche alla applicazione,
Faccio una copia del mio .adp e comincio a modificare tabelle e query
- ma ero ancora connesso al DB principale
- da quella volta ho imparato bene
------------)
Torniamo a noi
Poi è arrivato SQLServer2005 ( poi 2008 2012 e 2014 ) con il suo ManagementStudio con cui si puo lavorare sulla parte Server, ci ho messo un po di tempo ad abituarmi perche gli .adp erano sempre li pronti e comodissimi
ma un giorno con ManagementStudio ho generato lo Script di un DB creato e modificato con .adp e mi sono accorto che avevo oltre a quanto necessario quintali e quintali e quintali di "ProprietaEstese" che all'inizio non capivo,
ma poi ho capito che quelle erano tutte le modifiche storiche che avevo fatto.
Quindi se io un campo per esempio lo avevo modificato da Nvarchar(50) a Nvarchar(60) e viceversa questo mi restava nel DB
Io da quel giorno ho abbandonato .adp a favore di ManagementStudio per le modifiche al DB e Access per la applicazione.
__________________________________________________________
Verissimo Access è piu lento, ma la colpa non è di Access bensi di come vengono costruite le query di Access,
Se nella query ci mettiamo
.... WHERE Campo=Forms!......!..... eccetera
questa non puo essere interpretata da SQLServer quindi tutta la massa di record della tabella transita nella rete e poi la query viene eseguita da Access
Se invece nella query ci mettiamo
.... WHERE Campo=" & Forms!......!..... & " eccetera
allora VBA interpreta questa query
.... WHERE Campo=5 eccetera
Questa puo essere interpretata direttamente da SQLServer e pertanto nella rete viaggiano solo i record interessati.
_______________________________________________________________
Poi se vogliamo ancora velocizzare Access su SQLServer abbiamo le query passTrought e le Stored
Ma non mi dilungo oltre se non postando sotto il testo di una query "Sperimentale" e senza significato pratico che ho testato in mattinata
si tratta di una PassTrought unica che di fatto contiene 3 query nidificate che fanno riferimento l'una all'altra
[code]
-- prepariamo 3 query di origine ( qqq01, qqq02, qqq03 )
WITH
qqq1 AS (
SELECT TaId, TaNote, TaNum FROM TempT
),
qqq2 AS (
SELECT TaId, TaNote, TaNum FROM TempT
),
qqq3 AS (
SELECT TaId, TaNote, TaNum FROM qqq1
UNION ALL
SELECT TaId, TaNote, TaNum FROM qqq2
)
-- Con quest'ultima sintetizzo le precedenti 3 query
-- osserva che qqq03 è gia prodotta a sua volta da qqq1 e qqq2
SELECT TaId, TaNote, TaNum FROM qqq1
UNION ALL
SELECT TaId, TaNote, TaNum FROM qqq2
UNION ALL
SELECT TaId, TaNote, TaNum FROM qqq3
[/code]
Scusatemi se mi sono dilungato ( ma è domenica )
774
2014-03-03 18:03:26 UTC
Permalink
Post by Stefano C
Ciao,
io personalmente sottoscrivo in toto ciò che ha scritto Fair87: non
utilizzare mai l'adp, oltre ad essere deprecato, quando le dimensioni
dell'applicativo crescono fa acqua da tutte le parti, a partire dalle
prestazioni.
Non sono affatto d'accordo!

Per me è esattamente il contrario.

Allora, adesso ho bisogno di esprimere tutto quello che penso al riguardo e
tutta la mia (opinabile) esperienza in materia, altrimenti perdo tutte le
mie certezze.

Access via ODBC: usa sia il proprio motore jet che il motore Sql Server per
le query che vengono eseguite sul server

Access adp: NON ha motore interno, quindi tutte le operazioni sui dati
devono PER FORZA essere eseguite lato server.

La conseguenza di tutto ciò è che, secondo me, Access con ODBC non è un
sistema Client-Server puro, Adp invece lo è.

ODBC può vedere le tabelle di Sql Server come tabelle collegate, Adp non le
collega neanche, semplicemente collega una volta per tutto l'intero database
e si interfaccia in modo totale con esso.

In Adp Access è ancora più semplificato rispetto a ODBC.

Facciamo un esempio: ho una tabella collegata di un milione di record e ne
cerco uno solo, se faccio una interrogazione su una maschera, all'interno di
Vba per cercare questo record access tende ad usare il motore Jet e quindi
si comporta da ....Access, facendo transitare tutta la tabella in rete fino
a trovare il record giusto, con enormi rallentamenti, in pratica si comporta
come un sistema File-Server, a meno di non usare query pass-through, ma mi
conviene creare query di questo tipo ogni volta che cerco prestazioni in
rete?

Adp invece, in automatico, delega il motore del server per tutto, senza
preoccuparmi di niente.



Le prime volte che cercavo prestazioni migliori per i miei applicativi in
rete ho cercato di usare ODBC, ma le prestazioni erano deludenti, in più se
volevo velocizzare le query dovevo usare query pass-through oppure viste
memorizzate sul server.

In una normale form ci sono listbox, caselle combinate ecc, ognuna con la
propria origine riga, con Adp imposto la select e so che in ogni caso verrà
eseguita sul server, con ODBC invece dovrei costruire una query p-t ogni
volta, ma chi me lo fa fare?



ODBC è una soluzione a metà strada tra access e sql server, invece Adp usa
il motore sql server per tutto. E' come se fosse un sql server che abbiamo
dotato degli oggetti che gli mancano: forms e reports.

Affidabilità: se partiamo dal presupposto che sql server sia affidabile e
access no, allora meglio Adp. Con Adp non è possibile creare tabelle e query
locali, access non contiene oggetti che possono creare una perdita dei dati.



Fair 87 ha scritto: "quando le dimensioni dell'applicativo crescono fa
acqua da tutte le parti, a partire dalle prestazioni."

Da dove trai questa conclusione? Proprio quando le dimensioni dell'applicativo
crescono Adp risulta vincente. Ho creato un gestionale con 160 form, 80
report, tabelle con centinaia di migliaia di record e l'applicativo va alla
grande da anni.



Mancini ha scritto: "Se nella query ci mettiamo
.... WHERE Campo=Forms!......!..... eccetera
questa non puo essere interpretata da SQLServer quindi tutta la massa di
record della tabella transita nella rete e poi la query viene eseguita da
Access

Se invece nella query ci mettiamo
.... WHERE Campo=" & Forms!......!..... & " eccetera
allora VBA interpreta questa query
e prima di