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 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."



Ecco appunto, perché scervellarsi nel cercare di capire se le query sono
nella forma eseguibile o meno dal server quando invece Adp le esegue tutte
sul server a prescindere?

Con Adp si ha il massimo delle prestazioni in rete. Con sospresa ho scoperto
che i miei programmi in Adp girano anche, anche se con un leggero
rallentamento, anche in reti Vpn via internet, cioè con il computer che
contiene l'applicativo Adp e il server che contiene il database separati da
migliaia di chilometri. Provate a fare questo con ODBC senza infarcire l'applicativo
di centinaia di query PT o di viste residenti sul server create magari solo
per alimentare una singola casella combinata!
Post by Stefano C
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.
Non so di cosa parli, in tanti anni mai successo.

Non so perché Microsoft spinga verso ODBC, eppure Adp, essendo in completa
sinergia con Sql Server, dovrebbe contribuire a far usare sempre di più
quest'ultimo. Un motivo per usare ODBC e il poter usare motori di database
diversi da Sql Server, che è poi in fondo una caratteristica che Access
vuole avere dalla nascita, cioè la possibilità di accedere a ogni fonte di
dato.



Rispondo a tmtube:

Effettivamente non mi sento di consigliarti in toto Adp, ma solo perchè
sappiamo che è una soluzione che verrà abbandonata, dal punto di vista
tecnico e pratico invece è da me consigliatisssima. E' anche verò però che
esistono ed esisteranno, spero per tanti anni i Runtime di Access Xp, 2003,
2007, 2010, quindi che supportano tutti Adp, quindi questo formato sarà
utilizzabile per molti anni ancora. L'accoppiata che mi hai proposto, cioè
Access Xp + Sql Server 2012 mi sembra un po' sbilanciata, ti spiego perché.
Ho usato per anni Sql Server 2000, di cui avevo la licenza developer. Poi il
2000 non era più supportato in Vista e ho dovuto cambiare. Ho cercato di
utilizzare per lo sviluppo Sql Server 2008, ma dopo giorni di tentativi non
sono riuscito ad installarlo, quindi ho optato per Sql Server 2005, che va
benissimo per tutte le nostre esigenze. Sql Server è un database molto
potente, in grado di "digerire" tutte le nostre applicazioni, anche in rete
locale con molti client. Usare la versione 2005 secondo me conviene, in
quanto molto più snella della 2008 e, presumo, della 2012, che non ho mai
avuto modo di provare. Attualmente utilizzo: Access Xp e Sql Server Express
2005. Per gestire il database utilizzo Sql Server Management Studio (SSMS).
Sia Sql Express che SSMS sono scaricabili gratuitamente e sono liberamente
utilizzabili. Dal cliente scarico e installo Sql Express 2005 e SSMS e, se
non hanno Access, il Runtime di Access Xp. Un difetto di questa soluzione è
l'impossibilità di gestire gli oggetti del database direttamente da access,
cosa possibile con Access 2007: in questo modo si possono creare tabelle,
query ecc nel database direttamente da Access senza neanche aver bisogno di
SSMS.

Ultimo pensiero, magari non ovvio per chiunque, lo stesso database Sql
Server può essere usato contemporaneamente da applicativi Access ODBC e da
applicativi Adp senza problemi.



Scusate la lunghezza ma il fine del NG è di crescere tutti ed è utile
l'esperienza di ognuno.
Stefano C
2014-03-03 21:08:42 UTC
Permalink
Post by 774
Post by Stefano C
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.
Non so di cosa parli, in tanti anni mai successo.
Parlo di questo:

"Microsoft Access Developer's Guide to SQL Server" -- Chipman & Baron

E' un discorso davvero molto lungo e vasto. Non riguarda il numero di
forms in un'applicazione, riguarda databases con centinaia di migliaia
di records da incrociare ed aggregare in tutti i modi, su tabelle con
accesso concorrente ai records.

