Newsgroup: it.comp.appl.access
Titolo: dati sql server express e front end access

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
 

 ha scritto nel messaggio 
news:530e425c$0$1370$4faf...@reader1.news.tin.it...

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 
 
 

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.
 
 
 
 
 
 


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
 
 

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

BFS
 
Bella questa e pure realistica
 

Grazie del messaggio cosa intendi per SQL e non access?

viste, stored procedure, t-sql

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


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 )
 
 
 
 
 
 
 
 
 
 
 
 

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!


 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.
 
 
 
 


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

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.
 
 
 
 

 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
 

 
[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
 
,
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

 - 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

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
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

 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.
 
 
 

 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

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.

Stefano
Ciao 
 
 

 ha scritto nel messaggio 
 
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

 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
 

 ha scritto nel messaggio 
news:57e50592-e92f-462f...@googlegroups.com...

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 
 
 

[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
 
 
:-)

 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