Newsgroup: it.comp.appl.access
Titolo: Cosa serve per migrare mdb a sql?

Buongiorno a tutti.
 
Il problema non è studiare, bensì sapere cosa studiare, ed in questo momento non ho la più pallida idea di cosa mi serva per migrare il mio mdb che:
- contiene solo tabelle e relazioni,
- è visibile a FE AccessXP/03/07,
- si trova in LAN,
- è condiviso da 30 utenti (di solito almeno 15-20 contemporanei).
 
N.b.: chiedo qui e a voi a causa di filtri, proxy e cippalippe varie applicati alla rete aziendale.
 
TIA
Popi


prima di tutto imparare i tipi di dati usati da sqlserver e le 
differenze rispetto ai dati del mdb
 
se usi i file adp per collegarti poi devi imparare a convertire tutte le 
query in view e stored procedure
 
per quanto riguarda il codice, devi usare ado invece di dao
 
sulle forms infine ci sono alcune differenze e accorgimenti da rispettare
 
il passaggio non è insomma indolore...anzi richiede pazienza
ma i vantaggi in termini di stabilità e prestazioni sono valgono 
ampiamente la fatica
 
ciao
BFS

 ampiamente la fatica
 
Ciao!
No problem sui tipi di dato: mi documenterò (dove?) su testo, memo, intero lungo, booleano, precisione doppia, data/ora.
 
Comunque il FE è un MDE generato con AXP e fatto girare sotto AXP/A03/A07 (in base a quale sia installato sulla macchina utente).
 
Perché ADO?
Pensavo che collegando le tabelle da db SQL anziché da MDB a livello di codice l'impatto ad esempio (!) sulle openrecordset fosse relativo a "parametri specifici" (opzioni come dbopentable, per intenderci), non è così?
 
Un esempio di differenze ed accorgimenti sulle form?
La cosa vale anche per i report?
 
Non potrebbe essere comunque un passaggio indolore, dato che i numeri da smazzare sono >170 form, 30 moduli, >300 report, >900 query ...
 
TIA
Popi

 > - è condiviso da 30 utenti (di solito almeno 15-20 contemporanei).
 
Piccola precisazione ulteriore: oltre che cosa studiare mi servirebbe anche sapere cosa installare ...
 
TIA
Popi

Popi - TheBadHabits ha scritto:
 

Da anni ormai utilizzo FE+SQLExpress collegati ODBC.
Mai avuto problemi.
Il passaggio è stato indolore. Qualche piccolo accorgimento: le tabelle
debbono essere dotate di un contatore PK e inserimento di un campo
timestamp.
 
--
sv  
 
-- 
 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it
 
 
 

 timestamp.
 
Ciao Salvino.
 
Con SqlExpress intendi questo?
http://www.microsoft.com/sqlserver/en/us/editions/express.aspx
 
 
Se il db sql si deve trovare su una cartella di rete ... il software andrà installato sul server che la ospita?
 
Le tabelle hanno già tutte una PK, va bene così o devo aggiungerne un'altra basata su campi contatore???
Studierò il campo timestamp.
 
TIA
Popi


per prima cosa decidi se vuoi usare i file adp che si appoggiano 
nativamente a sql server o usare la connessione ODBC come ti diceva SV
personalmente mi trovo molto meglio con la prima, ora che ho 
famigliarizzato con stored procedure e view
Con ODBC sicuramente il passaggio è meno traumatico ma da un test che 
avevo fatto a suo tempo ho notato prestazioni in rete nettamente inferiori
 
ciao
BFS
 
 


Non apro dispute ado vs dao, ma porto la mia esperienza. Sql express
in rete lan con client in A2003/2007. Connessione ODBC. Applicativo
con quasi 200 form e nn so manco quante query. A parte qualche
accorgimento il passaggio è stato praticamente indolore, più la paura
dell'upgrade che il vero e proprio upgrade. Poi, con calma, stò
trasformando cicli e query 'pesanti' in stored e view. Ma il lavoro va
avanti senza rallentamenti e le prestazioni aumentano pian piano.
Facendo in questo modo ho potuto sveltire la migrazione (qualche
settimana per familiarizzare con le differenza mdb/sql, dati boolean,
formati data e cambiare le relative procedure) e poi dedicarmi ai
meandri di SQL server

 avevo fatto a suo tempo ho notato prestazioni in rete nettamente inferiori
 