In questi casi l'applicazione va strutturata interamente su server, con
viste, stored procedures e funzioni in T-SQL, richiamate da query
passthrough eventualmente create "al volo" (conosci l'oggetto QueryDef?).

.adp è un wrapper attorno a ODBC. Anch'io l'ho usato, ma davvero a
ragion veduta non mi sentirei di consigliare un'esperienza che non
rifarei. Un esempio fra molti: sai che croce gestire gli accessi
concorrenti da .adp?

Ciao
Stefano
774
2014-03-04 19:06:17 UTC
Permalink
Post by Stefano C
"Microsoft Access Developer's Guide to SQL Server" -- Chipman & Baron
E' un discorso davvero molto lungo e vasto. Non riguarda il numero di
forms in un'applicazione, riguarda databases con centinaia di migliaia di
records da incrociare ed aggregare in tutti i modi, su tabelle con accesso
concorrente ai records.
Esatto, 160 forms presuppongono decine e decine di tabelle relazionate tra
di loro con centinaia di migliaia di record
Post by Stefano C
In questi casi l'applicazione va strutturata interamente su server, con
viste, stored procedures e funzioni in T-SQL, richiamate da query
passthrough eventualmente create "al volo" (conosci l'oggetto QueryDef?).
Esatto, quello che si fa quando si crea un database da interfacciare in
seguito con .Adp
Post by Stefano C
.adp è un wrapper attorno a ODBC. Anch'io l'ho usato, ma davvero a ragion
veduta non mi sentirei di consigliare un'esperienza che non rifarei. Un
esempio fra molti: sai che croce gestire gli accessi concorrenti da .adp?
.Adp non c'entra con ODBC, è un'altra cosa.
Gestire gli accessi concorrenti? Certo che si fa con Adp. Sempre di Sql
Server si tratta.
s***@gmail.com
2014-03-04 20:14:40 UTC
Permalink
Post by 774
.Adp non c'entra con ODBC, è un'altra cosa.
Ehm... .adp usa il provider OLEDB (deprecato) e il cursore ADO (non deprecato e anzi pienamente supportato), che a sua volta "siedono" su ODBC...
Post by 774
Gestire gli accessi concorrenti? Certo che si fa con Adp. Sempre di Sql
Server si tratta.
Io personalmente no sono mai riuscito a gestire il tracking delle modifiche con .adp. Soprattutto, se usi locks pessimistici il record diventa inaccessibile anche in lettura. Con dei recordset ADO disconnessi, riesci a fare aprire lo stesso record a quanti utenti vuoi e per quanto tempo vuoi; se due tentano di salvare una variazione, il server ne committa una e all'altro segnala che il record è stato modificato, chiedendo se si desidera ricaricarlo con le ultime modifiche. Questo da .adp non saprei proprio come gestirlo...

E comunque con .adp: No Local Storage, No Local Queries, Security Limitations

Ciao.
Stefano
Fair87
2014-03-04 22:04:26 UTC
Permalink
discussione con poco senso. adp e oledb sono deprecati. basta questo per convincere chiunque debba cominciare oggi a non usarlo. se qualcuno ha già una struttura su queste basi è ovvio continuare ad usarla. ma imbastirla oggi è assurdo. io ho impiegato tanto a convincermi a passare a sql +odbc+access quando oledb sembrava la luna. mai avuto problemi (e lemie tabelle ne contengono milioni di record. e hanno più del doppio delle form di cui si parlava). senza nessuno sforzo diverso che farlo in access. non è questione di decidere se sia jet o sql a risolvere. se imposti bene (=non fai 'accessate') non hai problemi. se una procedura è dichiarata obsoleta, è obsoleta.
774
2014-03-04 23:38:24 UTC
Permalink
Post by 774
.Adp non c'entra con ODBC, è un'altra cosa.
Ehm... .adp usa il provider OLEDB (deprecato) e il cursore ADO (non
deprecato e anzi pienamente supportato), che a sua volta "siedono" su
ODBC...
Non sapevo che OLEDB fosse deprecato, questo potrebbe giustificare in parte
la cattiva fama di Adp
Post by 774
Gestire gli accessi concorrenti? Certo che si fa con Adp. Sempre di Sql
Server si tratta.
Io personalmente no sono mai riuscito a gestire il tracking delle modifiche
con .adp. Soprattutto, se usi locks pessimistici il record diventa
inaccessibile anche in lettura. Con dei recordset ADO disconnessi, >riesci
a fare aprire lo stesso record a quanti utenti vuoi e per quanto tempo
vuoi; se due tentano di salvare una variazione, il server ne committa una e
all'altro segnala che il record è stato modificato, >chiedendo se si
desidera ricaricarlo con le ultime modifiche. Questo da .adp non saprei
proprio come gestirlo...
E comunque con .adp: No Local Storage, No Local Queries, Security Limitations
Concordo sulle prime 2, per quanto riguarda le Security Limitation mi
piacerebbe approfondire

Mi chiedo una cosa però: in tutto questo discorso stiamo parlando di vere e
proprie applicazioni vero?
Usiamo tutti, come faccio io, il Vba in modo intensivo per tutto, usiamo in
modo intensivo i recordset nel codice?
Dico questo perchè mi è capitato di vedere applicazioni in cui tutta la
logica di programmazione veniva relegato alle query memorizate, compresa
l'origine dati delle maschere ad esempio.
In questo caso è chiaro che il numero delle query aumenta in modo
spropositato.
Se si sfrutta al massimo vba magari l'esigenza delle query locali e delle
query in generale viene meno.
Le query memorizzate nel database le uso solo per usi generali, cioè solo
per select complesse che includono molte tabelle e che vengono usate in
molte parti del programma.
Si sente ogni tanto il bisogno di memorizzare dei dati in modo temporaneo,
in questo caso, non potendo usare tabelle locali, trovo molto utili e comode
le tabelle temporanee di Sql Server, delle vere e proprie tabelle che si
possono creare a runtime e che durano il tempo della sessione.
Post by 774
Ciao.
Stefano
Ciao
Stefano C
2014-03-05 20:48:59 UTC
Permalink
Post by 774
Concordo sulle prime 2, per quanto riguarda le Security Limitation mi
piacerebbe approfondire
.adp è un tunnel diretto su SQL Server. Mi sembra che senza .adp
sia più facile scrivere meccanismi di autenticazione (Windows auth / SQL
auth).

Diciamo che con ODBC+VBA controllo meglio la situazione e dormo più
tranquillo.
Post by 774
Mi chiedo una cosa però: in tutto questo discorso stiamo parlando di vere e
proprie applicazioni vero?
Usiamo tutti, come faccio io, il Vba in modo intensivo per tutto, usiamo in
modo intensivo i recordset nel codice?
Forse ti ho già scritto che per me il punto di *partenza* è il testo di
Chipman & Baron ;-)
Post by 774
Si sente ogni tanto il bisogno di memorizzare dei dati in modo temporaneo,
in questo caso, non potendo usare tabelle locali, trovo molto utili e comode
le tabelle temporanee di Sql Server, delle vere e proprie tabelle che si
possono creare a runtime e che durano il tempo della sessione.
Mmm... in una tabella locale puoi fare anche calcolo statistici
elaborati senza impegnare la CPU del server SQL, che poverina ha già
altro a cui pensare -- calcoli statistici che possono anche durare 10
secondi di orologio.

Ma vorrei chiarirti una cosa: io non condanno .adp, e neanche OLEDB, e
neanche il vecchio Jet. Indipendentemente dal fatto che Microsoft lo
abbia dichiarato "deprecared". E' una via per risolvere un problema,
quindi il fatto che non sia più supportato mi sembra più una questione
di strategia di mercato che di effettiva obsolescenza.

Il "dramma" di Access è che lascia fare di tutto a livello di codice,
macro, e chi più ne ha più ne metta, e quindi è più facile infilarsi in
un vicolo cieco. Cosa che è più difficile con .Net, che viene
considerato "serio": per me a torto, perché è possibile con poco sforzo
usare ADO esattamente come ADO.Net, e le possibilità di reporting di
Access tutti gli altri se le sognano. Alla fine i miei clienti chiedono
report con dati accurati, se chiedo a loro cos'è un backend
probabilmente mi rispondono il didietro :-)

