Newsgroup: it.comp.appl.access
Titolo: migrazione BE

Ciao
Sto gestendo e sviluppando un database Access composto FE/BE con una
ventina di postazioni e quindi di accessi contemporanei.
Vorrei passare a SQL server come back end e sto leggendo libri per
documentarmi.
A quanto ho capito gli adp sono la soluzione più performante per il
trasferimento dei dati e permettono di gestire in modo nativo le SP che
vorrei usare come sorgente dati per le mie maschere, in modo da far
passare per la rete il minor quantitativo di dati possibile.
Tuttavia gli adp non supportano le query a campi incrociati che uso
pesantemente per molti report e non posso rinunciare ad esse.
Restano le tabelle collegate ODBC, ma in questo caso non ho idea di come
gestire le Stored Procedure e come attaccarvi le maschere.
Qual'è il modo migliore di filtrare i dati sul server e passare ad Access
i soli dati necessari? Come faccio ad eseguire in locale Query a campi
incrocociati basate su dati già filtrati dal server? COme si gestisce un
vero client server con Access senza ADP?
Grazie a tutti, sui libri che ho letto l'intgrazione Access e BE SQL
prevede essenzialmente ADP ma non posso usarli...
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 gestire le Stored Procedure e come attaccarvi le maschere.
Con ODBDirect puoi far eseguire SP sul Server con parametri di Input-Output.
Puoi anche eseguire Select pass-throught e basarci origini dati di
combo/reports, Forms ... anche se nel caso delle maschere i recorsets
restituiti sono snapshot.
Ma in generale con ODBC è buona norma utilizzare nelle viste tabellari
sempre snapshot, le modifiche verranno eseguite in mascherine di
"dettaglio".
Altra cosa da evitare assolutamente sono le query con origine dati
eterogenee (SQL+JET per esempio).
Per approfondire consulta i seguenti:
http://support.microsoft.com/default.aspx?scid=KB;en-us;q164481
http://support.microsoft.com/default.aspx?scid=kb;en-us;128808
Saluti.

 prevede essenzialmente ADP ma non posso usarli...
Non vedo perche'.
Sib


Cioe' tu dici che la miglior cosa sia: SQL Server e ADP di Access
quello nativo? anzike usare odbc?
Ciao :)

"yQy" <fabrizi...@SESPAMMITISTRONCOtin.it> ha scritto nel messaggio
news:23g9evkqsjrjqi8af...@4ax.com...

Per forza che č cosě.

 quello nativo? anzike usare odbc?
Con ODBC è comunque possibile creare applicazioni Client-Server scalabili a
vaste multiutenze: basta evitare le ingenuità più grossolane (e nei links
che ti hanno postato ci sono buoni esempi).
La scelta dipende anche da te: fai dei tests per valutare quale delle due
soluzioni maggiormente ti aggradi.
Ti saluto.

"yQy" <fabrizi...@SESPAMMITISTRONCOtin.it> ha scritto nel messaggio

Si', intendevo proprio quello.
Se sei abituato con odbc, te ne accorgerai subito delle differenze.
ad es. negli adp le query non esistonno, fai direttamente viste e sp, ma la
cosa bella e' che le viste e le sp, che vedi allo stesso modo di come
vedresti le query, non sono in realta nel tuo fe, ma direttamente nel be,
quindi non esiste proprio il problema se le elaborazioni siano locali o
remote, sono tutte remote.
Sib

 remote, sono tutte remote.
Attenzione però Davide, da come l'hai scritto potrebbe pensare che qualunque
cosa chieda al Server, questi gliela restituisca alla velocità della luce,
il che non è vero.
Con un .ADP puoi lavorare solo col codice SQL nativo del Server, ma le
elaborazioni restano Client-Server.
Quindi se scrivo una select che mi restituisca un milione di records in un
DataSheet ... al Client quei record devono andare, .ADP o ODBC che sia, con
chiara insoddisfazione di tutti ;-)
Le elaborazion saranno tutte "remote" solo se configura un Terminal Server,
ma a quel punto il discorso è indipendente dal motore Back-End.
Ciao.

"Sib" <si...@SPAMiol.it> ha scritto nel messaggio
news:QpiFa.67905$pR3.1...@news1.tin.it...