Ciao!
Al momento il nocciolo della questione è tutto sulla facilità di implementazione, a maggior ragione se le prestazioni via ODBC sono come minimo le stesse via JET/MDB (BTW per varie ragioni non credo che passerò il FE a ADP).
 
Comunque grazie di tutto :)
 
Popi

 meandri di SQL server
 
Yes, l'idea è proprio quella: cambiare il meno possibile (teoricamente solo il DBMS in cui sono memorizzati i dati) per avere il sistema up&running in tempo zero, e poi passare a migliorare dove necessario.
 
BTW perché trasformare le query?
Al momento le ho tutte nel FE ....
 
Popi

on 03-04-12, Popi - TheBadHabits supposed :

Rispondo anche a Fair87 che dichiara fra l'altro:
"quasi 200 form e nn so manco quante query"
 
Ma cosa ve ne fate di tante query?
 
Io ho un'applicazione (contabilità) con 110 Tab, 203 Form, 164 Report,
44314 linee di programma, 0 Macro, 0 Query!
Debbo considerarmi un marziano?
 
Bruno
 
PS
Per query intendo quelle che appaiono sulla finestra database, non 
quelle create al volo con codice VBA; queste non sono in grado di 
contarle.
 
 


in mdb concordo che sono inutili.
in una applicazione che poggia su sql server è fondamentale averne il 
più possibile. (intese come stored procedure)
 
BFS

 contarle.
 
Ciao Bruno.
 
Forse per deformazione professionale (leggi "facilità di documentazione") ogni form/report hanno la loro bella query (con stesso nome!).
 
Ovviamente ne ho diverse che costruisco a codice, ma la maggior parte sono salvate.
Anche perché in diversi casi ho query che richiamano altre query basate a loro volta su query di query ... 
 
Nel mio caso si tratta di sw per studi di affidabilità e manutenibilità di grandi impianti, ed in diversi casi c'è da raggruppare i dati, estrarne alcuni, sommarne altri, e poi magari dividere i sommati per quelli estratti ed infine unirli ai dati di partenza ... PAURA!!!
 
Popi

 Popi


[cut]
 
Scaricati questo white paper per il 2005, ma penso che i concetti siano
sempre gli stessi.
 
http://www.google.it/url?sa=t&rct=j&q=&esrc=s&frm=1&source=web&cd=1&ved=0CCcQFjAA&url=http%3A%2F%2Fdownload.microsoft.com%2Fdownload%2F8%2Fe%2F7%2F8e726318-0357-4cbc-a68d-ed6b5380efbf%2FMgSQLExpwSSMSE.rtf&ei=owl7T8fuC_OM4gSg4PSHBA&usg=AFQjCNF_UyT5RO2dDfnnirk7ak7Pb1EJnw&sig2=iTndGTuQDe50TZnqzKR21A
 



Ciao Bruno, macchè marziano!!!! Anzi, mi chiedo come tu faccia a nn
avere query memorizzate......
Per quanto mi riguarda, 1 form = 1 query, 1 rpt = 1 query, quando non
sono costretto dagli eventi a costruirle on the fly. Quindi non dico
200 Form = 200 qry ma quasi.....più tutte le insert, update.....nelle
query di selezione Access ho notato essere + performante se si usa il
QBE piuttosto che il VBA. Quando posso, anche per comodità di
parametrizzazione, uso le qry memorizzate (ah...che meraviglia non
doversi preoccupare di formati di data, campi nulli ecc ecc eccc...),
se no vba a palla de foco....

 sv
 
 
Su AccessGroup ho inserito la relazione di Giorgio:
 
http://lnx.accessgroup.it/community/tabelle/mdb-accdb-e-microsoft-sql-server-via-odbc.html
 


 se no vba a palla de foco....
 
Anch'io uso un'infinità di Query/subQuery sempre in ambito VBA, per 
filtrare, per aggregare, per creare controlli calcolati di 
scheda/report  (per esempio in luogo delle domain function DSum, DCount 
etc che proprio non uso mai).
E come record source di Form/Report.
 
Quanto alle performance non me ne son mai preoccupato: uso processori 
piuttosto allegri e RAM in abbondanza.
 
Bruno