Per me .adp è un vicolo cieco nel senso che quando devo scalare davvero
verso l'alto incontro muri invalicabili. Per cui a chi inizia dico:
impara la strada che sicuramente ti porta più lontano.

Ciao.
Stefano

Mancini
2014-03-03 21:57:50 UTC
Permalink
[cit]
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.
[/cit]
Bene, la discussione si fa interessante :-)


[cit]
La conseguenza di tutto ciò è che, secondo me, Access con ODBC non è un
sistema Client-Server puro, Adp invece lo è.
[/cit]
sistema Client-Server puro Non so cosa sia

i sistemi Client-Server invece sono costituiti da 2 entita che possono essere:
SQLServer + ASP
SQLServer + VB
MySql + Access
SQLServer + Access
Eccetera
Si tratta sempre di 2 entita distinte

a parer mio .adp invece E' DI FATTO IL DataBase


[cit]
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.
[/cit]
Appunto, adp è l'intero DataBase

Io per esempio ho delle applicazioni di access che si connettono contemporaneamente a 2 DB SQLServer
- Il DB contabile di terze parti
- il DB commesse

Uso tenere in Access una tabellina dove memorizzo dei dati stupidi come per esempio l'ultimo utente logato per ripresentarlo al successivo riavvio,
non potrei