Scusate l'intromissione. Potrei pensare a questa soluzione per mettere in
pensione il DB2 su AS/400 replicandolo su un Server basato su SQL Server.
Il mio uso attuale con Access riguarda per lo più interrogazioni e
reportistica, raramente UPDATE su singolo record, frequenti gli
aggiornamenti di MASSA (update, insert, delete) per singola connessione.
Gli ADO e le query pass-through sono utilizzati a tal scopo in maniera
massiccia.
I primi sono un potente strumento flessibile che permette maggiore
interattività, utilizzato soprattuto in remoto (gestendo anche DB
transazionali, vedi commit e rollback, non nidificati però). Le seconde per
la reportistica in genere.
Manca solo un piccolo particolare: vera interattività irragiungibile dati i
tempi lunghi di risposta. Non ne parliamo per utenti in remoto.... disastro.
La domanda nasce spontanea: non avendo nessunissima esperienza in SQL
Server, ma solo in Access 2000...
da dove incomincio?
SQL Server mi permette di avere l'interfaccia che mi offre Access con tutti
i controlli manipolabili da VBA, eventi a non finire, ecc. ecc.?
Bisogna acquistare hw carrozzato per i client?
Sui client si deve installare SQL Server (che ne so versione client...)?
SQL Server quanto costa?
Grazie e pazientate un pochino per la lunga premessa. Ciao.
Daniele

 ha scritto nel messaggio
news:gZiFa.76157$Ny5.2...@twister2.libero.it...

Dal punto di vista delle licenze necessiti della licenza SQL Server (una,
per il server) e tante CAL quanti sono i client Microsoft collegati alla
rete (poco importa se accedono SQL Server o no...).
Dal punto di vista del collegamento con il DB, con Access hai due
possibilità: dai file MDB via ODBC (o al limite solo da codice via ADO o
ADOX), dai file ADP via OLEDB (ADO).
L'hardware va carrozzato per supportare Access...
Ciao.

 
http://support.microsoft.com/default.aspx?scid=kb;en-us;128808
Grazie per i links
Saluti


 Ciao.
Scusami se mi ripeto: SQL Server non ha nessuna interfaccia evoluta come
Access?
Se  non ha interfaccia come si progetta tutta la struttura del DB e
l'interfaccia utente?
Grazie


Ha una console di amministrazione che sia si chiama enterprise manager da
cui puoi operare le manutenzioni del caso: creare, backuppare e droppare DB,
operare sugli oggetti quali tabelle viste, ecc... ma COMUNQUE con
funzionalità di pura amministrazione, non di uso.
Non so se mi sono spiegato.
SQL Server è un SERVER non un RAD con un DB dietro...
Ciao.

 Ciao.
Solo adesso so SQL non ha interfaccia come sono abituato con Access.
Sì un po' come avviene con DB2 sull'AS/400 dove accedo con gli ODBC.
Ti ringrazio ancora
Daniele


E' vero solo parzialmente: Access 2000, meglio l'XP, è la naturale
interfaccia utente di SQL Server 7 o 2000... ti sembra più chiaro così?
Puoi farci quello che vuoi: creare db, tabelle, stored procedures, assegnare
privilegi, modificare delle viste... che cos'è se non un'interfaccia di
amministrazione questa?
Al DB2 accedi via ODBC perchè non hai un'interfaccia grafica, tutto qui...


Così è fantastico! Ci sono innumerevoli vantaggi. Le query che costruisco
coinvolgono parecchie tabelle contemporaneamente e sono piuttosto corpose e
nidificate su più livelli.
La cosa da fare è mettersi bene al lavoro sulle strutture, relazioni,
indici, ecc... e strutturare per benino le query in modo che
da richiedere solo e sempre ciò che serve in quel momento.
Dammi una conferma: Ad esempio, è inutile scaricare l'intera anagrafica
fornitori per farne sceglierne uno alla fine in fattura... è sufficiente
suggerigli cosa cercare (non so una sigla una parte del nome, la partita
iva, o altro)?

In parole povere se ho capito bene la strada da percorrere è questa?
1) Replica da destinare su un server SQL Server
2) SQL Server è il server
3) Su Access 2000 (trasfomato in ADP) verrà programmato l'intero gestionale
e curata tutta l'interfaccia
    (sangue e sudore)