Il magazzino ha una applicazione specifica di Access per fare solo le bolle,
non ha TUTTE LE TABELLE DEL DATABASE a disposizione come invece sarebbe con .adp

Va bene tu mi dirai che hai fatto l'utente limitato....
mi dirai che anche con Acces si puo .....



[cit]
a meno di non usare query pass-through, ma mi
conviene creare query di questo tipo ogni volta che cerco prestazioni in
rete?
[/cit]
La crei in un attimo,

Poi non è fondamentale che sia PassTrought, ma il suo testo deve essere conforme alla sintassi di SQLServer


[cit]
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.
[/cit]
Quello che ti dicevo prima, .adp è di fatto il DataBase e a parer mio è un fatto negativo,
Non sei piu su un Client-Server

Ma tu lo distribuiresti un file .adp a degli utenti sconosciuti che devono lavorare per esempio in internet ???



[cit]
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.
[/cit]
Anch'io stavo creando con .adp qualcosa di cosi mastodontico,
certo che funziona bene, ma ogni volta che dovevo fare una modifica sudavo freddo
Con Access ho spezzati il MegaMastodonte in una ventina di miniapplicazioni
Magazzino
Ordini
Fatture enmesse
Fatture Ricevute
... eccetera

Con un'unica aplicazione di LogIn che funziona da pannello e passa le credenziali alle altre applicazioni "satelliti"

Non tornerei mai al MegaMastodonte ( io il mio lo chiamavo cosi )


[cit]
Ecco appunto, perché scervellarsi nel cercare di capire se le query sono
nella forma eseguibile o meno dal server quando invece Adp le esegue tutte
sul server a prescindere?
[/cit]
Io non mi scervello, faccio una query PassTrought "muletto" gli incollo dentro iltesto della mia query e se funziona significa che funziona bene anche nella versione NON PassTrought



[cit]
Adp e il server che contiene il database separati da
migliaia di chilometri. Provate a fare questo con ODBC senza infarcire l'applicativo
di centinaia di query PT o di viste residenti sul server create magari solo
per alimentare una singola casella combinata!
[cit]
Anch' io lavoro bene in internet con ODBC non si tratta di migliaia di chilometri ma solo di qualche decina
Pero la mia linea non è a fibra

Ma io mi chiedo,
Se tu devi alimentare una casella combinata "stupida" con una query allora fai la query nel DataBase principale ????
a me sembra un "peccato mortale" !!!!


[cit]
Non so perché Microsoft spinga verso ODBC, eppure Adp, essendo in completa
sinergia con Sql Server, dovrebbe contribuire a far usare sempre di più
quest'ultimo.
[/cit]
Perche SQLServer è molto piu di .adp

SQLServer ( ripeto) puoi usarlo con ASP, VB, OpenOffice

Poi il tuo applicativo ha 160 Maschere che sembrano tante,
una banca che si appoggia a SQLServer in tutte le sue applicazioni avrebbe 16.000 maschere e 15.000 query,
Pensi che potrebbero stare tutte in un unico file

Le maschere puoi delocalizzarle, ma con le query come fai ????


Per concludere,
Io ero un fautore di .adp, ma dopo queste considerazioni lo sconsiglio,

Ti chiederei pero di provare a costruirti da ManagementStudio lo script del tuo DataBase ( basta anche solo 1 tabella ) e dicci poi cosa ti viene fuori
oltre al classico "CREATE TABLE ........"




Dopo rispondo anche a pfmarro

,
774
2014-03-04 16:54:11 UTC
Permalink
"Mancini" <***@gmail.com> ha scritto nel messaggio news:ec27983b-eaf6-4ece-8164-***@googlegroups.com...

[cit]
Post by Mancini
a parer mio .adp invece E' DI FATTO IL DataBase
No, è solo una interfaccia verso il database contenuto sul Server, così come
lo è il formato ODBC

[cit]
Post by Mancini
Appunto, adp è l'intero DataBase
Vedi sopra
Post by Mancini
Il magazzino ha una applicazione specifica di Access per fare solo le bolle,
non ha TUTTE LE TABELLE DEL DATABASE a disposizione come invece sarebbe con .adp
Al magazziniere gli fai un Adp specifico con le sole maschere per la
gestione delle bolle, all'amministrazione un Adp completo per fare tutto,
entrambi collegati allo stesso database.
Al magazziniere all'accesso gli assegni un account "Magazziniere" con una
sua password e gli dai accesso dentro Sql Server solo alle tabelle su cui
può operare, così è anche tutto più sicuro.
E magari poi, come o fatto io, ai commerciali gli crei delle pagine web in
formato .net che si collegano via internet solo alle tabelle di loro
competenza, sempre nello stesso database.
E nessuno vieta anche di creare applicazioni ODBC insieme alle Adp.
Post by Mancini
Ma tu lo distribuiresti un file .adp a degli utenti sconosciuti che devono
lavorare per esempio in internet ???
Spiegati meglio

[/cit]
Post by Mancini
Anch'io stavo creando con .adp qualcosa di cosi mastodontico,
certo che funziona bene, ma ogni volta che dovevo fare una modifica sudavo freddo
Con Access ho spezzati il MegaMastodonte in una ventina di miniapplicazioni
Magazzino
Ordini
Fatture enmesse
Fatture Ricevute
... eccetera
Potevi creare una ventina di miniapplicazioni tutte in formato Adp.
Post by Mancini
Ma io mi chiedo,
Se tu devi alimentare una casella combinata "stupida" con una query allora
fai la query nel DataBase principale ????
a me sembra un "peccato mortale" !!!!
No, nella proprietà OrigineRiga della casella combinata scrivo: "Select
campoi1, campo2 from tabella1 order by campo1"
Stop
Non creo nessuna query, non verrà memorizzata nessuna query nel database, ci
mancherebbe, cerco di crearne il meno possibile.
E' Adp che si occupa di elaborarla in fase di esecuzione, interrogando il
server "al volo" e restituendo il risultato nella casella combinata.
In Adp sono necessarie meno query memorizzate sul server, sempre secondo me,
Post by Mancini
SQLServer ( ripeto) puoi usarlo con ASP, VB, OpenOffice
esatto
Post by Mancini
Poi il tuo applicativo ha 160 Maschere che sembrano tante,
una banca che si appoggia a SQLServer in tutte le sue applicazioni avrebbe
16.000 maschere e 15.000 query,
Pensi che potrebbero stare tutte in un unico file
Le maschere puoi delocalizzarle, ma con le query come fai ????
Sottolineo: in Adp non c'è niente, è tutto sul server come ODBC, anche tutte
le query, quindi dove sta il problema?
Post by Mancini
Ti chiederei pero di provare a costruirti da ManagementStudio lo script del
tuo DataBase ( basta anche solo 1 tabella ) e dicci poi cosa ti viene
fuori
oltre al classico "CREATE TABLE ........"
Il mio database è memorizzato dentro Sql Server come i tuoi.
Adp, come ODBC, è solo un modo come un altro per interrogarlo.
All'inizio un mio database lo gestivo in ODBC, poi sono passato a gestirlo
in Adp, ma il database è sempre rimasto al suo posto, sul server. E' solo
migliorato il mio lavoro.
E posso in ogni momento passare a gestirlo in ODBC, o in entrambi i modi
contemporaneamente.
Ah, Adp è uno dei tanti formati di Access, come mdb, accdb ecc. Usare Adp
significa in ogni caso usare Access
Mancini
2014-03-05 08:19:16 UTC
Permalink
A questo punto mi sono incuriosito.

Premesso che ieri sera ho provato ad aprire un file .adp con Access2013 e non ho potuto perche ormai non è piu supportato

Ma ho un' altro PC con la versione 2007
Quindi faro qualche test

----- Innanzitutto
creare 2 DB identici con ManagementStudio e con .adp
modificare identicamente i 2 DB con ManagementStidio e con .adp
Generare lo Script dei 2 DB per esaminare le differenze delle proprieta estese

----- In secondo luogo
faro dei test di velocita magari con qualche milioncino di record nelle seguenti condizioni
Query .adp
query Access PassTrought
query Access Non PassTrought ma con comprensibile a SQLServer
query Access con sintassi tipica di Access
-- Magari il tutto su una connessione Internet