4) Client-Server è servito.
Una licenza che "quota di mercato" ha in soldoni?
Ti ringrazio nuovamente
Daniele

 ma a quel punto il discorso è indipendente dal motore Back-End.
che c'entra.
quello di cui noi accessisti ci siamo lamentati fin'ora e' che facendo una
query che filtra 10 record da una tabella che ne contiene 10 milioni access
deve elaborare localmente tutti i dieci milioni di record quanto meno a
livello di indice, il che e' una bella seccatura.
gli adp risolvono questo problema con efficienza ed efficacia (per non
parlare della ssemplicita' rispetto agli odbc.
Sib

 strttura del DB SQL. Puoi allegare tabelle e viste e usarle come tabelle
di
COME NO?
invece hai proprio la visibilita' delle viste e delle sp memorizzate nel
motore sql server!
Per di piu' puoi gestirle, crearle, manipolarle e farne quello che vuoi sia
a mano sia da codice.
La cosa vale anche per gli utenti e la sicurezza.
Il tutto tramite gli adp.
Sib

 SQL Server quanto costa?
assai.
no, scherzo. certo non lo regalano ma i costi non si avvicinano a un quinto
del costo del piu' scarso as400
ciao
Sib

 parlare della ssemplicita' rispetto agli odbc.
Il discorso è più articolato: anche con ODBC puoi eseguire una select sul
Server e associare il set di risultati a una Form, ma il recordset è a sola
lettura e viene a mancare la flessibilità del Data Entry in vista tabellare
_che molti comunque non amano_
La forza di un .ADP in questi casi sta:
1) Nel caricamento in background del set di record
2) I Recordset Snapshot aggiornabili che sono un decente compromesso tra
prestazioni e flessibilità.
Per contro, in varie situazioni, si deve ricorrere ai comandi Resync per
aggiornare i dati nelle Forms ... e non è il massimo per chi non sia
abituato ad usare .ADP.
Ti saluto.

Dalla lettura del thread mi sembra che gli ADP funzionino bene e
permettano di gestire database multiutenti con un certa scalabilità
sfruttando l'elaborazione sul server. A questo punto mi sembra la strada
giusta da percorrere, visto anche che mi serve il data entry nelle forms e
quindi non posso usare SP e query pass through.
Vorrei sapere ancora due cose:
1) A cosa rinuncio con gli ADP? Avranno qualche problema anche loro. 
Ho letto della necessità di resync, potete spiegarmi meglio?
2) Devo prima scoprire e fare degli esperimenti con le query cross tab
perchè se non riesco a riprodurle non posso migrare un bel niente.
Qualcuno mi rispondeva che si possono simulare sapendo a priori le
colonne, cosa che io so, quindi dovrei superare l'ostacolo. Ma devo usare
le SP per riuscirirci o staticamente posso usare anche il QBE normale?
Grazie a tutti


 Ho letto della necessità di resync, potete spiegarmi meglio?
Ci sono molti problemi e difficoltà, ma le capirai quando ci metterai il
nasino ;-)
Proprio perchè non utilizzano Dynaset _troppo pesanti in rete_ richiedono
allo sviluppatore (in molte circostanze) uno sforzo "manuale" per aggiornare
i dati sulle forms.
A parte questo con gli .adp puoi lavorare solo con SQLSVR, non puoi avere
tabelle locali sul Client e hanno i loro bei bachi: .GPF, "memory leaks" e
altro ancora.
Se cerchi a proposito degli Access Data Project su comp.databases.msaccess
(quello USA) ne trovi di tutti i colori: gli Yankees sono perfezionisti ed
esagerano, però non hanno tutti i torti ;-)
Ciao.

 di quel cliente facendo elaborare la tabella al server BE?