Mi occorre qualche giorno
faro sapere
pfmarro
2014-03-05 08:39:58 UTC
Permalink
Post by Mancini
A questo punto mi sono incuriosito.
Premesso che ieri sera ho provato ad aprire un file .adp con Access2013 e non ho potuto perche ormai non è piu supportato
Ma ho un' altro PC con la versione 2007
Quindi faro qualche test
----- Innanzitutto
creare 2 DB identici con ManagementStudio e con .adp
modificare identicamente i 2 DB con ManagementStidio e con .adp
Generare lo Script dei 2 DB per esaminare le differenze delle proprieta estese
----- In secondo luogo
faro dei test di velocita magari con qualche milioncino di record nelle seguenti condizioni
Query .adp
query Access PassTrought
query Access Non PassTrought ma con comprensibile a SQLServer
query Access con sintassi tipica di Access
-- Magari il tutto su una connessione Internet
Mi occorre qualche giorno
faro sapere
grazie del test!
se permetti facci sapere.

Buon lavoro
BFS
2014-03-05 09:35:04 UTC
Permalink
Post by Mancini
Query .adp
mi intrometto avendo sviluppato oltre un centinaio di applicazioni
adp+msde negli anni passati

query adp non esiste
tabelle, view e storedprocedure sono oggetti di sqlserver non del file
adp. sono elaborate e risolte sempre e solo dal server e i soli
risultati sono inviati al file adp

nel lontano 2005 se non ricordo male avevo fatto un test

a)be mdb
b)be sqlserver+ odbc
c)be sqlserver+adp

5.000.000 di record
query select...from...where...order by

tramite rete 100 mbit

a)da addormentarsi
b)nettamente meglio di a
c)nettamente meglio di b


ciao
BFS
774
2014-03-05 11:19:21 UTC
Permalink
Post by Mancini
A questo punto mi sono incuriosito.
Premesso che ieri sera ho provato ad aprire un file .adp con Access2013 e
non ho potuto perche ormai non è piu supportato
Ma ho un' altro PC con la versione 2007
Quindi faro qualche test
----- Innanzitutto
creare 2 DB identici con ManagementStudio e con .adp
modificare identicamente i 2 DB con ManagementStidio e con .adp
Generare lo Script dei 2 DB per esaminare le differenze delle proprieta estese
----- In secondo luogo
faro dei test di velocita magari con qualche milioncino di record nelle seguenti condizioni
Query .adp
query Access PassTrought
query Access Non PassTrought ma con comprensibile a SQLServer
query Access con sintassi tipica di Access
-- Magari il tutto su una connessione Internet
Mi occorre qualche giorno
faro sapere
Bene, solo che vorrei sottolineare alcune cose, se posso.
Non è necessario creare 2 DB, ne basta uno.
Crei un DB di qualche milioncino di record con Management Studio all'interno
di Sql Server nel Server remoto e poi accedi alternativamente a questo dal
client prima con un file access con connessione ODBC e poi con un file
access in formato .Adp.
Quando crei il file Adp basta che dici ad Access di utilizzare un database
esistente (quello da un milione di record) e non di crearne uno nuovo.
Ovviamente devi dare poi ad Adp il percorso corretto del database, come
farai con ODBC, se su internet su una vpn.
Prova in entrambi a creare una maschera con dentro magari una listbox e una
casellina con cui filtrare i dati della listbox, il tutto usando VBA e la
propietà me.elenco1.rowsource="Select .........."
Prova a visualizzare nella listbox solo 1 record, sempre impostando la
select nell'origine riga della listbox.
In ODBC prova a visualizzare nella listbox solo 1 record utilizzando tutti i
tipi di query che hai elencato prima e la select direttamente
nell'origineriga della listbox
Prova con entrambi i sistemi a usare una casella combinata con origineriga
una select che restituisce poche righe usando la clausola Group By
Cercare di visualizzare tutto il milione di record non avrebbe senso,
ovviamente, perchè con entrambi i sistemi i record dovrebbero fisicamente
transitare in rete.
Facci sapere
Ciao
Mancini
2014-03-05 19:53:06 UTC
Permalink
[cit --> BFS]
query adp non esiste
tabelle, view e storedprocedure sono oggetti di sqlserver non del file
adp. sono elaborate e risolte sempre e solo dal server e i soli
[/cit]
Concordo pienamente,
mi sono espresso in modo troppo conciso dando adito a fraintendimenti




[cit --> 774]
Non è necessario creare 2 DB, ne basta uno.
[/cit]
Ma io voglio esaminare anche le proprieta estese dei 2 DB
perche ricordo che ai tempi con .adp c'erano differenze

per il test invece concordo ne basta ( anzi meglio ) uno


:-)
Mancini
2014-03-03 23:07:31 UTC
Permalink
[cit]
Post by pfmarro
- viste di SQL server le trovo molto utili anche se noto che collegate ad access perdono gli eventuali ordinamenti.
[/cit]
Ba!!! Tradizionalmente l'ordinamento si fa immediatamente prima di presentare i dati in maschera o report
Quindi visto che le Viste di SQLServer perdono gli ordinamenti ti conviene non fare ordinamenti finche non sei nella applicazione


[cit]
Post by pfmarro
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?)
[/cit]
Si quando fai la "Gestione tabelle collegate" con delle viste di SQLServer perdi gli indici e il collegamento va in sola lettura.

Per ovviare potresti fare un a routine che richiama 1 per 1 le tabelle e viste è le riconnette.
Eviterei il ciclo perche per ogni vista devi indicare uncampo specifico come indice,
pertanto con il ciclo dovresti fare anche una tabella ausiliaria.
Magari apri un thread specifoco perche l'argomento è abbastanza complesso
e dicci di quante tabelle e viste si tratta


[cit]
Post by pfmarro
- creare delle query pass-through. utili ma non utilizzabili per altre query. (query di query: es query di raggruppamento di una query pass-through)
[/cit]
Questa non la capisco,

ho provato a fare una query PassTrought e su questa una query raggruppata.
funziona tutto benissimo
questa è la PassThrought
[code]
SELECT
TaId,
TaData,
TaNote,
TaNum,
CASE WHEN TaNum < 15 THEN 'x' ELSE 'y' END AS Calc
FROM
dbo.Tabe
[/code]
e questa è la raggruppata sulla PassThrought
[code]
SELECT
Count(QPT1.TaId) AS ConId,
QPT1.TaData,
Max(QPT1.TaNum) AS MaxNum,
QPT1.Calc
FROM
QPT1
GROUP BY
QPT1.TaData,
QPT1.Calc
;
[/code]
Postaci la tua PassThrought che poi non riesci a raggruppare
g***@gmail.com
2014-03-03 19:25:44 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
prima di tutto grazie del messaggio

credo proprio nel forum e nella crescita con confronti.

ho letto attentamente il tuo messaggio
ammetto che non uso ADP ma ODBC.
cosa intendi per

"Un difetto di questa soluzione è l'impossibilità di gestire gli oggetti del database direttamente da access, cosa possibile con Access 2007: in questo modo si possono creare tabelle, query ecc nel database direttamente da Access senza neanche aver bisogno di SSMS"
intendi ADP del 2007?

Grazie
774
2014-03-03 19:59:28 UTC
Permalink
Post by g***@gmail.com
ho letto attentamente il tuo messaggio
ammetto che non uso ADP ma ODBC.
cosa intendi per
"Un difetto di questa soluzione è l'impossibilità di gestire gli oggetti
del database direttamente da access, cosa possibile con Access 2007: in
questo modo si possono creare tabelle, query ecc nel database >direttamente
da Access senza neanche aver bisogno di SSMS"
intendi ADP del 2007?
Grazie
Si, intendo proprio questo.
Sarà sempre sottinteso in seguito che parlerò solo del formato Adp.
Se vogliamo creare all'nterno del server una tabella in modalità
progettazione, oppure un indice o una relazione, lo possiamo fare
direttamente in Access come fossero oggetti locali, cosa possibile usando in
alternativa SSMS.
La manipolazione degli oggetti è possibile a seconda della versione di
Access e della versione di Sql Server.
Con Access Xp e Access 2003 è possibile manipolare oggetti del database solo
fino alla versione Sql Server 2000.
Per le versioni successive di Sql Server lo si può fare con Access 2007 e
Access 2010.
In ogni caso non è una grave mancanza, essendoci SSMS.

Rispetto a quello che ho scritto prima voglio sottolineare il fatto che
l'applicazione che funziona in vpn non è progettata per tale scopo, ma solo
per la rete locale, eppure è utilizzabile, anche se non è un fulmine.
Continua a leggere su narkive:
Loading...