Dopo aver filtrato col codice di SQL i clienti che ti servono, avrai una
maschera a sola lettura.
Un click su un bottone potrebbe esplodere in una maschera singola i dati di
dettaglio di quel record: dato che l'accesso avviene attraverso l'indice
della chiave primaria il processo di recuperò sarà abbastanza veloce _almeno
in rete LAN_ e poco costoso.
Ma si potrebbe andare oltre: la maschera singola di dettaglio potrebbe
essere rigorosamente non associata, alla fine del Data Entry salvi i dati
sul Server con una connessione Direct utilizzando la sintassi del Server
(per i dettagli devi consulterai manualistica, web, usenet, etc.).
Concordo però sul fatto che ci vuole più lavoro per ottenere le prestazioni
con
ODBC/Direct, partendo oggi a sviluppare una gestione probabilmente opterei
solo per .ADP.
Ma se nel caso tuo prevedi solo una ventina di postazioni in rete locale e
non in remoto, preparerei prima un prototipo ODBC: a parer mio abituarsi a
lavorare con gli Access Data project (e i buchi che devi aggirare, e i .gpf
che incontri) richiede molto tempo.
Saluti.

 i dati sulle forms.
Qualcosa di più potevo dirti ;-)
Il comando resync è una maledetta istruzione SQL aggiuntiva che va scritta
(in determinate forms) per vedere i dati aggiornati a video in fase di
modifica.
Peraltro, non essendoci strumenti visuali che aiutino, è facile commettere
errori e in questo Access non t'aiuta.
Ciao.

 che incontri) richiede molto tempo.
Il prototipo l'ho già fatto, anche se chiaramente non è ottimizzato e non
usa SP. Tuttavia ho visto che con tabelle collegate ODBC senza SP il tutto
risulta circa il doppio più lento del sistema attuale in Access e non
voglio sprecare tempo se la strada migliore e più attuale sono gli ADP. 
Ho studiato un pò le SP e ho visto che potrebbero risolvere tante
operazioni che faccio e che quindi risulterebbero decisamente più
performanti; rimango perplesso dai probelemi e dai bachi che mi segnali,
dove posso documentarmi?
Grazie e ciao


 dove posso documentarmi?
Putroppo non sono cose che invento: ma ripeto, valuterai da te quanto
traumatico sia il passaggio.
Per esempio dai un'occhiata a questo:
http://groups.google.it/groups?hl=it&lr=&ie=UTF-8&threadm=Xns92EA4BE449337ly
lefairyahoocom%40216.221.81.119&rnum=1&prev=/groups%3Fq%3D%2522truly%2Bsuck%
2522%2Bgroup:comp.databases.ms-access%26hl%3Dit%26lr%3D%26ie%3DUTF-8%26group
%3Dcomp.databases.ms-access%26selm%3DXns92EA4BE449337lylefairyahoocom%254021
6.221.81.119%26rnum%3D1
Oppure a quest'altro:
http://groups.google.it/groups?hl=it&lr=&ie=UTF-8&threadm=a3f86127.021211133
3.26f7d35b%
40posting.google.com
&rnum=8&prev=/groups%3Fq%3D%2522adp%2522%2Bgr
oup:comp.databases.ms-access%26hl%3Dit%26lr%3D%26ie%3DUTF-8%26group%3Dcomp.d
atabases.ms-access%26selm%3Da3f86127.0212111333.26f7d35b%2540posting.google.
com%26rnum%3D8
Perchè un prodotto MS sia solido, servono almeno 3 Service pack...
Simone

"Sib" <si...@SPAMiol.it> ha scritto nel messaggio
news:nynFa.115399$g92.2...@news2.tin.it...

SQL Server è qualcosa di mastodontico.
Mi ricorda quell'acqua minerale "povera di sodio"... Access 2000 è quella
particella di sodio...
Mi chiedevo se sai dirmi al volo un buon libro da acquistare del calibro di
serietà "Access 2000 Manuale di Programmazione " della Jackson Libri per cui
vale la per di spendere 100 euro.
Ti ringrazio.
Spero solo di non buttarmi in un progetto troppo grande. Sono preoccupato
per lo più per gli utenti che hanno disponibile una banda da 64 kb. Non
vorrei cercare delle soluzioni cervellotiche... paging, caching, replica
ecc...
Conforto morale?
Ciao.
Daniele

 ecc...
se la banda e' stretta devi fare largo uso di viste filtrate, con un server
puoi richiedere anche un record alla volta (con buona pace della banda).
Ciao
Sib